| Electronics > Beginners |
| reccomendations for getting started with RTOS and threading? |
| (1/2) > >> |
| cbc02009:
I've done quite a bit of programming on simple single core processors like the 328p and the ARM M0, and now I'm curious about more complicated coding techniques for small MCUs. In my senior design project we had a screen update function that we wrote by hand, but it took a long time relative to the rest of the program, and so the other, more important things would have to wait while it was running. I ran out of time to look into it, but I wondered if I could have solved that problem with threads. Does anyone have any good books or textbooks or projects they could recommend for someone to learn about these kinds of topics? I don't really know enough to even know where to begin. Thanks! |
| ggchab:
A suggestion only: you may not need RTOS on a small micro-controller. Important things can be triggered by interrupts. This will suspend the screen update function that restarts when the important things are done. You may also use timer interrupts to do things at regular intervals. Interrupts priorities may help. |
| tggzzz:
--- Quote from: ggchab on December 11, 2018, 01:24:55 pm ---Interrupts priorities may help. --- End quote --- ... in which case you have to be aware of "priority inversion". I suggest the OP: * reads a textbook on real-time programming and RTOSs. I've been doing this since the early 80s, so my textbooks are probably unobtainable! * reads about design patterns related to distributed applications, multicore processing (there's a lot of overlap!) * avoids designing applications at the mutex/semaphore level, and uses "higher" level abstractions * the Java concurrency utilities are one set of such abstractions; it is well worth understanding the underlying design patterns, even if you never use Java * do not share data between threads, but do send messages containing primitive values (i.e. no addresses!) between threads * think asynchronously; do not assume any event ordering * think in terms of FSMs: events (passed in messages), states (where a thread is waiting for an event), actions and transitions (when a thread receives an event in a state) |
| cbc02009:
--- Quote from: ggchab on December 11, 2018, 01:24:55 pm ---A suggestion only: you may not need RTOS on a small micro-controller. Important things can be triggered by interrupts. This will suspend the screen update function that restarts when the important things are done. You may also use timer interrupts to do things at regular intervals. Interrupts priorities may help. --- End quote --- Thank you, yes, it would have been overkill for the project I was working on. It was just a small thing that bothered me, but I ended up using flags to minimize its impact. --- Quote from: tggzzz on December 11, 2018, 04:48:57 pm --- --- Quote from: ggchab on December 11, 2018, 01:24:55 pm ---Interrupts priorities may help. --- End quote --- ... in which case you have to be aware of "priority inversion". I suggest the OP: * reads a textbook on real-time programming and RTOSs. I've been doing this since the early 80s, so my textbooks are probably unobtainable! * reads about design patterns related to distributed applications, multicore processing (there's a lot of overlap!) * avoids designing applications at the mutex/semaphore level, and uses "higher" level abstractions * the Java concurrency utilities are one set of such abstractions; it is well worth understanding the underlying design patterns, even if you never use Java * do not share data between threads, but do send messages containing primitive values (i.e. no addresses!) between threads * think asynchronously; do not assume any event ordering * think in terms of FSMs: events (passed in messages), states (where a thread is waiting for an event), actions and transitions (when a thread receives an event in a state) --- End quote --- Can you explain your third point? I know what mutex and semaphore are. Are you saying I should avoid them, or just ignore that level of abstration and move on to the next one? Why? |
| tggzzz:
While mutexes and semaphores are sufficient and work on a small scale, if used in a undisciplined fashion in a typical system, the system eventually becomes brittle and unmaintainable. That can best be understood after designing and implementing a system, by attempting to prove to someone else that there are no situations that could end up in deadlock or lovelock. That's extraordinary difficult, even with the use of design patterns :) Having said that, mutexes and semaphores are critical to implementing the primitives used in higher level abstractions. |
| Navigation |
| Message Index |
| Next page |