Need to clarify what I have done, because the next step is to extend this model to handle the SPI bus. I’m trying to prototype multiple threads accessing a common resource – the UART in this example. I also want to make sure that I can shut down the processor as much as possible while this is going on. This is not rocket science, just a RTX familiarization exercise.
I’m using RTX which is an RTOS provided by Keil, but available for free via ARM, and Nordic. It’s reasonably lightweight, and allegedly well-tried and tested. The question is can I get it to do what I need.
My test program needs to demonstrate use of a mutex to serialize access to a shared resource (the UART, as a stand-in for the SPI bus), and show that it can be driven from a variety of types of threads: the main loop, user threads, and a timer event handler.
The test program sets up five threads, three of which try to output to the UART in parallel. Here’s what each thread does:
- Following initialization crap, main() loops forever, alternately suspending itself for 1s, and then sending two “wakeup” inter-thread signals to the two user-threads, called Blinky1, and Blinky2.
- A timer-event handling thread is woken by the RTC every 100ms, and sends a text message to the UART. The message records the number of times the handler has been called.
- Blinky1, and Blinky2 simple wait for a signal from the main loop, and then try to send 10 text messages to the UART as fast as they are able.
- A fifth thread, “Idle”, runs only when all other threads are idle.
Each thread is assigned a LED which get’s turned on whenever it is the active thread.
- First, Blinky1, and Blinky2 never interleave their individual messages. Why is this?
- It is interesting how much of the time the Idle thread is running. Even though there is a lot of UART activity the Idle LED stays on almost all the time.
Here are the LED assignments, and below is a video showing the program running.