Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Periodic delay in tasks--Raspberry Pi.

Posted by hobit222 on July 17, 2014

Hello, 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?

Thanks. Mark


void task1(void *pParam) {

    volatile int i = 0;
    while(1) {
            SetGpio(16, ON_N);
            SetGpio(17, ON_N);
            for(i=0;i<2000;i++);
            SetGpio(16, OFF_N);
            SetGpio(17, OFF_N);
            for(i=0;i<2000;i++);
    }

}

void main(void) {

    DisableInterrupts();
    InitInterruptController();

    SetGpioDirection(16, GPIO_OUT);                // green LED

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

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

    vTaskStartScheduler();

Periodic delay in tasks--Raspberry Pi.

Posted by rtel on 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?

Regards.


Periodic delay in tasks--Raspberry Pi.

Posted by hobit222 on July 18, 2014

Thanks, 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?


Periodic delay in tasks--Raspberry Pi.

Posted by rtel on 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 http://www.freertos.org/contact .

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists