apullin2 wrote on Thursday, July 09, 2015:
OK, I am stuck on something, and I have a feeling that it is probably something fundamental/basic that I need to get a handle on:
I have two tasks at different software priority levels (dsPIC, so only 1 hw priority level active for tasks). The higher priority task does some checks, sometimes kicks something into a queue, then calls taskYIELD(). The lower priority task blocks on waiting for stuff to come into that queue.
The ops the lower priority task does on the queue data is much slower than everything else, so I want that at a lowest priority. The problem is that the higher priority task totally blocks the lower priority one, not even executing the code in the task that comes before the for(;;){} loop in the task.
If I put both tasks at the same priority, then it works (as far as I can tell). But I thought taskYIELD() would voluntarily halt that higher priority task for the remainder of the time slice, so then a lower priority task could be serviced for the rest of the time slice? Like I said, I’m not hitting a breakpoint at all that is on the first line of the lower priority task.
The code itself is visible at:
https://github.com/apullin/octoroach_freertos/blob/work_save/lib/radio_freertos.c#L814 (the high priority task)
although this code is a cobbled krufty mess still, so you will not be able to glean much from just a look.
It occurs to me that I can rewrite the task as two separate tasks, and put a few semaphores between them so that everything ends up blocking waiting for some event signal from the hardware … it just seemed less obvious to divide it into two tasks that compete for the state of the peripheral, as part of the same driver.
As always, I am just a novice working on an academic project, and any input is welcome and appreciated.
Thanks,
Andrew