1 2 Previous Next 27 Replies Latest reply on Jun 25, 2015 3:26 AM by daniel.hotop

    I'm missing something when it comes to setting pins

    daniel.hotop

      Ok so I'm on the CY8CKIT-042 pioneer kit. 

         

      I have 5 output pins in the schematic set to Port0[4..0], and I have a Control Reg(toCpldController) connected to the pins. The http://www.cypress.com/?docID=49248 document shows that I shouldn't need it, but if I don't have it the project won't build.

         

      They are set to strong drive, as the pin is connected to an input pin on a CPLD.

         

      Trying to control the pins in software like this

         

      toCpldController_Write(8u);
      toCpldController_Write(0u);

         

      Gives me a nice up then down pulse that is about 780~800ns long.

         

      If I do

         

      CY_SET_REG32(CYREG_PRT0_DR,8);
      asm("nop");
      CY_SET_REG32(CYREG_PRT0_DR,0);

         

      I get a pulse for 20ns which seems impossibly short for a 48mhz cpu especially given a nop op, but then it holds low for 5~8us then start to glitch, as if it is floating. With the Controller methods above I don't see that happen.

         

      What am I missing?

        • 1. Re: I'm missing something when it comes to setting pins
          user_1377889

          When you connect a control register to a pins compunent it won't work properly when you try to set the oututs with a direct write to the port. Can you post your complete project, so that we all can have a look at all of your settings? To do so, use
          Creator->File->Create Workspace Bundle (minimal)
          and attach the resulting file.



          Bob
           

          • 2. Re: I'm missing something when it comes to setting pins
            user_14586677

            Here is an ap note that discusses fast pin toggle issues, amongst other

               

            GPIO stuff.

               

             

               

                

               

                      

               

            http://www.cypress.com/?rID=93401     AN86439 - PSoC® 4 - Using GPIO Pins

               

             

               

             

               

            Regards, Dana.

            • 3. Re: I'm missing something when it comes to setting pins
              daniel.hotop

              Hi Bob

                 

              I have attached the bundle, thanks for having a look.

                 

               

                 

              Hi Dana

                 

              That is the mythical document that shows I don't need to connect things to pins for it to build.. I hope Bob finds what I have done wrong.

                 

               

                 

              Is it documented on how fast the ARM can pump data to the internal FIFO buffers? Can it push data there at 48Mhz, and then let the hardware push it out at 48Mhz?

              • 4. Re: I'm missing something when it comes to setting pins
                user_1377889

                OK, back to the drawing-board:

                   

                You do not need to use a status register to read the state of a pin.

                   

                You do not need to use a control register to set the state of a pin.

                   

                You cannot conect a pin to an internal signal and write to the pin by software expecting a predictable result (Who will win, the signal level or the written value???)

                   

                 

                   

                The discussion on how fast a pin can be toggled by software has been started often (started with PSoC1) and always ended up in the following conclusion:

                   

                You can toggle a pin at a comparable low speed as 4MHz (let it be more or less, no matter) but you cannot control the pin since you are using up the whole CPU performance to toggle.

                   

                Instead, with a simple component which is real hardware inside a PSoC you may toggle a pin at 48MHz and still being able to control start/stop, pulse width, maintainig a serial interface and some ADCs etc while using only a small amount of CPU power.

                   

                 

                   

                Yes, I admit, it is tempting to write a pin-toggle program to test the performance of an MCU, But, you normally do not compare the performance of an Indy-Car to a pickup by comparing their load capacity.

                   

                 

                   

                I would suggest you to try solving some real-world problems as a reflex light barrier, sensing or regulating and other projects you usually find in the world of embedded microsystems. Then you will see what a PSoC can perform.

                   

                 

                   

                Happy designing

                   

                Bob

                • 5. Re: I'm missing something when it comes to setting pins
                  user_1377889

                  Some more info:

                     

                  When you delete your control- and status-registers and the connecting wires

                     

                  and check off the "Hardware Connection" for your remaining two pin-components you may use

                     

                  fromCPLD_Read() to get both input pins values at the same time in the lower two bits of the result

                     

                  toCPLD_Write() to simultanously write to all 5 pins a (different) value.

                     

                   

                     

                  There is no DMA on your PSoC4

                     

                  When you need DMA, you will have to purchase a CY8CKIT-044 with a PSoC4 -M. That chip has got DMA

                     

                   

                     

                  Bob

                  • 6. Re: I'm missing something when it comes to setting pins
                    user_14586677

                    That is the mythical document that shows I don't need to connect things to pins for it to build.. I hope Bob finds what I have done wrong.

                       

                     

                       

                    Each pin has an internal register, a bit in its respective port, the xxx_DR register, associated with it.

                       

                    So no you do not need a control reg to drive it.

                       

                     

                       

                     

                       

                     

                       

                    Is it documented on how fast the ARM can pump data to the internal FIFO buffers? Can it push data there at 48Mhz, and then let the hardware push it out at 48Mhz?

                       

                     

                       

                    In the ap note direct write to the register maxes out at a pin toggle rate of ~ 300 Khz.

                       

                    You can always do a quick check on any device by looking at the number of cycles

                       

                    to do two ASM mov immeadiates coupled with a near jump, that will reflect code driven

                       

                    toggle rates.

                       

                     

                       

                    Regards, Dana.

                    • 7. Re: I'm missing something when it comes to setting pins
                      daniel.hotop

                      check off the "Hardware Connection"

                         

                      That is what I was missing :) take that off and I don't need the other things.

                         

                      I would suggest you to try solving some real-world problems

                         

                      I am working on a real world problem. The code is not just toggle some pins to blink a led super fast, it is only pin toggles for now, as baby steps.

                         

                      Step 1. Since the arm can not trap a 8Mhz pulse does my Async SetReset in the CPLD work. Hence the wait for a pin  to go high from the CPLD ( the call to action ) then the toggle of another pin ( tell the CPLD I got it, and to hence clear its SR ).

                         

                      Step 2. Can I react in time and calc an address, push it to the arm, in 1000ns?

                         

                      Step 3. Can I do that 5 times in a row and inc the address each time

                         

                      Step 4. Can I react in time and calc an address, and a data value, push it to the arm, in 1000ns?

                         

                      Step 5. Can I do that 11 times in a row and inc the address and pull a different byte each time

                         

                      Step 6. Or can I react in time, calc and address, then wait for the Done, then pull the data value from the CPLD, react to it in time to give the next address?

                         

                      ..... I like to take small measured steps

                         

                      By tweaking the optimisation levels, I have managed to win the fight with the compiler I think ( Why does it in release with optimisation set to high, and I declare the register to be 'register rg32' does it save the value on the stack to read again the next clock ) I have been able to get it to react to the CPLD_request line in ~240ns then do a pulse for ~100ns

                         

                      The LDR/SDR instruction is 2 clocks, at 48mhz that is ~41ns so there are wait states in the bus to delay it to 100ns? Do you have to wait that long or if you put other instructions that are reg/reg or reg/# in between will they execute instead of the CPU stalling?

                         

                      When you need DMA, you will have to purchase a CY8CKIT-044 with a PSoC4 -M. That chip has got DMA

                         

                      I can't find a tech spec for the DMA module, I searched for PSoC4-M TRM and the site only returned the normal PSoC4 one, I did find a family guide which showed the DMA on the block diagram, but no tech specs. I searched for app notes on DMA got nothing, do you know of a document that details its workings?

                         

                       

                         

                      In the ap note direct write to the register maxes out at a pin toggle rate of ~ 300 Khz.

                         

                      Is that what the osciliscope pictures show? Not having one I'm not very good at reading them.

                         

                       

                         

                      Thanks for taking time to help me, I really appreciate it, especially on your weekends.

                      • 8. Re: I'm missing something when it comes to setting pins
                        user_1377889

                        The PSoC 4 might not be as fast as you need it to be...

                           

                        But wait..

                           

                        There are 4 UDBs within your PSoC with a DataPath object containing two FIFOs and a programmable ALU, a counter some PLD and all is running easily at 24MHz. So the question still remains: Can you do your problem in hardware?

                           

                        What do you mean with "Calculatinng an address"?

                           

                        All your requirements seem not yet quite clear to me.

                           

                         

                           

                        Bob

                        • 9. Re: I'm missing something when it comes to setting pins
                          daniel.hotop

                          so given the following steps

                             

                          put lower 8 bits of address onto bus

                             

                          tell cpld it is there

                             

                          tell cpld that the upper 8bits of address are on the bus

                             

                          put upper 8 bits of address onto bus

                             

                          tell cpld that the 8 bits of data are on the bus

                             

                          put 8bits of data onto bus

                             

                          tell cpld done

                             

                          Putting the tell cpld that X is there into a counter on the PLD parts could be done and save ~300ns I think. This is why I wanted to know if the CPU to FIFO was faster as it could put the data into the FIFO and let the CPLD pulse the ARM FIFO to get the data leaving the CPU free.

                             

                           

                             

                          What does this need to do...

                             

                          There are 3 components a Computer a CPLD ( to handle the bus marshaling ) and the PSoC

                             

                          1.) 8 way screen scrolling

                             

                          so you have a 40x25 char screen = 1000 bytes

                             

                          to scroll it left you need to do

                             

                          screenBase = screenBase + 1

                             

                          screenBase +1 = screenBase + 2

                             

                          ...

                             

                          screenBase + 38 = screenBase + 39

                             

                          screenBase + 40 = screenBase + 41

                             

                          ....

                             

                          to scroll down you need to do

                             

                          screenBase + 960 = screenBase + 920

                             

                          screenBase + 961 = screenBase + 921

                             

                          ....

                             

                          ScreenBase + 880 = screenBase + 920

                             

                          ...

                             

                          to scroll up left

                             

                          screenBase = screenBase + 41

                             

                          screenBase + 41 = screenBase + 82

                             

                          ... being diagonal the number of shifts goes for 0-46 back to 0

                             

                          So while that can be done with hardware counters to cover all 8 directions is a lot of silicon, in a CPU - trivial.

                             

                          Then you have to do the same with colour memory.

                             

                          You also have to be able to tell the ARM where screenBase is

                             

                          so you make a packet in memory like so

                             

                          c000 : 00 04

                             

                          Then the computer tells the ARM that it has something at C000 for it, and that it wants it to do task 1 ( where 1 is set Screen Base )

                             

                          The CPLD will load C000 into its address buffer and then pass the task number to the ARM, the ARM then see that it is task1, it then instructs the CPLD to read the first byte at that address, and give it to it, it stores in, inc the address buffer in the CPLD and says get the next byte, cpld gets the byte and then gives it to the ARM, arm stores that in its RAM, and tells the CPLD to give the computer control again.

                             

                          Then later the computer will signal the CPLD with another task 2 ( scroll screen left 1 char ). The CPLD tells the ARM task 2, the ARM tells the CPLD to take control, and then gives it the first address from above, and to read that byte. Then the 2nd address, tells it to write the byte it just read... until all 1000 are done, then changes the address to CRAM, does the 1000, then tells the CPLD to give control back to the host.

                             

                           

                             

                          Once the ARM decides to take control of the computer it has to wait ~3000ns till it can take over, so there is plenty of set up time for its interal state, switching on task etc

                             

                           

                             

                          Sprite Multiplexing

                             

                          each sprite needs x,y,colour,image and then there is 1 byte for all 8 on enable, x expand, y expand, priority and xmsb.

                             

                          Say you want 32 sprites. so the ARM needs to pull in 32xs, 32ys, 32colours, 32 images, 32 misc bits- ofcause you will need a task that tells the ARM where the data is kept in ram, and another task that tells the arm you have changed it, and to grab again. Once it has grabbed the data it will give controll back to the computer.

                             

                          The ARM will then Y sort the 32 sprites, and work out the grouping needed to set the computers registers, it can have 8 on a line and only has 8 sets of registers for sprites. It will then arange the data to the needed format and build an internal raster line table of what raster lines it needs to write that data on. 

                             

                          The CPLD will keep track of cycles the computer has, and thus be able to guess when the raster points are going to occur. some time 4~5 computer clocks before the Raster line is about to hit, the ARM will take control via the CPLD, tell it to get the value of $d012 and poll it till it hits the right value. Once it hits the right value it will write the 8 sprite data to the right places in memory, tell the CPLD to let the host have control and then tell the CPLD the next raster line it wants ( well raster line - a few cycles )

                             

                          Some models of the computer have 65 cycles per line, some 64, others 63, so the ARM will need a task that lets it query, or time the machine to work out which one it is.

                             

                          Flip sprite data.

                             

                          Sprites are 63 bytes of data and the colours are 2 bits wide so flipping them is not trivial. Tell the ARM where it is in RAM , it can pull in the 63 bytes, then as it reads flips the bits the right way , then write back the 63 bytes.

                             

                          Blocks moves, decompression algortims, write sample data to the sound chip... lots of other things

                             

                           

                             

                          The computer lets you have half of a 1Mhz bus. So while th Clock is 1000ns you can only have 500ns, so effectivly 2Mhz. ( well PAL machines give you 1015ns NTSC machines give you 977ns )

                             

                          At the start of the 500ns you need to set the address valid, then at the end you either set the data or read that data depending on how you set the R/W line. So this gives a 500ns window to get the Address to the CPLD, I then have 70ns after that or so to get the R/W line state as well then I have 400ns to get the data to the CPLD if I need to write data. Once the data is to the CPLD I have until the 1000ns is up to prepare for the next round.

                             

                           

                             

                          So basically I need the full power of a CPU, I need at least 2K RAM, and flash/prom to store the program in. Having extra PLD and the ALU units is a nice bonus, I hope I can put the Cycles counters to track the raster line and position into them.

                          • 10. Re: I'm missing something when it comes to setting pins
                            user_1377889

                            Quite a complex project, I whish you good luck!

                               

                             

                               

                            Bob

                            • 11. Re: I'm missing something when it comes to setting pins
                              user_14586677

                              In the ap note direct write to the register maxes out at a pin toggle rate of ~ 300 Khz.

                                 

                              Is that what the oscilloscope pictures show? Not having one I'm not very good at reading them.

                                 

                               

                                 

                              Indeed that is what the scope traces show.

                                 

                               

                                 

                              Looking at the pin architecture one can see that the only thing direct to

                                 

                              the pin is the analog buss.....hmmm makes one wonder if a mux out to the

                                 

                              pin with two states in its inputs, a 0 or a 1, would toggle the pin faster. An

                                 

                              experiment I will try.

                                 

                               

                                 

                              Or this -

                                 

                               

                                 

                                 

                               

                                 

                              Regards, Dana.

                              • 12. Re: I'm missing something when it comes to setting pins
                                user_14586677

                                Using below I got a pretty clean 24 Mhz pin toggling out of the

                                   

                                part. Control reg to disable toggling, or connect HW to D reset

                                   

                                to effect control.

                                   

                                 

                                   

                                Regards, Dana.

                                   

                                 

                                   

                                • 13. Re: I'm missing something when it comes to setting pins
                                  daniel.hotop

                                  Quite a complex project, I whish you good luck!

                                     

                                  Not really, once the system is set up to DMA To and From the computer its academic. writing C code to do the sorting of sprites is 1hr tops. Even a bubble sort will easily out perform what the computer would do.

                                     

                                  The computer has a 7.9~8.1Mhz dot clock which the CPLD uses to time its parts, i.e. it breaks the 500ns active time into 4 smaller clock cycles, so controlling the bus is just a simple FSM.

                                     

                                  Turns out I didn't pick my battle difficultly well though. So far the CPLD stuff has been mostly easy compared the PSoC stuff. I figured with a 48Mhz CPU I would be drowning in clock cycles, that I would be wasting it in long nop loops, that I would be writing C in any old fashion not really caring what the compiler did with it. Not reading the dissasembly and tweaking every compile option and coding in a certian style to fox it into cycle exact coding.

                                     

                                  Do cypress have any barebones higher clock CPU+RAM+ROM combos that are cheap?

                                     

                                  For those who come after

                                     

                                  if( CY_GET_REG32(CYREG_PRT1_PS) != 0 ) break;

                                     

                                  is not the same as this

                                     

                                  register r32 var = CY_GET_REG32(CYREG_PRT1_PS);

                                     

                                  if( var != 0 ) break;

                                     

                                  The first one is about 8x faster.

                                  • 14. Re: I'm missing something when it comes to setting pins
                                    user_1377889

                                    Does it matter when you leave out the "!=0" part?

                                       

                                    There are PSoCs quite faster than a PSoC4 (I thought you would never ask )

                                       

                                    The PSoC5 with an M3-core comes with 68MHz and there are 80MHz versions availlable. Moreover there is the CY8CKIT-050 as a versatile development kit and lastly the CY8CKIT-059 prototyping board with snap-off kit-programmer. The advantage of the PSoC5 besides its speed are the 24 UDBs (compared to 4 with a PSoC4). You may easily build your 8-bit address/data interface using 3 UDBs, pushing the data into a FIFO, getting interrupted.... Even the adding of the displacement values you could do within a single UDB clock cycle.

                                       

                                     

                                       

                                    Bob

                                    1 2 Previous Next