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
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.
- kristianpaul
- Junior Member
- Posts: 4
- Joined: Sun Dec 13, 2009 2:02 pm
- Contact:
Hey thats fantastic, how may rtos can i run at the same time?
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.
- errordeveloper
- Active Member
- Posts: 50
- Joined: Wed Dec 16, 2009 6:04 pm
- Location: London
- Contact:
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 :)
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
- infiniteimprobability
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
- Contact:
Good work on the update - I'm sure there will be many who benefit from this.
what are the tools required to run this port.
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.
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.