RTOS Taking the bull by the horns

[seulater]

It dumbfounds me that a large part of the community is not up in arms that ME has not come out with a RTOS yet.
It been over 5 years now that I have asked the ME come out with a RTOS, or even something that resembles the ability to have multiple threads. I cannot believe they still do not have a solution for this. It's mind boggling really. With the speeds getting faster and faster for uP's it just dont make any sense what so ever to NOT be running in an RTOS environment.

So what, ME wants me to use say the new PIC32MZ @ 200MHZ and sit there in a while loop waiting for the user to press a button to continue. Meanwhile all my sensors that need to be read continuously for alarm events go unread because i am stuck in a while loop. Absurd.
Sure there will be advocates for ME saying set up interrupts and while your in the while loop call a function to read the sensors. That is a backwards way to accomplish these sorts of tasks which the RTOS takes care of simply.

ME Someone needs to take the bull by the horns and fire up the community to force your hand to get with the program and come out with a RTOS or RTOS like features. It high time you set your priorities properly. As things continue to speed up and cost less you are going to find yourself in a bad spot in the near future because you do not provide a solution to this.

[rmteo]

Not going to happen any time soon.

[warrendev]

I've done the work of porting FreeRTOS to run with the mikroC Pro for PIC32. I'm running It now with PIC32MX devices, and will make a port for PIC32MZ device later. I am testing the port and fine tuning stack usage during context switching. I plan to share my work with FreeRTOS.org.

[seulater]

I've done the work of porting FreeRTOS to run with the mikroC Pro for PIC32. I'm running It now with PIC32MX devices, and will make a port for PIC32MZ device later. I am testing the port and fine tuning stack usage during context switching. I plan to share my work with FreeRTOS.org.

warrendev, That is awesome! But i fear that the next road block is going to be ME again. Last time I checked, a few months back ME does not even support the PIC32MZ.

[warrendev]

Maybe ME does not support the PIC32MZ. When they do I can use what I've learned to create a FreeRTOS port for it. A larger memory block is needed to store the additional registers of the PIC32MZ. Currently, I am running 3 FreeRTOS tasks for testing purposes, and I am tracking down a small stack alignment problem. Once I resolve this last issue, I will make the port available to those who want to use it and to FreeRtOS.org. I am going to use this FreeRTOS port on my next development project with the PIC32MX, and I wanted to use mikroC rather than the MPLAB toolset. The cool thing is that the FreeRTOS memory footprint is quite small, only taking up about 2% of 512k.

[seulater]

I am sure many will thank you for your efforts.

[Toley]

Hi warrendev,

It will surely be a pleasure to try it. Please don't forget to post it on Libstock please. http://www.libstock.com/

[Dany]

I've done the work of porting FreeRTOS to run with the mikroC Pro for PIC32. I'm running It now with PIC32MX devices, and will make a port for PIC32MZ device later. I am testing the port and fine tuning stack usage during context switching. I plan to share my work with FreeRTOS.org.

Hi Warren,

I am also busy with an RTOS for PIC32 in mikroPascal, see http://www.mikroe.com/forum/viewtopic.php?f=172&t=64439. It is a "cooperative" Rtos, in contrary to FreeRTOS which is pe-emptive (I think). As you can see in the forum post I have a problem related to the access of local variables in tasks.

So, I have a few questions with respect to your PIC32 C implementation of FreeRTOS (PIC32MX..):

- do you also save and restore the stackpointer when a task is left/entered by the scheduler?
- If so, how do you make sure that there is enough stack space available (pointed to by the stackpointer in the tasks "stack") to allow calls to other procedures and interrupts? I see in that context that creating a task involves a parameter called "StackSize". How do you calculate this size?
- If not, how do you make sure that the task can access its local variables (in mP they are accessed via the stackpointer, I do not know how the mC compiler does that)?

This is the documentation about the already existing PIC18 and PIC24 versions:

CRTOS.pdf

(1.34 MiB) Downloaded 328 times

Thanks in advance for your info!

Added: In the mean time I found the online chapters "Thread Local Storage Pointers" and "Stack Usage and Stack Overflow Checking". I think they will help me to proceed...

[Dany]

Hi, in the mean time there is a preliminary version of the CRTOS library for PIC32, see http://www.mikroe.com/forum/viewtopic.php?f=172&t=64546

[warrendev]

Hello!

In answer to your questions:
1) Yes the stack pointer is saved/restored when leaving/entering a task. A task stack is allocated for each running task, and this task stack contains space for saving task context, as well as stack used for task variable storage and function call stack.
2) Task stack usage can be calculated, and total stack depth used during the life of a thread can be determined and controlled through limiting function call nesting and auto variables.
3) As mentioned above, a stack is allocated for each individual task, and the stack pointer is loaded with the address of the stack of the task that is currently running.

I have been running my port of FreeRTOS for well over 30 days now. I have one remaining small issue that I need to resolve, but I just haven't had time to work on it. I'll get back to working on it after Memorial day, and when I resolve this last issue I will post it in LibStock.

[Dany]

1) Yes the stack pointer is saved/restored when leaving/entering a task. A task stack is allocated for each running task, and this task stack contains space for saving task context, as well as stack used for task variable storage and function call stack.
2) Task stack usage can be calculated, and total stack depth used during the life of a thread can be determined and controlled through limiting function call nesting and auto variables.
3) As mentioned above, a stack is allocated for each individual task, and the stack pointer is loaded with the address of the stack of the task that is currently running.

Thanks for the information!

I have been running my port of FreeRTOS for well over 30 days now. I have one remaining small issue that I need to resolve, but I just haven't had time to work on it. I'll get back to working on it after Memorial day, and when I resolve this last issue I will post it in LibStock.

that would be very nice. Thanks in advance!

[Dany]

I have been running my port of FreeRTOS for well over 30 days now. I have one remaining small issue that I need to resolve, but I just haven't had time to work on it. I'll get back to working on it after Memorial day, and when I resolve this last issue I will post it in LibStock.

that would be very nice. Thanks in advance!

Any progress?

[Dany]

I have been running my port of FreeRTOS for well over 30 days now. I have one remaining small issue that I need to resolve, but I just haven't had time to work on it. I'll get back to working on it after Memorial day, and when I resolve this last issue I will post it in LibStock.

that would be very nice. Thanks in advance!

Any progress?

Any progress?

[ilferrari]

Thanks Dany, will try your library

[warrendev]

I've been away from this work for awhile. Been very busy with RTOS framework development on NXP Kinetis ARM devices and on STM32 ARM devices. But now I want to get back to the FreeRTOS port that I was working on for PIC32 and MikroC and complete it. Where I left of was that I had got a FreeRTOS building and running 3 tasks with the MikroC for PIC32 compiler, but the stack pointer was offset by 4 bytes. I've just set up my dev environment again for this, and will get back on it this week. I want very much to complete this effort and provide a library to LIbStock.

-warrendev