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:

sched_setscheduler(pid,SCHED_FIFO,&priority);

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.

The modified program is: 

#include <stdio.h>
#include <stdlib.h>
#include "mraa.h"
#include <sched.h>
int main() {
 const struct sched_param priority={1};
 sched_setscheduler(0,SCHED_FIFO,&priority);
 mraa_gpio_context pin = mraa_gpio_init(13);
 mraa_gpio_dir(pin, MRAA_GPIO_OUT);
 mraa_gpio_use_mmaped(pin,1);
 for (;;) {
  mraa_gpio_write(pin, 0);
  mraa_gpio_write(pin, 1);
 }
 return MRAA_SUCCESS;
}

If you run this program you will discover that the result are very different - no matter what the load on the CPU. 

and the frequency table is:

You can see that now the only problem is that we have around 100 pulses around 50 microseconds. Looking at the logic analyser trace reveals that there is a 50 microsecond pulse about every 10 milliseconds. 

Notice that this result is independent of CPU loading, the data above is for a heavily loaded CPU. What happens is that the program is loaded into one of the cores and it stays there as there are no other priority one programs running. All of the priority zero programs are scheduled using the other core to run. 

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 Edison 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. 

mlockall(MCL_CURRENT);

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

Practical FIFO Scheduling

Adding a simple statement makes your program hog one of the 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 priority of 99 and use FIFO scheduling as soon as your program is loaded. However sharing a single core between all of the other processes on the Edison can have some undesirable effects. 

If you try this you will discover that ever so often - about every ten minutes - the WiFi link will fail. The reason is most likely that the WiFi thread doesn't get to run sufficiently often. There are likely to be other more subtle problems.

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 FIFO scheduling it for the time it actually does the decoding is the best option. In this situation you would still have to cope with a possible 50 microsecond delay every 10 milliseconds. 

This raises the question of where the 50 microsecond delay originates?

Without more information it is difficult to be sure, but the most likely suspect is a System Management Interrupt, SMI. This is used by all Intel ICH chip sets which includes the Atom. An SMI is something that happens outside of the operating system and it is often necessary for the correct operation of the hardware. The bottom line is that SMIs cannot easily be turned off and this problem that effects all operating systems, including real time operating systems. 

At this point things get complicated and you have to start worrying about power management issues, DMA and many other things that a complex CPU and operating system does behind the scenes. 

If you can't work within the FIFO restrictions then you are probably better off finding a completely different solution - use an mcu, perhaps even the mcu on the Edison chip, or use dedicated hardware that carries out the operation away from the software like the UART or the PWM GPIO lines. More about this approach in the next chapter.  

More Information

The starting point for finding out about all Intel's Internet of Things resources, including Edison, is the Intel IoT Developer Zone.

Exploring Edison

USA and World  Amazon.com
Canada              Amazon.ca
UK                      Amazon.co.uk
France                Amazon.fr
Germany            Amazon.de
Spain                  Amazon.es
Brazil                  Amazon.br
Italy                    Amazon.it
Japan                 Amazon.co.jp
Mexico               Amazon.com.mx 

<ASIN:1871962447>

More Information

Edison Getting Started

Edison Software Downloads

Edison IDE Installers

Intel IoT Developer Kit

Related Articles

Powerful New Features For Edison 

Intel Announces IoT Platform       

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

<ASIN:B00ND1KH42@COM>

<ASIN:B00ND1KNXM>

<ASIN:B00ND1KH10>