• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 1227 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.

1 Semaphore 2 tasks running exclusively Transceiver mode CC3200

Fernando Sanchez1
Intellectual 740 points

Hi,

I have 2 tasks. Task 1 must transmit a packet every 100ms, for this I am using a clock and a semaphore. Task 2 must receive an unknown number of packets that are sent while Task 1 is not transmitting. How can I implement this? are semaphores a feasible approach?

I am trying to use 2 semaphores. May I use just 1 semaphore to enable(disable) task 1 and at the same time disable(enable) task 2?. The 2 tasks should be running exclusively(when one runs, the other stops), but I can not use just 1 thread, because task 2 needs to be receiving an unknown number of frames.

Summarizing, there are 2 tasks:

task 1: Transmits a frame every 100ms. 

task 2: Receive an infinite number of packets. Task 2 should run indefinitely, when task 1 is not active.

So the desired behavior is as follows. The clock triggers task 1 to transmit, task 2 stops and task 1 transmits. After that, task 1 finishes the transmission, and task 2 continues in its loop receiving an undefined number of frames. Later on, when the clock tic happens, task 2 stops and task 1 runs, such that a new frame is transmitted by task 1. The operation continues indefinitely.

I have tried many implementations, but at the end the programs hangs, I think the hanging is something similar to the issue in

http://e2e.ti.com/support/wireless_connectivity/f/968/p/384881/1362946#1362946

but I want to be sure that is just the hanging issue and not something wrong in my implementation with semaphores.

Please give me a working example to implement this. Thanks!

  • 0
    TI__Guru* 96960 points

    Hi Fernando,

    What are the priorities of the two tasks? I'd have Task 1 (the one waiting for the Clock module to post the semaphore) be a higher priority than Task 2. This way Task 2 can be running and when the Clock module posts the semaphore, Task 1 will be made ready and since it is a higher priority than Task 2, Task 1 will run. When Task 1 gets back to waiting on the semaphore, Task 2 will run again.

    One note: I'm assuming that Task 1 and Task 2 are not accessing the same data. If they are, make sure to use a semaphore, or even better a gate, to protect the accesses to that memory.

    Another potential option is to change your Clock function to do the transmit itself instead of posting the semaphore. Please note the clock functions run in Swi context, so you cannot call any blocking function (e.g. UART_read in blocking mode, Semaphore_pend with a non-zero value, etc.). This approach has more restrictions, but saves you a task stack worth of memory.

    Another note: if you have Task 2 always running, the Idle task will never execute. This probably is fine in your application unless you are counting on any of the Idle functions (e.g. logging if you are using LoggerIdle or system stack checking). If Task 2 is doing some blocking, the Idle task will run. What is it receiving? If it is data from a  driver, is the driver interrupt based. If so the receive probably is blocking and the Idle task will run.

    Todd