Anyone got FreeRTOS running on the embed ?

25 Apr 2010

Nice work!

26 Apr 2010

The port from the NXP CMSIS bits are at the end of this page

http://www-users.cs.york.ac.uk/~pcc/MCP/index.html

 

fileDescription
Free RTOS NXP (LPC1768) Port of FreeRTOS Real Time Operating System (local)
CMSIS Cortex Microcontroller Software Interface Standard Source (Local)
Diags Our gcc based test code

Have fun

 

Pete

07 May 2010

I will try FreeRTOS, but I am more interested in www.coocox.org which would would add a big boost to mbed development when there are more than a few peripherals connected to the mbed.

07 May 2010

Can you please explain the advantages of CoOS? A quick look reveals (what appears to me to be) an almost exact 1:1 API mapping between CoOS and FreeRTOS, and it looks like you could almost port between the two with nothing more than a series of find-and-replace...

The CooCox peripheral drivers don't appear to either depend on or integrate with the OS (e.g. use of mutexes etc, reentrancy, thread safety). What am I missing?

07 May 2010

Being specific to LPC1xxx, CooCox has theoretically better performance (e.g. latency times, memory footprint, and so on) than FreeRTOS.

10 Oct 2010

Andy C can you post a link to your binary?

Thank you

10 Oct 2010

Compiling on Ubuntu I obtain this:

andrea@andrea-laptop:~/Scrivania/RTOS_GCC$ make

  CC    init/cr_startup_lpc17.c

make: arm-none-eabi-gcc: comando non trovato

make: *** [gcc/cr_startup_lpc17.o] Errore 127

What should I do?

10 Oct 2010

user Andrea Zanelli wrote:

Compiling on Ubuntu I obtain this:

 

 

andrea@andrea-laptop:~/Scrivania/RTOS_GCC$ make

  CC    init/cr_startup_lpc17.c

make: arm-none-eabi-gcc: comando non trovato

make: *** [gcc/cr_startup_lpc17.o] Errore 127
What should I do?
You should install the arm compiler "Sourcery G++ Lite 2009q3-68"

10 Oct 2010

Thank you, is there any possibility to use the mbed compiler instead of gcc?

14 Oct 2010 . Edited: 14 Oct 2010

I ported CoOS to mbed board and did a successful compile in the Webinterface. As base of my project i took http://www.coocox.org/EXAMPLE/NXP_Keil_ARMCC.htm example and the CoOS distribution with the Keil port.c. My sources are available at: http://dl.dropbox.com/u/768445/CoOS.zip. There seems to be an watchdog initialized by CoOS and this causes a reset after initialization. May be this is the problem: http://www.coocox.org/Forum/topic.php?id=171. Any ideas or experiences about that?

13 Nov 2010

user Eric Ebert wrote:
http://dl.dropbox.com/u/768445/CoOS.zip

Hi

I tried to compile CoOs in the webinterface as you did, but i have numerous errors such as:

"A value of type "void *" cannot be used to initialize an entity of type "P_OSTCB" (E144)" in file "ccrtos/time.c" or

"A value of type "void *" cannot be assigned to an entity of type "P_OSTCB" (E513)" in file "ccrtos/time.c"

Did you get these ones?

Do i have to convert C style code to C++ one in order to fix these errors?

 

Many thanks

13 Nov 2010

Yes. In C it is valid to assign a void* to any other pointer without a cast. In C++ it is not, so you need to add casts.

13 Nov 2010

I solved by adding explicit casts were needed(they are a lot!)....Are you going to use CoOs?Let me know if you get any result or issue, I'm trying to do the same!

13 Nov 2010

user Andrea Zanelli wrote:

I solved by adding explicit casts were needed(they are a lot!)....Are you going to use CoOs?Let me know if you get any result or issue, I'm trying to do the same!

Well i'm beginner in RTOS, and having an mbed i told myself it could be a good opportunity if something already exists with such device...I think it's too complicated for me by now.

What a pity!

13 Nov 2010

user Ivo van Poorten wrote:

