Nice work!

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

Have fun

Pete

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.

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?

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

Andy C can you post a link to your binary?

Thank you

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

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?

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

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?

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

Hi

"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

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.

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!

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!

What a pity!

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.

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...

raphael bendel wrote:

 

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...

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!

raphael bendel wrote:

 

raphael bendel wrote:

 

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!

 

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!

raphael bendel wrote:

 

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!

raphael bendel wrote:

 

raphael bendel wrote:

 

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!

 

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!

 

 

 

@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.

Is there anybody succesfilly using CoOs on mbed?

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. 

Hi,

@ 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.

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

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.

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

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...

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...

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

Thank you!

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

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