Periodic delay in tasks--Raspberry Pi.

hobit222 wrote on Thursday, July 17, 2014:

We are running the (unsupported) port of FreeRTOS to the Raspberry Pi (latest version etc.) I’ve inherited a few changes, but as far as I know there are no changes from the base build for the Pi.

I’ve got a task that does a for-loop delay, then turns on an LED, does the delay again and turns it off. (code below)

When running the code as a task, I’m seeing the period of the output be as low as 885us and as high as 910us. When I run the task as the main (so just move the task code into main and don’t run the scheduler) and disable interrupts I get 884.4us to 885.4us (over 40k samples).

Additional data: When removing the for loop but running as a task, we see 4us period with the rare (every 1000 samples?) 10us period. Feels like there is a 6uS delay popping in there.

Am I seeing the kernel/scheduler overhead here? I’m assuming the Pi is running at a high frequency, but if it’s slower (24MHz?) that might be be reasonable (170 cycles?) though it seems high.

If it is running at a low frequency, then is there a clean way to speed it up?


void task1(void *pParam) {

    volatile int i = 0;
    while(1) {
            SetGpio(16, ON_N);
            SetGpio(17, ON_N);
            SetGpio(16, OFF_N);
            SetGpio(17, OFF_N);


void main(void) {


    SetGpioDirection(16, GPIO_OUT);                // green LED

    SetGpioDirection(17, GPIO_OUT);                 // accessable GPIO pin

    xTaskCreate(task1, "LED_0", 128, NULL, 0, NULL);


rtel wrote on Friday, July 18, 2014:

I’m afraid I know nothing about that port, or the hardware it is running on, but can ask some generic questions in the hope of a following discussion homing in on the cause -

Your task is sharing a priority with the idle task. What the idle task does depends on your FreeRTOSConfig.h settings. What happens to the timing if you run the task at priority 1 (above the idle task)?

Do you have configUSE_TIMERS set to 1 in FreeRTOSConfig.h? If so, does it make a difference if you set it to 0 (shouldn’t do, but it will eliminate another task)?

What happens if you run the same program with all caches completely disabled?

Is the device running anything else, or just that one task as per the code you posted (I don’t know how the system is booting)?

Are there any interrupts other than the tick running?


hobit222 wrote on Friday, July 18, 2014:

Yeah, we noticed a slight improvement when we moved from priority 0 to priority 1. (2us as I recall)

configUSE_TIMERS doesn’t seem to be defined, so it looks like it is defaulting to 0.

Not sure how to turn off the caches, but I’m about 95% sure it couldn’t be the issue.

It’s just running this task. There are no interrupts being set in main.c. But when I disable all interrupts by hand I see slightly better performance, so there is something.

Thanks for the help, it’s looking like it’s all issues with the port.

Out of curiosity (not that I could likely afford it), about how much would it cost to get an official port to Raspberry Pi from you?

rtel wrote on Friday, July 18, 2014:

It would be very interesting to have an official port. Its is a shame, somewhat, that it is ARM11 based rather than Cortex-A based. We have a very nice Cortex-A port, whereas interrupt nesting has always been somewhat hasslesome on the ARM7/9/11 cores.

At the moment however it is more a matter of time than money with regards to getting an official port done. We are extremely busy with lots of good things at the moment and time is really at a premium. Maybe it won’t always be like that though.

If you have any ideas in particular then you can use the “business contact” email address on .