Iam using pic24fj256gb106 and i have two tasks tasklog and taskupdate, task log is for collecting data through sensors and store it in to sd card. Task update will collect stored data from sd card and update in to the server(GSM modem). Here i want to process tasklog in every 5 seconds and taskupdate in every 10 seconds, i used DelayUntill() for both tasks to do this.The problem is that if i set higher priority for tasklog, some times the updation may take more than 5 or 10 seconds so that the task will switch to tasklog during updation process and it wont resume its process(will stuck) after completing tasklog. Could you please suggest me any solution for this problem?
Sorry I don’t understand the problem you are describing - I interpret your statement to say you want to run tasklog every 5 seconds, but sometimes it takes 10 seconds to run - in which case you can’t run it every 5 seconds whether you are using an RTOS or not.
Is it possible to optimise your drivers, so writing the logged data is faster?
My data logging occurs in every 5 seconds (tasklog priority is 3 and taskupdate is 2). The taskupdate runs only when tasklog is in blocked state,taskupdate will take more than 5 seconds to complete its process, so definitely tasklog pre-empts taskupdate. taskupdate is a process of reading sd card and update to server. My problem is when tasklog pre-empts taskupdate during memory read operation in taskupdate the entire program will stuck, memory read will not resume again.
It sounds like you may have a deadlock in your application. When it is “stuck” what is it executing? (the idle task maybe?). If you are using a debugger that has a kernel aware plug-in can you see the state that the tasks are in, and which objects (semaphores, etc.) they are waiting for [assuming your file system is protected from being accessed by two tasks simultaneously - if its not, that is probably the source of your problem].
Thank you for reply.There are two functions one is for sd card read and next is for sd card write . when ever task switching occurs either one of these two functions (SD read function or SD write function ) the execution will stuck in that particular function. Here tasklog pre-empts taskupdate during memory read operation in taskupdate and after finishing tasklog process execution returns to sd card read, but execution will stuck in that line. And now i set tasklog priority 1 just before sd read and write function and set to 3 after these functions. program worked without any problem, but i think is this proper way? or any other methods? why this happening in such functions?
Somewhere there needs to be a mutex (or equivalent) in the system so that when the SD Card is being used by one task, another task can’t start to use it too.
If the SD Card driver was multi-task aware, it could be inside the SD Card driver (that would make it OS specific, or need an OS Specific hook to do this). If the driver software is not multi-task aware, then YOU need to this (perhaps with a wrapper layer on the driver).
Basically you need to create a mutex, and before calling an SD Card routine take the mutex, and when you are done and it is ok to be interrupted, you give the mutex (if there are sequences of calls that you need to keep together, for example selecting what card to use, then using the card, these should be keep together under a single mutex take.)
ok thank you. let me ask one thing any port interrupt task can preempt the task with mutex??
The docs say PIC24 apps can use the ISR safe FreeRTOS functions from any interrupt running at priority 1.
There is no such thing as an “interrupt task”, Interrupts have service routines (a type of subroutine), which are not tasks. Tasks are software pieces managed by the OS (FreeRTOS in this case).
Mutexes to not block interrupt. That is the job of a critical section (which because it blocks interrupts needs to be kept short in execution time).
A mutex does not prevent task switches either, what it does stop is the second (or later) task that tries to take the mutex before it is released from proceed further until the mutex is released.