• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 799 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/CC1310: Semaphore Delay

Mark Lederman
Prodigy 240 points
Part Number: CC1310

Tool/software: TI-RTOS

Hello:

I'm seeing a similar issue with semaphore delay as mentioned in this post https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/607008?tisearch=e2e-quicksearch&keymatch=Semaphore Delay

In our application a radio waits to receive a message and then transmits a reply. Using a logic analyzer we are currently measuring a 360 microsecond gap between receive and transmit. 70 of those microseconds are for the semaphore to trigger. My first thought was there's power policy code going on so I disabled all aspects of the power policy but no joy.

Below is the breakdown of the rx/tx gap time. Just wondering if those times are in the ballpark and if there is anything I can do about them? It doesn't appear I can use command chaining to save time because the receive message has to be interpreted. Not unless I can chain a cancel command with a transmit?  Not using a semaphore saves 70 uS but would prefer to use it. Any suggestions?

Gap Time

semaphore: ~70 uS

RF_getRssi: ~20 uS

RF_cancelCmd: ~110 uS

my code: ~20 uS

RF_runCmd(Transmit): ~140 uS.

  • 0
    TI__Genius 14860 points

    You could analyse the packet and post the TX command directly in the RX callback, but I guess you want to use the semaphore for a "cleaner" SW architecture and shifting most of the work onto task level. 70µs seems to be the time needed for switching from the system stack to the task stack and it is indeed a bit long. Do you pend with a timeout? This would start a timer and require some extra code to abort the timer then.

    Do you see any improvement when you do:

    Semaphore_pend();
RF_getRssi();
// Your code
RF_postCmd(TX);
RF_cancelCmd(RX);

    This would optimize the time spent between cancelling RX and starting TX. Another option would be, to chain the TX command to the RX command with COND_ALWAYS. I guess you have set the RX command to run infinitly. Instead of cancelling it, use a custom end trigger for the RX command once you have your packet payload in place. Set pktConf.endType to 1 to force the RX command to abort when the end trigger is observed. You would only cancel the whole chain when you decide to not send a reply.

    Hope that helps.

  • 0 in reply to Richard W.
    Prodigy 240 points

    Thank you. With my setup there is a master radio and many slaves. The master transmits a message and the slaves respond in sequential address order. If a slave doesn’t hear from the preceding address it transmits just after it believes it should have. Would command chaining work for my use case and if so would it save time?

  • 0 in reply to Mark Lederman
    TI__Genius 14860 points

    Hi,

    Mark Lederman said:
    Would command chaining work for my use case and if so would it save time?

    it would work and you can squeeze the last microseconds out of the CC1310. But I would recommend to start without chaining first and get the system working with ordinary timing to achieve a simple code. What I don't understand:

    Mark Lederman said:
    The master transmits a message and the slaves respond in sequential address order. If a slave doesn’t hear from the preceding address it transmits just after it believes it should have.

    Do your slaves have fixed timeslots when they are supposed to respond or is the TX time variable and depending on how many preceding slaves have responded? The latter case sounds a bit fragile to me.