This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Omap 3530: Fastest GPIO toggle speed

Prodigy 10 points

Replies: 27

Views: 19748

Folks,

I am scoping out an application on OMAP 3530 SoC where linux code interacts with the user and DSP code acts as a multi-channel waveform generator. I will be using DSP-Link for the two sides to communicate. My questions are:

  • What is a fastest speed at which I can toggle a GPIO pin from DSP code?
  • If I want to do the above on multiple channels/pins, what limitations would I run into?

Thanks in advance for any insights.

 

-Raj

27 Replies

  • In reply to Brad Griffis:

    So, on the clocks, the sysclk = 26Mhz. This is clearly not inside the band specified in this register setting.

    Is there somewhere this gets divided to meet this range? I'm not sure I've seen this anywhere?

    Ultimately though, what effect are any of these clks going to have on the gpio toggle speed. From the sounds of it, little or none - I'm guessing.

     

    With some cuts and jumps on the fpga board I should be able to make this happen - move the spi pins to the jtag pins on the fpga.

    Some advice on setting up the SPI would be nice. I know I'm on my own on the jtag to fpga protocol. But Xilinix goes through this fairly well - so I should be able to handle that.

    I will have to do some research on the TMS signal and its usage in the configuration process.

     

    I'll post back when I have an understanding of the details - it will most likely be tomorrow or Monday before I can get to and through it.

    Thanks again for the insight.

    Matt

  • In reply to MPope:

    I recommend researching TMS before you hack up your board or go too far down the path of programming SPI.  Otherwise you may do a lot of work for nothing!

     

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

  • In reply to Brad Griffis:

    Thanks for the ref on the clk stuff. I'll have a look and see if it helps make sense of things.

     

    It's not looking to good for the spi use unless it can handle single bit operations.

    I found this nice description, while I was eating lunch, on the jtag sequence.

    There are a bunch of different length transfers as well as some that require tms to transition at the end.

     

     

    Table 10-4: Single Device Configuration Sequence

    TAP Controller Step and Description

    Set and Hold # of Clocks                                                               TDI TMS TCK

    1. On power-up, place a logic 1 on the TMS, and clock

    the TCK five times. This ensures starting in the TLR

    (Test-Logic-Reset) state. X      1      5

    2. Move into the RTI state. X      0      1

    3. Move into the SELECT-IR state. X      1      2

    4. Enter the SHIFT-IR state. X      0      2

    5. Start loading the CFG_IN instruction, LSB first:             000101      0      5

    6. Load the MSB of CFG_IN instruction when exiting

    SHIFT-IR, as defined in the IEEE standard.     0      1      1

    7. Enter the SELECT-DR state. X      1      2

    8. Enter the SHIFT-DR state. X      0      2

    9. Shift in the Spartan-6 FPGA bitstream. Bitn (MSB) is

    the first bit in the bitstream(1).      bit1 ... bitn      0      (bits in bitstream)-1

    10. Shift in the last bit of the bitstream. Bit0 (LSB) shifts

    on the transition to EXIT1-DR.                                  bit0      1      1

    11. Enter UPDATE-DR state. X      1      1

    12. Move into RTI state. X      1      1

    13. Enter the SELECT-IR state. X      1      2

    14. Move to the SHIFT-IR state X      0      2 

    15. Start loading the JSTART instruction. The JSTART

    instruction initializes the startup sequence.      001100      0      5

    16. Load the last bit of the JSTART instruction. 0      1      1

    17. Move to the UPDATE-IR state. X      1      1

    18. Move to the RTI state and clock the startup

    sequence by applying a minimum of 16 clock cycles

    to the TCK.   X      0      16

    19. Move to the TLR state. The device is now functional. X      1      3

     

    Sorry some of the cols don't stay aligned when posted - hopefully you can still make sense of it.

    Thx,

    Matt

  • In reply to MPope:

    So is Step 9 where you send in the whole file (or the bulk of it)?  If so, that will be the most time consuming part of the operation (i.e. most data being sent) and it appears that TMS=0 for that entire part of the sequence.  So what you  could do is bit bang steps 1-8 and then use the super-duper SPI mode for step 9 and then bit bang the rest.  What's the maximum TCK speed the FPGA can support?  Basically I envision that your GPIO will be kind of slow for steps 1-8 but then you'll be able to blast in the data in step 9.

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

  • In reply to Brad Griffis:

    Yes, step 9 is the bulk of the transfer.

    Can the spi pins be manually done/toggled while in spi mode?

    Or, will the pins mode have to be changed to gpio to do the bit twiddle?

    Is it possible to change the mode and not affect the pins?

     

    I think 99+% fast and <1% slow is just fine.

    Max jtck is specified at 25Mhz.

  • In reply to MPope:

    You would change the pin muxing at run time to switch between GPIO mode and SPI mode.  Sounds like it should create a HUGE optimization!

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

  • In reply to Brad Griffis:

    I thought that might be the case.

    I noticed that the word length in the spi cfg reg has reserved areas for 1,2,3 bit xfer lengths.

    Any chance of those working? Especially the 1 bit? That would then make this a piece of cake.

    But since that would be the case, I'm sure there is no chance of that working.

    Any idea of what would happen if any of those three modes are selected?

  • In reply to MPope:

    Using a 1-bit mode would not speed anything up because then you would need to poll after every single bit to see if the word/bit had completed.  It would actually become slower!

    I don't understand why you say there is no chance of it working.  Just use slow GPIO for everything but step 9.  For step 6 you're just blasting in a huge bitstream right?  If that's the case then I would anticipate using the largest word size, 32-bit.

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

  • In reply to Brad Griffis:

    No it probably wouldn't speed it up - even if it were slower, that would probably be better then going from gpio to spi and back to gpio and hoping there were no glitches on the i/o pins that would cause some problem.

    The part I was referring to as no chance of working was the 1,2,or 3 WL bit transfer modes. I think either way (spi only or gpio/spi/gpio) has possibility and should be a vast improvement. I would probably prefer the spi only mode just because the flow would be easier for me to program and it seems like it would have the best chance of working, in my opinion. I'm not a sw guru by the stretch of anyone's imagination.

    So if the 1-3 bit modes work, then each step just has its length set and go - could be a simple function for all of the xfers but the large 1.3Mb xfer. Step 9 uses 32bits to the last 32bit word and then would be split into 1-3 bytes and a 1 bit xfer.

    I think that would work well if it can be done with the 1,2 & 3 bit xfers.

    There are 7 1-bit xfers, 6 2-bit xfers and 1 3-bit xfer - every thing else is more than 4-bits, 3 5-bits, 1 16-bit.

    So, I guess it's just up to if the 1 to 3-bit xfers work or not to determine the path to follow. Any thoughts on the 1,2, or 3 WL transfers?

     

  • In reply to MPope:

    MPope
    So, I guess it's just up to if the 1 to 3-bit xfers work or not to determine the path to follow. Any thoughts on the 1,2, or 3 WL transfers?

    I'd just use GPIO.  You just need to write to the PADCONF register to switch between GPIO mode and SPI mode.  No big deal.

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.