Hello guys,
This is a silly question: Can software timers be used to start the scheduler? Example, I want the scheduler to start only X seconds after a device has been powered on. If possible, how to do it?
Thank you
No, you cannot use software timers before starting the scheduler because software timers require the scheduler to be running. Can you not use hardware timer for this?
1 Like
Thank you,
Surely I could use a hardware timer. Just thought it might be easier if I just use the FreeRTOS timer.
Just for testing before deciding to set a hardware timer (as the systick cannot be used), I have tried to make some artificial delay using an empty FOR loop, but it does not work as it is supposed to be(not delay happen at all). Then realized that setting the optimization level to 0 (with Keil) the artificial delay works fine, but then some tasks started to malfunction⌠Anyway, looks like I cannot escape from setting the hardware timer
Simple or seemingly useless counting loops as delay will usually optimized out as you âve seen. From the compiler point of view such loops ARE useless. Thatâs a common problem and there are numerous problem reports and solutions.
Using a volatile count variable should be enough to keep the delay loop even with with optimizer enabled.
One question comes, do you really need to delay the SCHEDULER, or do you only need to delay some of the tasks starting?
Itâs hard to see a reason you want to hold off starting the scheduler for a period of time, but I can easily see wanting to hold off SOME of the operations of the system. Starting the scheduler immediately, but holding off on some operations for a bit might make sense.
1 Like
Thank you,
I will verify this. Not really using an empty loop to create delays in production, but for the sake of testing something quick, itâs worth to try it
Thank you,
Actually, I would like to prevent some processes from starting X seconds after the scheduler has started. But because I am using several DMAs that are continuously getting data from peripherals, and this data needs to be synchronized with some tasks, seemed to me easier if I just waited for the hardware to be ready before starting the whole process
The problem with trying to do stuff before the scheduler, is that this tends to mean the interrupt are disabled, or your ISRs need to check if the scheduler has started and act differently (and waste the time of the check after the scheduler has started.
Seems better to start the scheduler, and have those tasks that need to sync to the DMA to begin with a wait for the signal from the DMA before starting to do their work.
Right, have to think the best way to do it
It might become in a dead end, because precisely some processes I want to prevent from starting are DMAs until all the hardware has been initialized and stable. The tasks will be waiting for notifications from DMA ISRs, which in turn hasnât been started yet.
I think will set a hardware timer so to avoid all this bug prone situation
Thank you
DMAs arenât Tasks, and something is wrong with your specifications if a task canât start until a DMA transfer that it needs to start is done.
I suspect you need to go over a formal specification of what needs to wait for what.
It sounds like you have some DMA transfers that need to wait for some period before they start, and then that task waits for the DMA to finish.
Well, I am new to FreeRTOS and actually havenât sit to formally make a design of the process.
I have an LTE/GPS system, and when I power on the hardware need to wait 6s so the LTE starts accepting/responding to AT commands(commands sent before 6s are lost).For that transfer process I have setup a DMA and 1 task in charge of this communication process.
The GPS module, once powered on, starts sending NMEA sentences. I have set up a DMA in charge of continuously receive GPS data, but I donât want to process it until I get the first fix which happens about 10s after power on. So, I want to wait at least 10 seconds before DMA starts sending notifications to the task in charge of processing GPS data
Because the DMA ISRs donât make any processing, they just send a notification to the correspondent task once the data has been received. Tasks are blocked waiting for the notification to start processing. Any processing during the first 10 seconds are useless.
This is the first time I am using FreeRTOS and cannot get all the potencial out of it. That is why I thought the most convenient was delay the scheduler at least 6s after power on. it seemed easier to me to start it when the hardware was stable
Often I found it handy that the task itself inits the peripheral itâs using especially if you have a 1:1 mapping (1 peripheral: 1 post-processing task). Then you have all the comfort of a running FreeRTOS application (proper delays, timers, event signaling) to implement a state machine handling the init phase and later on the real post-processing.
Just my 2 ct. Good luck !
1 Like
Having done stuff like this, you WILL want to start FreeRTOS right away, then you have your task that is to handle the GPS first wait for the GPS to âwake upâ, You can just wait that 6 seconds, but that timing is often only approximate, so normally I will wait a couple of seconds then a couple of times a second send a âpingâ message to see if the device is responding. And when it is it going start up the message reception. The receiving task looks at the message, and confirms that the message says it is locked, and if so processes the data, otherwise it discards it (maybe doing something to note the lack of lock).
A big thing you have to watch out for is you can lose GPS lock after you get it, so you need to have a plan for what to do there.
Thank you all guys for your advice