• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 656 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/TMS320F28335: GPIO: Software to hardware delay

Rahul Dewani
Prodigy 20 points

Part Number: TMS320F28335

Tool/software: Code Composer Studio

Hi,

I was trying to establish a half-duplex serial communication scheme from the said DSP to an FPGA board. I need some clarification on the GPIO functionality to clean up the synchronization part of the communication protocol.

Considering the example of GPIO36 configured as an output pin, say the pin is initially reset(Logic 0), and I wish to set it(logic0 to logic 1 transition), there are 2 ways to achieve this:

method 1: GpioDataRegs.GPBSET.bit.GPIO36 = 1;  // writing to the GPBSET register.

method 2: GpioDataRegs.GPBDAT.bit.GPIO36 = 1;  // writing to the GPBDAT register.

As the code is being executed sequentially, can you please comment on how many machine cycles it might take for the hardware pin to go high.

Also, I had been advised by a friend(could never cross-check this from a reference guide though), that the data register may not be written to as the instruction is executed and it may take affect at a much later point, when the RAM values are actually written to the real memory. This suggests that the delay(software instruction execution to hardware pin switching) may be large and most importantly "undeterministic" for method 2. Can you please comment if this makes sense. Also I will be very grateful if you could point to any appropriate reference guide for DSP-TMS320F28335.

EDIT1: Could it be that method 2 has a delay of several machine cycles compared to method 1 as we are accessing a single bit of the corresponding data register and must be using bit-banding. The bit banding register might take a while to update to the real Data register, which is connected to hardware? Just another dart in the dark. :-P 

Thank you! :-)

  • 0
    TI__Guru 57255 points

    Hi Rahul,

    Please take a look at the following wiki page.  I believe it should help answer some of your questions about GPIO register accesses:
    http://processors.wiki.ti.com/index.php/General_Purpose_IO_(GPIO)_FAQ_for_C2000

    Looking at the disassembly code generated by the compiler may also be a helpful tool.

    Hopefully this helps!


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Prodigy 20 points

    Hi Brett,

    Thanks for pointing me to the links. It was really helpful.

    For anyone looking into differences between execution of method 1 and 2 mentioned above, this technical note was of great help: http://www.ti.com/lit/an/spraa85e/spraa85e.pdf 

    Specifically, section 6.1.2 GPxDAT Registers, page 19 reads:

    "Another case of bits that can change between a read and a write are the GPIO data registers. Consider the code shown in Example 18. Except on 281x devices, the GPxDAT registers reflect the state of the pin, not the output latch. This means the register reflects the actual pin value. However, there is a lag between when the register is written to when the new pin value is reflected back in the register. This may pose a problem when this register is used in subsequent program statements to alter the state of GPIO pins. In Example 18, two program statements attempt to drive two different GPIO pins. The second instruction will wait for the first to finish its write due to the write-followed-by-read protection on this peripheral frame. There will be some lag, however, between the write of GPIO16 and the GPxDAT bit reflecting the new value (1) on the pin. During this lag, the second instruction will read the old value of GPIO16 (0) and write it back along with the new value of GPIO17 (0). Therefore, the GPIO16 pin stays low. One solution is to put some NOP’s between the read-modify-write instructions. A better solution is to use the GPxSET/GPxCLEAR/GPxTOGGLE registers instead of the GPxDAT registers. These registers always read back a 0 and writes of 0 have no effect. Only bits that need to be changed can be specified without disturbing any other bit(s) that are currently in the process of changing. The same code using GPxSET and GPxCLEAR registers is shown in Example 19."

    Thanks again Brett, it resolved the issue and helped me learn something new. :-)