Hi,
I have many LEDs indicating various status and errors. They all blink at different frequencies, different number of blinks, different on states and different off state. And for each error I have a flag.
I need to implement all that functionality in a single task and without locking.
Any tips on how to implement it efficiently and elegantly?
When confronted with similar behaviors in the past I have implemented a set of simple state machine functions to manage the blink state of each led. These functions would not block and would check the current system tick counter and the led state to determine the next required state.
there are certainly many ways to do this but here is one idea:
That is potentially much simpler, because you can schedule the timer callback to a reasonable rate for updating the LED state. You would still use the LED state machine functions and just make each one a timer callback running at a suitable rate. Take a look here for a timer example:
Iāll second Richardās suggestion, the only potential drawback being that your LED logic in that scenario also ācompetesā with all other FreeRTOS software timers. If all behave well (ie donāt starve the timer chain), it wouldnāt be a problem. but if you really need a dedicated task for only your LED timers, you could clone and strip down FreeRTOSās timer task to act ask your LED control task. After all, FreeRTOS software timers pretty much are a generic solution for exactly your problem.
Thank you all,
because every LED has also a sequence of error codes depending on how many errors have been assigned to that LED, I assume going with the software timers I would then:
create one software timer for each LED
create a state machine within each software timer callback which then takes care of sequencing through all the error codes one after the other
Yes, I would have each LED on a separate software timer that has a simple state machine (maybe even just a sequence list) that defines its blinking. Software times are ācheapā enough that there is no need to add the complexity to decide which LED needs the next servicing to combine them.
I am getting these errors for each xTimerStart() inside the in the StartLEDsSoftwareTimers():
build/default/production/_ext/1360937237/panel_UI_control.o: In function `StartLEDsSoftwareTimers':
d:/dropbox (tdl)/tdl design/rational/firmware_2021_op60_rtos/firmware/src/panel_ui_control.c:113: undefined reference to `xTimerGenericCommand'
d:/dropbox (tdl)/tdl design/rational/firmware_2021_op60_rtos/firmware/src/panel_ui_control.c:114: undefined reference to `xTimerGenericCommand'
d:/dropbox (tdl)/tdl design/rational/firmware_2021_op60_rtos/firmware/src/panel_ui_control.c:115: undefined reference to `xTimerGenericCommand'
But now the following error came up but cannot find any documentation on vApplicationDaemonTaskStartupHook() or where it is located.
Do I need to include some other .h or some other variable/#define?
Also generally, do I need to either create or start the timers AFTER some freeRTOS initialization of some sort?
Error:
build/default/production/_ext/404212886/timers.o: In function `prvTimerTask':
d:/dropbox (tdl)/tdl design/rational/firmware_2021_op60_rtos/firmware/src/third_party/rtos/freertos/source/timers.c:564: undefined reference to `vApplicationDaemonTaskStartupHook'
That says you have #define configUSE_DAEMON_TASK_STARTUP_HOOK 1 which means you need to define the function yourself (or change the option to 0). All function that begin like vApplicationā¦ are user defined functions, which when enabled by the appropriate define in FreeRTOSConfig.h are called at the appropriate point by FreeRTOS. That hook is called at the start of the Timer Task to allow your application to do some initial initializations after FreeRTOS starts if needed rather than needing you to define your own startup task. (I rarely use that option myself).