Yes. In C it is valid to assign a void* to any other pointer without a cast. In C++ it is not, so you need to add casts.

yes i agree with you, but  unlike what the compiler states, nowhere in the code it is written void * , but ptr=NULL instead;

it seems that the compiler do confuse null pointers with void pointers. Am i right? If i replace NULL by 0, the error message disappear. But there are so many...

13 Nov 2010

user raphael bendel wrote:

 

user Ivo van Poorten wrote:

Yes. In C it is valid to assign a void* to any other pointer without a cast. In C++ it is not, so you need to add casts.

yes i agree with you, but  unlike what the compiler states, nowhere in the code it is written void * , but ptr=NULL instead;

 

it seems that the compiler do confuse null pointers with void pointers. Am i right? If i replace NULL by 0, the error message disappear. But there are so many...

i m wrong there are also many void* in the code. I will waste a lot of time to find the rigth type of each concerned pointers. Good day!

13 Nov 2010

user Andrea Zanelli wrote:

I solved by adding explicit casts were needed(they are a lot!)....Are you going to use CoOs?Let me know if you get any result or issue, I'm trying to do the same!

user raphael bendel wrote:

 

user raphael bendel wrote:

 

user Ivo van Poorten wrote:

Yes. In C it is valid to assign a void* to any other pointer without a cast. In C++ it is not, so you need to add casts.

yes i agree with you, but  unlike what the compiler states, nowhere in the code it is written void * , but ptr=NULL instead;

 

it seems that the compiler do confuse null pointers with void pointers. Am i right? If i replace NULL by 0, the error message disappear. But there are so many...

i m wrong there are also many void* in the code. I will waste a lot of time to find the rigth type of each concerned pointers. Good day!

 

user Andrea Zanelli wrote:

I solved by adding explicit casts were needed(they are a lot!)....Are you going to use CoOs?Let me know if you get any result or issue, I'm trying to do the same!

13 Nov 2010

user raphael bendel wrote:

 

user Andrea Zanelli wrote:

I solved by adding explicit casts were needed(they are a lot!)....Are you going to use CoOs?Let me know if you get any result or issue, I'm trying to do the same!

user raphael bendel wrote:

 

user raphael bendel wrote:

 

user Ivo van Poorten wrote:

Yes. In C it is valid to assign a void* to any other pointer without a cast. In C++ it is not, so you need to add casts.

yes i agree with you, but  unlike what the compiler states, nowhere in the code it is written void * , but ptr=NULL instead;

 

it seems that the compiler do confuse null pointers with void pointers. Am i right? If i replace NULL by 0, the error message disappear. But there are so many...

i m wrong there are also many void* in the code. I will waste a lot of time to find the rigth type of each concerned pointers. Good day!

 

user Andrea Zanelli wrote:

I solved by adding explicit casts were needed(they are a lot!)....Are you going to use CoOs?Let me know if you get any result or issue, I'm trying to do the same!

 

 

 

i finally fixed all the errors related to the COO. Do you have a main file to make some tests? Do you test it as a preemptive RTOS or round robin? many thanks

13 Nov 2010

@raphael: The C standard's definition of NULL is ((void*)0), C++ stdlib defines it as just 0 (which is an integer). C++0x  will have a new nullptr keyword which is implicitely cast to other pointer types if such an assignment occurs.

13 Nov 2010

Is there anybody succesfilly using CoOs on mbed?

15 Nov 2010
user Andrea Zanelli wrote:

Is there anybody succesfilly using CoOs on mbed?

i've tried the example but it doesn't work, it just displays the 2 first printf lines, but none tasks printf. The CoInitOS() seems to fail. 

15 Nov 2010

Hi,

@ user raphael bendel

did you download the file http://dl.dropbox.com/u/768445/CoOS.zip ?

I just made it working in the online Compiler. It is the example code from CoOS. Simply import the Zip-File. It is a direct export from Compiler-UI.

So far this works for me and is not the large amount of stuff and overhead which bring some other RTOSses to my mbed. Thats why i decided to use CoOS.

