Version: 7.6
Status: Complete
License: Custom Licence
Download: https://github.com/BiancoZandbergen/XMOS_FreeRTOS
Update February 2014: Now based on FreeRTOS version 7.6.0 (Requires tools v13 or newer to build).
This is a port of FreeRTOS (website http://www.freertos.org) v6.0.2 to the XMOS XS1 architecture.
It should contain all the features available on FreeRTOS however not all of them are tested.
Features of FreeRTOS include:
- Pre-emptive scheduling (timeslices)
- Co-operative scheduling
- Delays
- Message queues
- Semaphores
FreeRTOS port
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
-
- XCore Addict
- Posts: 169
- Joined: Fri Jan 08, 2010 12:13 am
Good work - will have to take a look at this implementation. I'm sure I will be back with more comments soon!
Paul
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
-
- Junior Member
- Posts: 4
- Joined: Sun Dec 13, 2009 2:02 pm
Hey thats fantastic, how may rtos can i run at the same time?
-
- XCore Expert
- Posts: 754
- Joined: Thu Dec 10, 2009 6:56 pm
Currently you can only run FreeRTOS at one thread on Core 0.
This is due to the fact that FreeRTOS shares its main code with a lot of other architecture ports and i left this code intact.
This is due to the fact that FreeRTOS shares its main code with a lot of other architecture ports and i left this code intact.
-
- Active Member
- Posts: 50
- Joined: Wed Dec 16, 2009 6:04 pm
- Location: London
Contiki port could be good to have as well ..
i would like to have a look at that sometime :)
i would like to have a look at that sometime :)
-
- Junior Member
- Posts: 7
- Joined: Sat Oct 30, 2010 9:48 am
Hi Bianco,
I am currently doing an internship at XMOS... more specifically a benchmark for UAVs hardware platforms. Studying/comparing the traditional microprocessors with XMOS architecture! A lot of the times a RTOS is used.
I read your thesis and I look to the code done... nice job.... very well written and a really good work.
I have just on question for you... the OS that you developed who do I need to talk with on XMOS to have access to it if you don't mind of course!
Thank you
Best
Goncalo
I am currently doing an internship at XMOS... more specifically a benchmark for UAVs hardware platforms. Studying/comparing the traditional microprocessors with XMOS architecture! A lot of the times a RTOS is used.
I read your thesis and I look to the code done... nice job.... very well written and a really good work.
I have just on question for you... the OS that you developed who do I need to talk with on XMOS to have access to it if you don't mind of course!
Thank you
Best
Goncalo
-
Verified
- XCore Legend
- Posts: 1140
- Joined: Thu May 27, 2010 10:08 am
Good work on the update - I'm sure there will be many who benefit from this.
Engineer at XMOS
-
- Newbie
- Posts: 1
- Joined: Fri Oct 10, 2014 4:08 pm
what are the tools required to run this port.
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
Just wondering if there is any advice for improving the port to work better with XCORE-200. With the XCORE-200 having so much more memory per tile than the XS1 it is a superior target to run meaningful programs in a FreeRTOS core (you can run one FreeRTOS core per tile, of course). It's great for me because I have a lot of legacy code for ARM Cortex-M targets that use FreeRTOS. And I just can write a few little .xc helper functions to interface that code to other parts of the chip (e.g. for I2C, UART, USB, Ethernet, etc).
The main challenges for XCORE-200 are discussed here: https://www.xcore.com/viewtopic.php?f=8&t=6370
Essentially you need to set portBYTE_ALIGNMENT to 8, and I have found that all the code that runs on the FreeRTOS core must be compiled with -mno-dual-issue, otherwise I get exceptions. Presumably related to either the clock interrupt or executing one of the assembly instructions, e.g. kcall instruction to jump to the kernel or disabling interrupts for a critical section and something screws up the issue alignment? I am honestly not a huge expert on how to deal with moving between dual issue and single issue code properly, especially with these asynchronous calls with interrupts and kcall. So I wonder if anyone has advice on where to look to get some insight on this? Of course I can continue to force the code on that core to be single issue, but it seems like it should be possible to make a few changes to the porting code so it would work with dual issue code (i.e. modify portmacro.h, port_asm.S, port.c and port_xc.xc).
Anyway, I have pulled in FreeRTOS 9 with just minor changes to the portmacro.h, so the port is by no means obsolete. I haven't tried FreeRTOS 10 yet, but I do like the MIT license.
The main challenges for XCORE-200 are discussed here: https://www.xcore.com/viewtopic.php?f=8&t=6370
Essentially you need to set portBYTE_ALIGNMENT to 8, and I have found that all the code that runs on the FreeRTOS core must be compiled with -mno-dual-issue, otherwise I get exceptions. Presumably related to either the clock interrupt or executing one of the assembly instructions, e.g. kcall instruction to jump to the kernel or disabling interrupts for a critical section and something screws up the issue alignment? I am honestly not a huge expert on how to deal with moving between dual issue and single issue code properly, especially with these asynchronous calls with interrupts and kcall. So I wonder if anyone has advice on where to look to get some insight on this? Of course I can continue to force the code on that core to be single issue, but it seems like it should be possible to make a few changes to the porting code so it would work with dual issue code (i.e. modify portmacro.h, port_asm.S, port.c and port_xc.xc).
Anyway, I have pulled in FreeRTOS 9 with just minor changes to the portmacro.h, so the port is by no means obsolete. I haven't tried FreeRTOS 10 yet, but I do like the MIT license.
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
As an update it will work without compiling the FreeRTOS core with -mno-dual-issue. You just need to use the 32 bit version of kcall (KCALLI_lu6 0) and increment the spc by 4 bytes rather than 2 bytes in the kernel call. That will work whether the code regardless whether the code was running in single issue or dual issue when the kernel call occurred.
I have also updated the kernel assembly to use dual issue instructions but I haven't determined if this is an improvement or not.
I have also updated the kernel assembly to use dual issue instructions but I haven't determined if this is an improvement or not.