And there's also an intermediate option with the state being a pointer to a function.
I already wrote that !
Yes. With that
- the outer level of the superloop's if/the/else/case is removed
- the state-dependent event processing will often devolve back to if/then/else/case statements. That's anathaema to me since it eventually metastasises into an unmaintainable mess
There is no cure for sloppy programming.
I like C quite a lot because it gives you freedom to do almost anything you want, but it also gives you the freedom to make a mess of things, but that is entirely upto the programmer. Sloppy programmers write bad and unmaintainable code, while better programmers spend more time about maintaining and improving the structure by regular refactoring during maintenance.
I've had quite alot of experiences where it was easy to add a handful of lines of code to quickly fix a problem, but instead I spend half an hour and in the end removed a handful of lines and changed two or three other lines.
Using function pointers to implement a state machine works quite good in C++, where you can use a class for each state machine. It also works good in C if you use a separate file for each state machine and make sure you only expose sensible parts though the header files.
"Arduino" like programming is horrible. It's quite sad that lots of people with no prior experience in programming start by learning the sloppy "arduino" way of things. sure it's easy to get a LED blinking, but after that you have to unlearn half of what you learned before you can learn some proper programming.
--------------------------
I never used a PIC24 myself, but assume they've got the right stuff for an RTOS.
Rewriting an application to use an RTOS is a quite big task. Because tasks can be interrupted at any time, you have to be very careful around any communication between the different tasks. Throwing an RTOS at your application is not a magic wand that solves all your problems. Using an RTOS also makes debugging more difficult. When using an RTOS it's still bad form to use software delay loops, and these are usually replaced by some yield() funciton or a delay function which is part of the RTOS. And even when using an RTOS, it's still useful to use state machines to divide big tasks into manageable chunks.
I have not seen much of your application, but I guess it's not going to improve much by adding an RTOS. Having knowledge and experience with an RTOS is still good to have in your toolbox though. Even small microcontrollers are starting to get multiple cores, such as the ESP32 and raspi2040. I'm not sure what became of the "propeller chip", It's sort of an 8-core (or 9?) architecture, but with weird limitations and there was no C-compiler available for it for a long time (I think there is now).
Maybe it's better to keep your current application for what it is, and start using and learning with an RTOS for your next application, even if it does not directly need an RTOS.