FreeRTOS

XCore Project reviews, ideas, videos and proposals.
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

FreeRTOS

Post by Bianco »

Hello,

I have just released my FreeRTOS XMOS XS1 port: http://www.xcore.com/projects/freertos-port

Any feedback is welcome, especially about running the demo on other boards than the XC-1 and API calls that i did not tested (are listed in the readme file in the Demo directory).


Corin
Experienced Member
Posts: 66
Joined: Fri Dec 11, 2009 3:38 pm

Post by Corin »

Very nice!
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

Wow that's cool

What's the overhead (memory etc..)
Are you using native threads or virtual threads or both
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Post by Bianco »

Folknology wrote:Wow that's cool

What's the overhead (memory etc..)
Are you using native threads or virtual threads or both
I haven't checked the memory overhead but it must be very reasonable as FreeRTOS runs on systems with just a few KB's of memory. The context switch overhead is 149 instructions or 1.49uS on 100MIPS and 0.149% at 1000HZ tickrate (not counting in manual context switches).

FreeRTOS runs in a single hardware thread running on core 0 (it cannot easily be migrated to other cores without modifying the code shared by other ports). There is a demo which shows how to use it in conjunction with hardware threads on the same and other cores.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

Wow that's conjured up an interesting thought and I'm not sure who would use it but:

You could run multiple instances of FreeRTOS one in each thread (8 for L1 and 24^h^h32 for G4!)

In other words as many FreeRTOS virtual machines as you are likely to need!!

Just a thought...

*UPDATE Actually it would be really useful if you were porting something from FreeRTOS to Xmos of course or integrating a bunch of FreeRTOS modules into a single Xmos chip!!

Update 2 - Doh! my addled brain replaced 24->32 instances, shouldn't post when exhausted :?
Last edited by Folknology on Fri Feb 19, 2010 2:17 pm, edited 3 times in total.
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Post by Bianco »

Folknology wrote:
You could run multiple instances of FreeRTOS one in each thread (8 for L1 and 24 for G4!)
Someone has to go back to primary school ;)

It's feasible to run multiple instances but requires some work..
The most easy way is to run a FreeRTOS on each core:

You only need to specify the stdcore[x] modifier on global variables

Getting multiple instances to work on the same core requires more work because the global variables used by FreeRTOS have to be unique for each FreeRTOS instance: stability isn't guaranteed when you share the same kernel data structures between multiple FreeRTOS instances :p
User avatar
trousers
Active Member
Posts: 44
Joined: Fri Dec 11, 2009 10:20 am
Contact:

Post by trousers »

I'm afraid I don't know FreeRTOS but if it has SMP support that may be the way to go. Multiple hardware threads on a single core share many characteristics with a shared-memory SMP machine.
Best friends with the code fairy.
richard
Respected Member
Posts: 318
Joined: Tue Dec 15, 2009 12:46 am

Post by richard »

Bianco wrote:Getting multiple instances to work on the same core requires more work because the global variables used by FreeRTOS have to be unique for each FreeRTOS instance: stability isn't guaranteed when you share the same kernel data structures between multiple FreeRTOS instances :p
Thread local storage is easy to implement on the xcore - change each global into an array of size 8 of that type indexed by the result of the getid instruction. This might be an easy route to running 8 instances of FreeRTOS on a core.
jhrose
Active Member
Posts: 40
Joined: Mon Dec 14, 2009 11:18 am

Post by jhrose »

Hei,
I have just released my FreeRTOS XMOS XS1 port...Any feedback is welcome...
I was able to download your port and try it out on my XC-1 using the Windows IDE today. Very well done - I cannot find any fault with your kernel functions in .../portable/XCC/XMOS_XS1. I had a minor problem with the demo where the LEDs didn't flash in the vCheckTasks task, due to errors in the declarations of vParTestInitialise and vParTestSetLED in your partest.h and ParTest.xc files, which is easily fixed.

With your permission I'd like to add your project into the XOSIG group IndexOfIdeas. Have you contacted Richard Barry to ask if he'd like to list your XS-1 port on the FreeRTOS website?

If you wanted to run multiple FreeRTOS kernel threads with different configurations, you could use some simple #if's in FreeRTOSConfig.h to distinguish configuration blocks for the different threads or cores in a project. Support for XS-1 i/o (ports, channels, timers) needs care if used in a FreeRTOS task, that the FreeRTOS kernel thread is not de-scheduled by the XS-1 scheduler when input is blocked for example. Developers could guard i/o using a select statement in XC to minimise this affect. But perhaps it is better to have a single thread running FreeRTOS and others running real-time i/o functions, and provide a means to share data between FreeRTOS tasks and XS-1 threads on a single core (say a RAM buffer) in the .../portable/XCC/XMOS_XS1 subdirectory. Have you given this task-to-thread interface any thought?
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Post by Bianco »

jhrose wrote:Hei,

I was able to download your port and try it out on my XC-1 using the Windows IDE today. Very well done - I cannot find any fault with your kernel functions in .../portable/XCC/XMOS_XS1. I had a minor problem with the demo where the LEDs didn't flash in the vCheckTasks task, due to errors in the declarations of vParTestInitialise and vParTestSetLED in your partest.h and ParTest.xc files, which is easily fixed.
Which errors did you got and on which board did you test?
jhrose wrote: With your permission I'd like to add your project into the XOSIG group IndexOfIdeas. Have you contacted Richard Barry to ask if he'd like to list your XS-1 port on the FreeRTOS website?
You have my permission. I have not yet emailed the author of FreeRTOS to include my port in the unsupported ports, i plan to do this though but there might be a minor new release before i do this.

Two planned improvements:
- asm functions in portmacro should be declared volatile to avoid shifting by the compiler.
- Stack initialisation for sed etc might better be initialised zero instead of inheriting it from the (hardware) thread which creates the threads.
jhrose wrote: If you wanted to run multiple FreeRTOS kernel threads with different configurations, you could use some simple #if's in FreeRTOSConfig.h to distinguish configuration blocks for the different threads or cores in a project. Support for XS-1 i/o (ports, channels, timers) needs care if used in a FreeRTOS task, that the FreeRTOS kernel thread is not de-scheduled by the XS-1 scheduler when input is blocked for example. Developers could guard i/o using a select statement in XC to minimise this affect. But perhaps it is better to have a single thread running FreeRTOS and others running real-time i/o functions, and provide a means to share data between FreeRTOS tasks and XS-1 threads on a single core (say a RAM buffer) in the .../portable/XCC/XMOS_XS1 subdirectory. Have you given this task-to-thread interface any thought?
A more important issue is the use of global variables by the kernel which makes running multiple kernels next to each other without modifying all references impossible. I tried to leave as much of the shared code intact as possible.

I'm currently working on a new operating system from scratch which will be easy to run in multi kernel setups (already working). It will also have mechanisms for threads scheduled by the kernel to talk to hardware threads.

Expect a release of this new system in about 3 months
Post Reply