• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 654 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.

RTOS/TMS320C6655: Dynamic SWI priority changes and preemption

Amanda
Prodigy 190 points

Part Number: TMS320C6655

Tool/software: TI-RTOS

I'll outline my system first and then describe the bug I'm trying to fix

I have a state machine that repeats once a second. Within the state machine, it goes through 5 data processing stages (idle, get data, windowing, FFT, processing). At the end of one state, a SWI_self is posted and on the next call, the state machine will go to the next stage. When the stages are complete before the one second is up, the state machine is in idle. This state machine is running in a SWI with priority 5. Every so often, various messaging SWIs (priority 3) run to send information about the state of the processing to higher level software. There are two SWis (priority 4) that are responsible for asynchronous function execution (ex: debug commands) - one to set parameters and one to get them.

My bug is that there is a small amount of time (due to the post_self) between state changes in the priority 5 SWI and the scheduler is letting the priority 4 Set SWIs run. The problem with this, is that by doing this, I am allowing the data to change as I am measuring/calculating it. (Not a good idea to change this data midway though processing!). I have been trying to find a way to "close up" those time gaps within the state machine state changes and have not yet been successful. The SWI messaging at priority 3 need to be lower priority than the set/gets (at priority 4).

I have tried playing with the priority levels and that hasn't been successful. I have tried to have a priority 4 SWI looping run in the gaps so the Set SWI doesn't have a chance to run, but this affects the notifications (priority 3) that need to be sent up. I haven't been able to think up a feasible way to use SWI_disable because my state machine relies on calling itself to change states. Some RTOS documentation stays that SWIs have dynamically changeable priorities (pg 51 of SPRUEX3Q) but I haven't found any other evidence to support this. If I could lower the priority of the Set to 2 while the state is in anything but Idle, that *may* work.

Would anyone have any suggestions on how to tackle this?