Another reason is that i can easily understand what happends there (with only a few amount of time) because its tiny and provides only the important stuff. A RTOS in less the 4kB of RAM and 34kB of Flash.

 

Build Result

So if there are any issues with CoInitOS() in your code see the Documentation at: http://www.coocox.org/CoOS.htm and please provide these infos in Forum. Or send me a mail and i will provide the updated code on my Dropbox-Account.

Sincerely,

Eric

15 Nov 2010 . Edited: 15 Nov 2010

It's a bit OT, but allow me to plug my FreeRTOS port (NOT using the online compiler, rather using gcc: http://github.com/hugovincent/mbed-freertos)... I did a lot of work on the toolchain and build system so that it can aggressively optimize out any parts of the operating system you aren't using in your application. RAM usage is ambiguous as FreeRTOS malloc()s some important memory, but a typical hello world app uses a similar amount of RAM as the CoOS example above and around 30-45 kB of flash, while a more complete app, with a TCP/IP stack, ethernet and DMA-driven buffered serial ports, mbed file system access, protected memory (using the MPU), debug handlers and so on, will use 75-85 kB of flash (edit: this is the total binary size, including all libraries etc and wastage necessitated by alignment for the MPU). Using my port, you will also get* thread-safe C/C++ libraries, which is impossible using the online compiler (from what I can see anyway... correct me if I'm wrong).

 

From what I've seen, FreeRTOS is a more mature, robust and complete RTOS compared to CoOS. However, using the online compiler might be seen as a big advantage, and it's going to be pretty difficult to get a good FreeRTOS port working using the online compiler**.

 

* OK they're not 100% complete yet, but something is better than nothing, right :-)

** Reason: for the protected memory/MPU stuff to work, we needed to make substantial changes to the linker scripts and C libraries... which we can't do with the online compiler.

15 Nov 2010

yes i tried this example, but i had to make some casts in the OS code source before compilation succeded. I agree it could be interesting for me to start learning about RTOS with this one, but i need to fix this problem firstly

 

15 Nov 2010

in fact i'm not sure that the problem comes from CoInitOS() function. But looking at the example this function is call just afterwards the 2 first printf calls...

15 Nov 2010

Sorry but I'm a bit confused...which of the two ports will provide libraries with the basic APIs?What does make mbeds library unsuitable for an RTOS application?Sorry, but I'm studying Real Time systems at the university and this is my first real application...

15 Nov 2010

My port does not provide the basic mbed APIs... but they aren't that useful for a hard-realtime environment anyway. It does provide the basic C libraries, printf(), fopen() etc, done in a thread-safe, reentrant, preemptible manner though. Some parts of the mbed library are unsuitable for hard realtime because they assume they have full/exclusive access to whatever part of the hardware they're dealing with, and that they can set their own interrupt handlers (which can take as long as they want to execute), and that they can use blocking delays. You might be able to use some of the mbed library as the basis for peripheral "drivers" in your RTOS however in almost all cases, but you'd need to add locking (to prevent two or more threads trying to access the same hardware and/or memory at the same time and clashing) at the least.

Summary: probably most parts of the mbed library are fine (a testament to the great devs behind it) but there are some parts in which assumptions were necessarily made, and those assumptions are incorrect when running atop a RTOS.

Hugo

 

15 Nov 2010

Thank you!

28 Nov 2010

Hi everybody

i'm trying to use coox RTOS with mbed. Do you know if it's compulsory to add files such as LPC17xx.h,startup_LPC17xx.s,system_LPC17xx.h and system_LPC17xx.c in the project?

Or are they already integrated in the compiler? This is fuzzy for me. Is anybody succed to use it?

Many thanks

28 Nov 2010

Hi Raphael,

If you click on the mbed library in the compiler, you can follow the "Open Library Page" link in the right "Library Details" column to see all the files included in the mbed library. You'll see (in the LPC1768 directory) that the CMSIS files you are referring to (LPC17xx.h and system_LPC17xx.h etc) are all already included. So you shouldn't need them again.

Simon

Please log in to post a reply.