Electronic – Elegant structure for coding embedded systems in C

I haven't had much personal experience with RTOS's other than QNX (which is great on the whole but it's not cheap and I have had a really bad experience with a particular board vendor and QNX's we-don't-care attitude for systems other than their most common) which is too large for PICs and MSP430's.

Where you will benefit from an RTOS is in areas such as

• thread management/scheduling
• inter-thread communications + synchronization
• I/O on systems with stdin/stdout/stderr or serial ports or ethernet support or a filesystem (not an MSP430 or PIC for the most part, except for the serial ports)

For peripherals of a PIC or MSP430: for serial ports I'd use a ring buffer + interrupts... something I write once per system and just reuse; other peripherals I don't think you'd find much support from an RTOS, as they are so vendor-specific.

If you need timing that is rock-solid to the microsecond, an RTOS probably won't help -- RTOS's have bounded timing, but typically do have timing jitter in their scheduling due to context switching delays... QNX running on a PXA270 had jitter in the tens of microseconds typical, 100-200us maximum, so I wouldn't use it for stuff that has to run faster than about 100Hz or which needs timing much more accurate than about 500us. For that kind of stuff you probably will have to implement your own interrupt handling. Some RTOS's will play nicely with that, and others will make it a royal pain: your timing and their timing may not be able to coexist well.

If the timing/scheduling is not too complex, you may be better off using a well-designed state machine. I would highly recommend reading Practical Statecharts in C/C++ if you haven't already. We've used this approach in some of our projects where I work, and it's got some real advantages over traditional state machines for managing complexity.... which is really the only reason you need an RTOS.

You can use global variables successfully, as long as you keep in mind @Phil's guidelines. However, here are some nice ways to avoid their issues without making the compiled code less compact.

1. Use local static variables for persistent state that you only want to access inside one function.

   #include <stdint.h>
   void skipper()
   {
       static uint8_t skip_initial_cycles = 5;
       if (skip_initial_cycles > 0) {
           skip_initial_cycles -= 1;
           return;
       }
       /* ... */
   }
   

2. Use a struct to keep related variables together, to make it clearer where they should be used and where not.

   struct machine_state {
        uint8_t level;
        uint8_t error_code;
   } machine_state;
   
   struct led_state {
       uint8_t red;
       uint8_t green;
       uint8_t blue;
   } led_state;
   
   void machine_change_state()
   {
       machine_state.level += 1;
       /* ... */
       /* We can easily remember not to use led_state in this function. */
   }
   
   void machine_set_io()
   {
       switch (machine_state.level) {
       case 1:
           PIN_MACHINE_IO_A = 1;
           /* ... */
       }
   }
   

3. Use global static variables to make the variables visible only within the current C file. This prevents accidental access by code in other files due to naming conflicts.

   /* time_machine.c */
   static uint8_t current_time;
   /* ... */
   
   /* delay.c */
   static uint8_t current_time; /* A completely separate variable for this C file only. */
   /* ... */
   

As a final note, if you are modifying a global variable within an interrupt routine and reading it elsewhere:

• Mark the variable volatile.
• Make sure it is atomic for the CPU (i.e. 8-bit for an 8-bit CPU).

OR

• Use a locking mechanism to protect access to the variable.