RTOS Taking the bull by the horns
RTOS Taking the bull by the horns
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.
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.
Re: RTOS Taking the bull by the horns
Not going to happen any time soon.
Why pay for overpriced toys when you can have
professional grade tools for FREE!!!
professional grade tools for FREE!!!
Re: RTOS Taking the bull by the horns
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.
Re: RTOS Taking the bull by the horns
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 wrote: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.
Re: RTOS Taking the bull by the horns
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.
Re: RTOS Taking the bull by the horns
I am sure many will thank you for your efforts.
Re: RTOS Taking the bull by the horns
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/
It will surely be a pleasure to try it. Please don't forget to post it on Libstock please. http://www.libstock.com/
Serge T.
Learning is an endeless process but it must start somewhere!
Learning is an endeless process but it must start somewhere!
Re: RTOS Taking the bull by the horns
Hi Warren,warrendev wrote: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.
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: 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...
Kind regards, Dany.
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Re: RTOS Taking the bull by the horns
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
Kind regards, Dany.
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Re: RTOS Taking the bull by the horns
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.
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.
Re: RTOS Taking the bull by the horns
Thanks for the information!warrendev wrote: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.
that would be very nice. Thanks in advance!warrendev wrote: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.
Kind regards, Dany.
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Re: RTOS Taking the bull by the horns
Any progress?that would be very nice. Thanks in advance!warrendev wrote: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.
Kind regards, Dany.
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Re: RTOS Taking the bull by the horns
Any progress?Dany wrote:Any progress?that would be very nice. Thanks in advance!warrendev wrote: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.
Kind regards, Dany.
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Forget your perfect offering. There is a crack in everything, that's how the light gets in... (L. Cohen)
Remember when we were young? We shone like the sun. (David Gilmour)
Re: RTOS Taking the bull by the horns
Thanks Dany, will try your library
Re: RTOS Taking the bull by the horns
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
-warrendev