RTOS theory help. Global variables vs Mailbox/Messages? Re-usable code?

[eneuro]

I'm not sure if you can use HAL concepts in your RTOS, but next week I'll fight with LinuxCNC RTOS and HAL to exchange data between different subsystems in my developed pick & place CNC machine controled by LinuxCNC
http://linuxcnc.org/docs/html/hal/tutorial.html

[andyturk]

http://koopman.us/bess/chap19_globals.pdf

Great book, BTW. I ordered a copy after reading your post. 

[jnz]

What should you be asking yourself is if you need a separate thread for this.

By the way there is no need to expose any of this in your drivers C file. You just simply make a routine that say messages the LED blink pattern to where it needs to be. That way in other parts of your code you just call that routine and not worry about how it does that.

I know what you're saying on the need of a thread or not. In this case, yes, on certain components I absolutely must have a thread. One of the SPI devices is sort-of another processor. The data coming in on a couple of the busses is bi-directional and responses are based on logic. In the case of one of the busses, I'll have at least two threads sharing access on that. If I could get by with just making function calls, I'd love that.

As to the driver's C wrapping up into my threads... My SPI driver is RTOS-aware, so my driver now also must be RTOS aware. I'm not dealing with the SPI hardware directly just because of timing and I have a working solution already laid out for me.

I'm not using global for the bulk of the message transfer, but what I am doing with mail/messages is massively more complex than just doing it dirty. I'm skeptical it's entirely with merit.

[Berni]

In this case you might want to pass data to it using an array/struct and put a rtos lock on it. Your call from anywhere C wrapper fills the array and gives the lock. Your processing thread should wake up on that lock becoming available, take the data out and once its done take the lock out. Just make sure you use two locks. One that gets given at the begining of the C wrapper to signal the array being used and another one at the end to tell the processing thread the array is done and it should take out the data.

This is quite simple and needs no pointer throwing and keeping the pointed to data alive for long enough to be read. On the down side it causes a context switch for every time you call your wrapper and might stall the calling thread for a significant time if your processing thread takes a long time to empty out the array. One could get around that by having an array of arrays, each with its its own lock so the wrapper can fill them up and then have the processing thread do them all within one context switch, not quite that simple at this point. Might as well go back to pointer throwing at this point.

Using globals is not dirty. Just care must be taken to surround access to them using mutexes correctly. Its essentially the same thing as your RTOS aware SPI driver.

If you really want to do things right you could go read coding standards like MISRA. Most of it is over the top, but then again we don't want software bugs in an ECU getting it stuck to full throttle (Funny enough the firmware in those famous Toyotas failed a MISRA review).

[Sal Ammoniac]

If you really want to do things right you could go read coding standards like MISRA. Most of it is over the top, but then again we don't want software bugs in an ECU getting it stuck to full throttle (Funny enough the firmware in those famous Toyotas failed a MISRA review).

Another good reference is JPL's C coding standards. When your embedded system is millions of miles from Earth, you need to be a little more careful...

http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf