Thread alternatives for embedded systems

Question

I'm currently studying electrical engineering. Due to the pandemics, my classes were suspended and I'm using this time learning more about electronics and programming.

I'm currently trying to use a Pic16f628a and a generic digital display to build a digital clock with some features. The thing, is that I'd had to access a menu pressing a button in execution time, while the clock is being displayed. Normally I'd call a thread for the clock display and the main thread would be watching for inputs, but due to the simplicity of the pic controller I can't use the resource.

So, my C code (not yet implemented specifically to pic) is something like this:

void display_timer(){
  static struct current_time timer;
  static int is_time_set = 0;
  set_current_time(&timer, &is_time_set);

  while (is_time_set){
    system("clear");
    printf("########\n");
    printf("%d:%d:%d\n", timer.HOURS, timer.MINUTES, timer.SECONDS);
    printf("########\n");
    sleep(1);
    update_timer(&timer, &is_time_set);
  }
}
int main ()
{
  while (1){
    display_menu();

  }
}

During the sleep(), the controller would have to be able to watch for new inputs and act correspondingly.

One alternative I though was to use a state machine to store a button press, dividing the sleep function into 4 or 8 intervals, something like this:

  while (is_time_set){
    system("clear");
    printf("########\n");
    printf("%d:%d:%d\n", timer.HOURS, timer.MINUTES, timer.SECONDS);
    printf("########\n");
    for (int i = 0; i<8; i++){
    if (state_machine_input == 1){state_machine_input = 0; break;}
    sleep(1/8);
    }
    update_timer(&timer, &is_time_set);

It could be done, but I'd appreciate if I'd not have to add more complexity to the project, adding another state machine for example. What could I do in therms of software to implement this functionality?

Answer 1

Threading is a higher level concept than microcontroller programming. Simply put, threads are implemented as a scheduler that uses timer interrupts, which in turn saves the program counter + stack pointer etc and sets those to different locations. So it is quite possible and easy to implement a similar concept using interrupts - with the benefit that you get specialized interrupts instead of generic multi-threading.

That's about the only sensible way to do it with a restricted legacy 8 bitter like PIC, which is extremely limited when it comes to stack use. Forget about using thread libs, even those written for microcontrollers. That will only add excessive bloat and complexity, for nothing gained. It is a bad idea in general to drag PC programming concepts into the embedded world.

What you should be doing, is to put your button scanning inside a cyclic timer interrupt that's executed once per 10ms or so. From inside the interrupt, you poll the buttons and compare the button read with the previous once, for debouncing purposes. The result of this is stored in a variable shared with the main program, declared as volatile and protected from race conditions. Since you only write to the variable from inside the interrupts, it may be sufficient protection to ensure that reads are 8 bits, but you must disassemble to be sure. More info about that here: Using volatile in embedded C development.

Answer 2

Use interrupts

You want to run some code when pressing a button? Use a pin-change-interrupt

You want to do something at a fixed interval? Use a timer-interrupt

In a way, the hardware of the microcontroller runs a 'thread' that monitors the interrupt sources, and runs a 'callback' or interrupt-routine for each event.

The main program is automatically paused while executing the interrupt.

A common way to share data between interrupts and main code is through volatile global variables and temporarily disable interrupts when reading data from these globals when they are more than the word-size of the controller (almost always on an 8 bit controller)

Answer 3

I would probably suggest a cooperative multitasking library. One that I have used in the past is Protothreads: http://www.dunkels.com/adam/pt/

Any decent cooperative multitasking library will help abstract away the implicit state machine required to keep track of things.

Good luck.

Answer 4

There are in general different approaches with multitasking when it comes to embedded system:

• Polling or Cooperative Multitasking: Everything is done in one infinite loop and the tasks are designed to take the minimum time possible and return to the main execution as fast as possible, to avoid delay. Note that tasks suitable for this architecture might not be what you would think of in terms of higher-level concept, for example in your application one task could be update_display and another task could be check_button and you would build a loop such as:

    while(1){
         check_buttons();
         update_display();
         sleep(0.1); //seconds
     }

• Interrupts: All possible inputs as connected to hardware interrupts and the main execution is left for things that cannot be put on interrupt (might be nothing, in which case usually the microcontroller is put in a sleep mode to reduce power consumptions. Details of how this is done usually depend on the particular microcontroller and compiler used.

• RTOS: depending on how much power the microcontroller provides, it might be possible to run a Real-Time Operating System (RTOS), which might provide with API to create tasks or even threads. This depends on the application and the hardware capabilities, and for educational examples should not be necessary (or advisable, imo)

Consider also that another important part in deciding the overall architecture of the application is the division in tasks and how they cooperate. One of the paradigms used is the State Machines (the link is to the general wikipedia page that might be overwhelming, simpler resources specific to embedded programming can be found on your textbook or on google).

Answer 5

Mostly, in 8-bit devices have limited source. I think simpler solution is better solution in 8-bit PICs.

You can create hardware Timers for 2 different tasks. Set a flag and check the flag in your infinite loop, do the task and reset the flag. Don't use delays. This method guarantees to done your tasks in your infinite loop, if your flags up.

But, you have to know that the tasks is not executed exact time when the flags up. If there was two flags set at same time you can't know which one is executed first. Because you don't know where in the infinite loop. But, it's mostly okay for not time critical interfacing applications.

Answer 6

For small embedded designs I've had a lot of success using a simple task switcher, based on RIOS. It's super simple and easy to port to any platform - all you really need is an interrupt giving you a timer tick. If you split the workload of your system into a set of state machines, with each one running as a single task, you can achieve quite complex systems with no need to use an RTOS. Each task can use static variables to preserve local state.

Basically it's a poor man's RTOS without the overhead and complexity. Every task must complete within one timer tick, so it's absolutely predictable in timing.

There is a bonus which is that this gives you a pretty decent understanding of what most OS's are doing underneath.