Tests Using '2012-09-18-wheezy-raspbian.img'

Using this code running:

	while (1)
	{
		bcm2835_gpio_write(RPI_GPIO_P1_13, 0);
		bcm2835_gpio_write(RPI_GPIO_P1_13, 1);
	}

Running the application at the command prompt (no GUI) gave this on the pin:

i.e. no significant process interruptions.

Running the application inside the GUI (startx) with nothing else specific happening gave this:

Very occasional process interruptions.

Now starting the Midori browser to make the RPi busy gave this:

This remained until the browser was fully loaded at which point the pin output returned to the previous state.

Sleeping

Good applications tell the linux scheduler when they are happy to be halted so another process can be run.  The scheduler is a complex beast but we have found that simply using delayMicroseconds(10) say in your programs main loop is enough to give the scheduler an opportunity to run another process and avoid it letting the your application run but periodically halt it for a significantly longer time for many other processes to be run before handing execution back to your application.  If your application needs constant fast monitoring of inputs or control of outputs then including this can help reduce the length of time your application is halted, assuming no other heavy process runs in the system (in which case you are stuffed as the scheduler will decide how to split running time between you and the other process – e.g. switching every 10mS in the Midori startup test above).  

Guaranteeing a slice of time for critical IO operations

Another approach if you need to know you are not going to be interrupted by the scheduler, for instance say you want to generate RC servo PWM signals using GPIO pins, could be to just ensure you limit your operations to less than 10mS before calling delayMicroseconds() letting the scheduler know you are happy to sleep.  This way you limit the maximum time your process needs to run before interruption to below the schedulers maximum time (often 10mS) and just accept that you don't know how long it will be before you get another slice of time, but at which point you are as sure as you can be that you will get the next block of time you need to complete another set of your IO operations.  We've not tried this, but it seems like an approach that could work well to overcome some of the real time issues of working on top of an OS and its scheduler – 10mS is a lot of time to get IO operations done.