I have a project that will need to fit into the smallest of devices. It currently runs on a 128k, 64-pin device for testing, but will move to a 16k, 20 pin device real soon now.
As I understand things if I "tell" the project it is ChibiOS/RT it will include realtime OS features, while I probably don't need those. So I'd like to move to ChibiOS/NIL.
How do I modify my project to obtain this move?
(as ChibiOS claims to fit in "under 8k" it is not out of the question to keep using the "full" ChibiOS. I might keep it anyway, even after trying /NIL...)
Moving from "RT" to "NIL".
Moderator: RoccoMarco
- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Moving from "RT" to "NIL".
NIL is less than 1kB large and its objects take much less RAM, RT can fit under 3kB in a reduced configuration, so it is not much larger but it takes more RAM.
In order to use NIL, just take the makefile, nilconf.h and main.c from a demo, the HAL use is exactly the same. The main difference is that with NIL you declare all your tasks statically into a table and those all start together, the main() function is the idle task sitting at lowest priority.
Giovanni
In order to use NIL, just take the makefile, nilconf.h and main.c from a demo, the HAL use is exactly the same. The main difference is that with NIL you declare all your tasks statically into a table and those all start together, the main() function is the idle task sitting at lowest priority.
Giovanni
Re: Moving from "RT" to "NIL".
Oh, ok. thanks!
I regularly come across demos that have a "while (1) {/* do nothing */ } " loop, with the additional comment that the main task is the idle loop and should never sleep. This is apparently taken from a NIL example, and inappropriate for an RT example.
Should I run through all the examples I can find to correct this, do you want a patch, or git pull, or do you want to do this yourself?
I've read somewhere that the normal idle process puts the CPU in a power-saving mode, waiting for something to happen (interrupt). Is there something to call from such an idle loop that causes this to happen? (i.e. don't take the process from the "run-able" state, but put the processor in a powersaving mode until the next interrupt?)
I regularly come across demos that have a "while (1) {/* do nothing */ } " loop, with the additional comment that the main task is the idle loop and should never sleep. This is apparently taken from a NIL example, and inappropriate for an RT example.
Should I run through all the examples I can find to correct this, do you want a patch, or git pull, or do you want to do this yourself?
I've read somewhere that the normal idle process puts the CPU in a power-saving mode, waiting for something to happen (interrupt). Is there something to call from such an idle loop that causes this to happen? (i.e. don't take the process from the "run-able" state, but put the processor in a powersaving mode until the next interrupt?)
- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Moving from "RT" to "NIL".
RT can work in the same way, set CH_CFG_NO_IDLE_THREAD to TRUE and the main() becomes your idle thread.
Giovanni
Giovanni
Re: Moving from "RT" to "NIL".
Many people tend to think about their embedded project as: "first initialize everything, then handle the stuff we need to do". So, often main gets to do stuff, but when there is nothing to do, a "wait for things to do" or "wait xx ms" is appropriate. Or "open valve for 2 secs" is easy to implement as "open valve; wait 2 s; close valve". So a sleeping main is useful.
What is not useful is that the comments in some demos state that main cannot sleep, which you tell me in this thread is only the case for NIL or when CH_CFG_NO_IDLE_THREAD is set. The comments are not clear about that.
It is nice of you to tell me how things work. But if I cannot find this from the documentation in the places where I look, I expect that there are others that would follow a similar path to me, so would end up with the same questions. I would like to help out your project by making it easier for people like me that look at those demos and improve the comments there. But you ignore my offer.
Similarly you've ignored my question about putting the CPU in a lower power mode inside the "idle loop" (which for NIL or CH_CFG_NO_IDLE_THREAD you need to implement yourself).
What is not useful is that the comments in some demos state that main cannot sleep, which you tell me in this thread is only the case for NIL or when CH_CFG_NO_IDLE_THREAD is set. The comments are not clear about that.
It is nice of you to tell me how things work. But if I cannot find this from the documentation in the places where I look, I expect that there are others that would follow a similar path to me, so would end up with the same questions. I would like to help out your project by making it easier for people like me that look at those demos and improve the comments there. But you ignore my offer.
Similarly you've ignored my question about putting the CPU in a lower power mode inside the "idle loop" (which for NIL or CH_CFG_NO_IDLE_THREAD you need to implement yourself).
- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Moving from "RT" to "NIL".
rew wrote:Many people tend to think about their embedded project as: "first initialize everything, then handle the stuff we need to do". So, often main gets to do stuff, but when there is nothing to do, a "wait for things to do" or "wait xx ms" is appropriate. Or "open valve for 2 secs" is easy to implement as "open valve; wait 2 s; close valve". So a sleeping main is useful.
What is not useful is that the comments in some demos state that main cannot sleep, which you tell me in this thread is only the case for NIL or when CH_CFG_NO_IDLE_THREAD is set. The comments are not clear about that.
It is nice of you to tell me how things work. But if I cannot find this from the documentation in the places where I look, I expect that there are others that would follow a similar path to me, so would end up with the same questions. I would like to help out your project by making it easier for people like me that look at those demos and improve the comments there. But you ignore my offer.
Similarly you've ignored my question about putting the CPU in a lower power mode inside the "idle loop" (which for NIL or CH_CFG_NO_IDLE_THREAD you need to implement yourself).
You will forgive me if I am not always 100% ready answering questions on a free support forum.
I verified all the demos in 3.0, the "sleep or wait" text only appears into the NIL main.c files, could you point me to misplaced comments in demos?
The "idle task" concept should be the same in any RTOS but I should not assume knowledge about that, placing a comment in examples probably is not sufficient.
About the sleep mode, it is a question unrelated to ChibiOS, the STM32 Reference Manual is the source you need, it involves using the "wait" assembler instruction inside that loop.
Giovanni
Re: Moving from "RT" to "NIL".
you're right. I checked the STM32 RT examples on 2.6.6 and those are also all correct. I might remember it from another or a NIL example that I looked at, possibly at a time that I didn't know the difference.
I would suspect that the IDLE thread looks something like:
The "device dependent" part of "put the device to sleep" would then be better written somewhere inside the architecture port.
I just found the idle thread It calls:Can't I call that from my idle thread if I want to?
I would suspect that the IDLE thread looks something like:
Code: Select all
while (true) {
// Put the CPU to sleep.
}I just found the idle thread It calls:
Code: Select all
port_wait_for_interrupt();- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Moving from "RT" to "NIL".
hi,
Yes, you can. It does just insert the mentioned "wait" instruction.
Giovanni
rew wrote:Can't I call that from my idle thread if I want to?Code: Select all
port_wait_for_interrupt();
Yes, you can. It does just insert the mentioned "wait" instruction.
Giovanni