Multitasking on PIC microcontrollers

Question

Multitasking is important these days. I wonder how we can achieve it in microcontrollers and embedded programming. I am designing a system which is based on a PIC microcontroller. I have designed its firmware in MplabX IDE using C and then designed an application for it in Visual Studio using C# .

Since I've gotten used to using threads in C# programming on the desktop to implement parallel tasks, is there a way to do the same in my microcontroller code? MplabX IDE provides pthreads.h but it is just a stub with no implementation. I know there is FreeRTOS support but using that makes your code more complex. Some forum says that interrupts can also be used as multi tasking but I don't think interrupts are equivalent to threads.

I am designing a system which sends some data to a UART and at the same time it need to send data to a website via (wired) ethernet. A user can control the output through the website but the output turns ON/OFF with a delay of 2-3 sec. So that is the problem I am facing. Is there any solution for multi tasking in microcontrollers?

Answer 1

There are two main types of multitasking operating systems, preemptive and cooperative. Both allow multiple tasks to be defined in the system, the difference is how the task switching works. Of course with a single core-processor only one task is actually running at a time.

Both types of multitasking OS's require a separate stack for each task. So this implies two things: first, that the processor allows stacks to be placed anywhere in RAM and therefore has instructions to move the stack pointer (SP) around -- i.e. there is no special purpose hardware stack like there is on the low-end PIC's. This leaves out the PIC10, 12 and 16 series.

You can write an OS almost entirely in C, but the task switcher, where the SP gets move around has to be in assembly. At various times I've written task switchers for the PIC24, PIC32, 8051, and 80x86. The guts are all quite different depending on the architecture of the processor.

The second requirement is that there is enough RAM to provide for multiple stacks. Usually one would like at least a couple hundred bytes for a stack; but even at just 128 bytes per task, eight stacks is going to require 1K bytes of RAM -- you don't have to allocate the same size stack for each task though. Remember you need enough stack to handle the current task, and any calls to its nested subroutines, but also stack space for an interrupt call since you never know when one is going to occur.

There are fairly simple methods to determine how much stack you are using for each task; for example you can initialize all of the stacks to a particular value, say 0x55, and run the system for a while and then stop and examine memory.

You don't say what kind of PIC's you want to use. Most PIC24's and PIC32's will have plenty of room to run a multitasking OS; the PIC18 (the only 8-bit PIC to have stacks in RAM) has a maximum RAM size of 4K. So that's pretty iffy.

With cooperative multitasking (the simpler of the two), task switching is only done when the task "gives up" its control back to the OS. This happens whenever the task needs to call an OS routine to perform some function which it will wait for, such as an I/O request or timer call. This makes it easier for the OS to switch stacks, since it is not necessary to save all of the registers and state information, the SP can just be switched to another task (if there are no other tasks ready to run, an idle stack is given control). If the current task doesn't need to make an OS call but has been running for a while, it needs to give up control voluntarily to keep the system responsive.

The problem with cooperative multitasking is if the task never gives up control, it can hog the system. Only it and any interrupt routines that happen to be given control can run, so the OS will seem to lock up. This is the "cooperative" aspect of these systems. If a watchdog timer is implemented that is only reset when a task switch is performed, then it is possible to catch these errant tasks.

Windows 3.1 and earlier were cooperative operative systems, which is partly why their performance wasn't so great.

Preemptive multitasking is more difficult to implement. Here, tasks are not required to give up control manually, but instead each task can be given a maximum amount of time to run (say 10 ms), and then a task switch is performed to the next runable task if there is one. This requires arbitrarily stopping a task, saving all of the state information, and then switching the SP to another task and starting it. This makes the task switcher more complicated, requires more stack, and slows the system down a little bit.

For both cooperative and preemptive multitasking, interrupts can occur at any time which will temporarily preempt the running task.

As supercat points out in a comment, one advantage cooperative multitasking has is it is easier to share resources (e.g. hardware like a multi-channel ADC or software like modifying a linked list). Sometimes two tasks want access to the same resource at the same time. With preemptive scheduling, it would be possible for the OS to switch tasks in the middle of one task using a resource. So locks are necessary to prevent another task from coming in and accessing the same resource. With cooperative multitasking, this not necessary because the task controls when it will release it self back to the OS.

Answer 2

Threading is provided by an operating system. In the embedded world we don't usually have an OS ("bare metal"). So this leaves the following options:

• The classic main polling loop. Your main function has a while(1) which does task 1 then does task 2...
• Main loop + ISR flags: You have an ISR which does the time-critical function and then alerts the main loop via a flag variable that the task needs service. Perhaps the ISR puts a new character in a circular buffer, and then tells the main loop to handle the data when it is ready to do so.
• All ISR: Much of the logic here is executed from the ISR. On a modern controller like an ARM which has multiple priority levels. This can provide a powerful "thread-like" scheme, but can also be confusing to debug so it should be reserved only for critical timing constraints.
• RTOS: An RTOS kernel (facilitated by a timer ISR) can allow for switching between multiple threads of execution. You mentioned FreeRTOS.

I would advise you use the simplest of the above schemes that will work for your application. From what you describe, I would have the main loop generating packets and placing them into circular buffers. Then have a UART ISR based driver that fires whenever the previous byte is done sending until the buffer is sent, then waits for more buffer content. Similar approach for the ethernet.

Answer 3

As in any single-core processor doing real software multitasking is not possible. So you must take care to switch between multiple tasks one way. The different RTOS are taking care of that. They have a scheduler and based on a system tick they will switch between different tasks to give you a multitasking capability.

The concepts involved in doing so (context saving and restoring) are quite complicated, so doing this manually is probably going to be difficult and makes your code more complex and because you have never done that before, there will be errors in it. My advice here would be to use a tested RTOS just like FreeRTOS.

