multitasking Problem

amarjith wrote on Saturday, November 09, 2013:

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?

rtel wrote on Sunday, November 10, 2013:

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?

Regards.

amarjith wrote on Monday, November 11, 2013:

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.

rtel wrote on Monday, November 11, 2013:

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].

Regards.

amarjith wrote on Monday, November 11, 2013:

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?

richard_damon wrote on Monday, November 11, 2013:

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.)

amarjith wrote on Tuesday, November 12, 2013:

ok thank you. let me ask one thing any port interrupt task can preempt the task with mutex??

edwards3 wrote on Tuesday, November 12, 2013:

The docs say PIC24 apps can use the ISR safe FreeRTOS functions from any interrupt running at priority 1.

richard_damon wrote on Wednesday, November 13, 2013:

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.

amarjith wrote on Wednesday, November 13, 2013:

Thank you MEdwards, Richard.