Article Index

Pi Zero Real Time FIFO Scheduling

Now we can try the same test but with FIFO real time scheduling selected.

To do this we need to use the sched_setscheduler function:


where pid is the thread id - if zero then the calling thread is used.

The second parameter sets the type of scheduling used FIFO in this case and the final parameter is a pointer to a structure that specifies the priority. 

Notice you need to include <sched.h> to make use of the scheduling functions.

The modified program is: 

#include <bcm2835.h>
#include <stdio.h>
#include <sched.h>

int main(int argc, char **argv) {
 const struct sched_param priority = {1};
 sched_setscheduler(0, SCHED_FIFO, &priority);

 if (!bcm2835_init())
   return 1;
 bcm2835_gpio_fsel(RPI_GPIO_P1_07 ,
 while (1) {
  bcm2835_gpio_write(RPI_GPIO_P1_07 , HIGH);
  bcm2835_gpio_write(RPI_GPIO_P1_07 , LOW);
 return 0;


If you run this program you will discover that the result are very different. The first thing you might notice if you have a console open is that the response is very sluggish. The reason is that your program is hoging the CPU.

If you run a logic analyzer then there is a surprise.

The program runs for one second and then it is interrupted for around 50ms.


Clearly there is something with a higher priority is now interrupting your program and probably keeping the console and other essentials alive. 

If you now run a cpu hoging task you will discover that there is no change in the behavior of your program. It runs for a second and then is interrupted for 50ms.  There is no 10ms switching between tasks - your program still gets a full 1 second of uninterrupted cpu time and this is irrespective of the cpu load.

You can also try locking the programs memory to stop the system from paging it if other applications need a lot of memory. In practice this isn't a common occurrence on a device like the Raspberry Pi but if you do need to do it then all you need is a call to mlock in sys/mman.h and to unlock to unlock it. You can lock the current memory or future memory allocations. In most cases it is sufficient to lock current memory unless you are using dynamic memory allocation. 


In the case of our test program locking memory make no difference as there is plenty of real memory to go around. 

Pi 2  Quad Core 900MHz

The single core Pi Zero has to share its single core even with a high priority FIFO process. The quad core Pi 2 and Pi 3 should behave differently because they have three cores to work with after you monopolize a whole core with your program. 

Lets see how things work with a Pi 2. 

First lets try the program without real time features. With a lightly loaded Pi 2 we have the usual 0.08 to 0.1 microsecond pulses with the usual 0.6 microsecond pulse every 0.125ms and 15 microsecond pulse every 10ms. 

When you add cpu hoging processes then at about four processes irregular 10ms pulses start to appear


The 10ms pulses correspond to periods of time when the program is swapped out and not running. It isn't regular because the four cores are shared between each of the processes. 

If you change the program to use realtime FIFO scheduling then with the same cpu load that produced the 10ms pulses you get a result that looks like a lightly loaded CPU. That is the 10ms pulses vanish and all you have to contend with are the 0.6 microsecond and 15 microsecond interruptions. 

The reason for this behavior is fairly obvious. Now your process can be run by one of the cores while the remaining three are shared between the other non-realtime processes. 

Thus for a Pi 2 or 3 near realtime Linux works better than for a single core Pi Zero or Pi 1. 

For a Pi 2 or 3 you can reasonably expect to respond within 15 microseconds. 

Practical FIFO Scheduling

Adding a simple statement makes your program hog one of the available processor cores and removes the long interruptions that occur when other threads are scheduled to run. 

You might think at this point that the best thing to do is set a maximum priority and use FIFO scheduling as soon as your program is loaded. However hogging a single core on a Raspberry Pi can have some undesirable effects. 

To avoid these it is a good idea to only enable FIFO scheduling when it is absolutely needed or to use the yield command at regular intervals.

For example if you are writing a program that has to decode an incoming pulse stream then using FIFO scheduling for the time it actually does the decoding is the best option. After the decoding is complete return to SCHED_OTHER, 

It is true that no amount of scheduling is going to convert the Raspberry Pi into a real time system. The reason is that it is not real time hardware and not configured to be. There are things the CPU has to do to keep the Pi running and these cannot be disabled. 

The best you can achieve with the Pi Zero is to effectively lock your task into its single core an keep the CPU uninterrupted for a one second period and accept the 50ms interrupt. You can only guarantee to respond to external events in 50ms. Of course you still have the  .5 microsecond interrupts every 1.25ms to take into account but unless you are working with below 1 microsecond timings these are not usually a problem.

For the quad core Pi 2 and 3 you can use one of the cores to keep your program running and only have the  0.6 microsecond pulse every 0.125ms and 15 microsecond pulse every 10ms to worry about. 

So we really do have near real time Linux if not actual real time Linux.





Now On Sale!

You can now buy a print or ebook edition of Raspberry Pi IoT in C from Amazon.


For Errata and Listings Visit: IO Press



This our ebook on using the Raspberry Pi to implement IoT devices using the C programming language. The full contents can be seen below. Notice this is a first draft and a work in progress. 

Chapter List

  1. Introducing Pi (paper book only)

  2. Getting Started With NetBeans In this chapter we look at why C is a good language to work in when you are creating programs for the IoT and how to get started using NetBeans. Of course this is where Hello C World makes an appearance.

  3. First Steps With The GPIO
    The bcm2835C library is the easiest way to get in touch with the Pi's GPIO lines. In this chapter we take a look at the basic operations involved in using the GPIO lines with an emphasis on output. How fast can you change a GPIO line, how do you generate pulses of a given duration and how can you change multiple lines in sync with each other? 

  4. GPIO The SYSFS Way
    There is a Linux-based approach to working with GPIO lines and serial buses that is worth knowing about because it provides an alternative to using the bcm2835 library. Sometimes you need this because you are working in a language for which direct access to memory isn't available. It is also the only way to make interrupts available in a C program.

  5. Input and Interrupts
    There is no doubt that input is more difficult than output. When you need to drive a line high or low you are in command of when it happens but input is in the hands of the outside world. If your program isn't ready to read the input or if it reads it at the wrong time then things just don't work. What is worse is that you have no idea what your program was doing relative to the event you are trying to capture - welcome to the world of input.

  6. Memory Mapped I/O
    The bcm2835 library uses direct memory access to the GPIO and other peripherals. In this chapter we look at how this works. You don't need to know this but if you need to modify the library or access features that the library doesn't expose this is the way to go. 

  7. Near Realtime Linux
    You can write real time programs using standard Linux as long as you know how to control scheduling. In fact it turns out to be relatively easy and it enables the Raspberry Pi to do things you might not think it capable of. There are also some surprising differences between the one and quad core Pis that make you think again about real time Linux programming.

  8. PWM
    One way around the problem of getting a fast response from a microcontroller is to move the problem away from the processor. In the case of the Pi's processor there are some builtin devices that can use GPIO lines to implement protocols without the CPU being involved. In this chapter we take a close look at pulse width modulation PWM including, sound, driving LEDs and servos.

  9. I2C Temperature Measurement
    The I2C bus is one of the most useful ways of connecting moderately sophisticated sensors and peripherals to the any processor. The only problem is that it can seem like a nightmare confusion of hardware, low level interaction and high level software. There are few general introductions to the subject because at first sight every I2C device is different, but here we present one.

  10. A Custom Protocol - The DHT11/22
    In this chapter we make use of all of the ideas introduced in earlier chapters to create a raw interface with the low cost DHT11/22 temperature and humidity sensor. It is an exercise in implementing a custom protocol directly in C. 

  11. One Wire Bus Basics
    The Raspberry Pi is fast enough to be used to directly interface to 1-Wire bus without the need for drivers. The advantages of programming our own 1-wire bus protocol is that it doesn't depend on the uncertainties of a Linux driver.

  12. iButtons
    If you haven't discovered iButtons then you are going to find of lots of uses for them. At its simples an iButton is an electronic key providing a unique coce stored in its ROM which can be used to unlock or simply record the presence of a particular button. What is good news is that they are easy to interface to a Pi. 

  13. The DS18B20
    Using the software developed in previous chapters we show how to connect and use the very popular DS18B20 temperature sensor without the need for external drivers. 

  14. The Multidrop 1-wire bus
    Some times it it just easier from the point of view of hardware to connect a set of 1-wire devices to the same GPIO line but this makes the software more complex. Find out how to discover what devices are present on a multi-drop bus and how to select the one you want to work with.

  15. SPI Bus
    The SPI bus can be something of a problem because it doesn't have a well defined standard that every device conforms to. Even so if you only want to work with one specific device it is usually easy to find a configuration that works - as long as you understand what the possibilities are. 

  16. SPI MCP3008/4 AtoD  (paper book only)

  17. Serial (paper book only)

  18. Getting On The Web - After All It Is The IoT (paper book only)

  19. WiFi (paper book only)



Related Articles

Real Raspberry Pi - Getting Started And Custom NOOBS



comments powered by Disqus