You mentioned that interrupts provide a level of multitasking. This is sort of true. The interrupt will interrupt your current program at any point and execute the code there, it's comparable to a two task system where you have 1 task with low priority and another with high priority which finishes inside one time-slice of the scheduler.

So you could write an interrupt handler for a recurring timer which will send a few packets over the UART, then let's the rest of your program execute for a few milliseconds and send the next few bytes. That way you sort of get a limited multitasking capability. But you will also have a rather long interrupt which might be a bad thing.

The only real way to get to do multiple tasks at the same time on a single-core MCU is to use the DMA and peripherals as they work independent of the core (DMA and MCU share the same bus, so they work a bit slower when both are active). So while the DMA is shuffling the bytes to the UART your core is free to send the stuff to the ethernet.

Answer 4

The other answers already described the most used options (main loop, ISR, RTOS). Here's another option as a compromise: Protothreads. It is basically a very lightweight lib for threads, that uses the main loop and some C macros, to "emulate" an RTOS. Of course it's no full OS, but for "simple" threads it can be useful.

Answer 5

My basic design for a minimal time-sliced RTOS haven't changed much over several micro families. It's basically a timer interrupt driving a state machine. The interrupt service routine is the OS kernel while the switch statement in the main loop is the user tasks. Device drivers are interrupt service routines for I/O interrupts.

The basic structure is as follows:

unsigned char tick;

void interrupt HANDLER(void) {
    device_driver_A();
    device_driver_B();
    if(T0IF)
    {
        TMR0 = TICK_1MS;
        T0IF = 0;   // reset timer interrupt
        tick ++;
    }
}

void main(void)
{
    init();

    while (1) {
        // periodic tasks:
        if (tick % 10 == 0) { // roughly every 10 ms
            task_A();
            task_B();    
        }
        if (tick % 55 == 0) { // roughly every 55 ms
            task_C();
            task_D();    
        }

        // tasks that need to run every loop:
        task_E();
        task_F();
    }
}

This is basically a cooperative multitasking system. Tasks are written to never enter an infinite loop but we don't care because the tasks run within an event loop so the infinite loop is implicit. This is a similar style of programming to event-oriented/nonblocking languages like javascript or go.

You can see an example of this style of architecture in my RC transmitter software (yes, I actually use it to fly RC airplanes so it's somewhat safety critical to prevent me crashing my planes and potentially killing people): https://github.com/slebetman/pic-txmod. It has basically 3 tasks - 2 real-time tasks implemented as stateful device drivers (see the ppmio stuff) and 1 background task implementing the mixing logic. So basically it's similar to your web server in that it has 2 I/O threads.

Answer 6

While I appreciate that the question specifically asks about the use of an embedded RTOS, it occurs to me that the broader question being asked is "how to achieve multitasking on an embedded platform".

I would strongly advise you to forget about using an embedded RTOS at least for the time being. I advise this because I think it is essential to first learn about how to achieve task 'concurrency' by means of extremely simple programming techniques consisting of simple task schedulers and state machines.

To extremely briefly explain the concept, each module of work that needs to be done (i.e. each 'task') has a particular function that must be called ('ticked') periodically for that module to do some stuff. The module retains its own current state. You then have a main infinite loop (the scheduler) that calls the module functions.

Crude illustration:

for(;;)
{
    main_lcd_ui_tick();
    networking_tick();
}


...

// In your LCD UI module:
void main_lcd_ui_tick(void)
{
    check_for_key_presses();
    update_lcd();
}

...

// In your networking module:
void networking_tick(void)
{
    //'Tick' the TCP/IP library. In this example, I'm periodically
    //calling the main function for Keil's TCP/IP library.
    main_TcpNet();
}

Single-threaded programming structure like this whereby you periodically call main state machine functions from a main scheduler loop is ubiquitous in embedded programming, and this is why I would strongly encourage the OP to be familiar and comfortable with it first, before diving straight into using RTOS tasks/threads.

I work on a type of embedded device that has a hardware LCD interface, internal web server, email client, DDNS client, VOIP, and many other features. Although we do use an RTOS (Keil RTX), the number of individual threads (tasks) used is very small and most of the 'multitasking' is achieved as described above.

To give a couple of examples of libraries that demonstrate this concept:

1. The Keil networking library. The whole TCP/IP stack can be run single-threaded; you periodically call main_TcpNet(), which iterates the TCP/IP stack and any other networking option you have compiled in from the library (e.g. the web server). See http://www.keil.com/support/man/docs/rlarm/rlarm_main_tcpnet.htm. Admittedly, in some situations (possibly outside of the scope of this answer) you do reach a point where it starts to become beneficial or necessary to use threads (particularly if using blocking BSD sockets). (Futher note: The new V5 MDK-ARM actually spawns a dedicated Ethernet thread - but I'm just trying to provide an illustration.)

2. The Linphone VOIP library. The linphone library itself is single-threaded. You call the iterate() function at a sufficient interval. See http://www.linphone.org/docs/liblinphone-javadoc/org/linphone/core/LinphoneCore.html#iterate(). (Bit of a poor example because I used this on an embedded Linux platform and linphone's dependency libraries undoubtedly spawn threads, but again it's to illustrate a point.)

Going back to the specific problem outlined by the OP, the problem seems to be the fact that UART communication must take place at the same time as some networking (transmitting packets via TCP/IP). I don't know what networking library you're actually using, but I'd assume it has a main function that needs to be called frequently. You would need to write your code that deals with UART data transmission/reception to be structured in a similar way, as a state machine that can be iterated by periodic calls to a main function.