thank you very much!

Hi!

i'm compiling coos with mbed, but it seems that i face problem with SwitchContext() function which belongs to port.C file.

Maybe i choosed the wrong one, do you know which one matches with mbed? GCC, Keil or IAR?

Can you tell me why are there different port.c files proposed with coos, while they only contain assembler commands which normally only depends on target? Am i right?

Many thanks

Keil or ARMCC is closest.

Thanks Igor.

hello everybody!

I'm still having problem with Coos RTOS in Mbed. But i go more deeply. Is there anybody who can tell me if i can redefine an exception handler that is previously defined in startup_LPC17xx.c?

I'm talking about PendSV_Handler(). How can i know how it is defined in Mbed? As we don't have the startup_LPC17xx.c file.

Many thanks

raphael bendel wrote:

 

hello everybody!

I'm still having problem with Coos RTOS in Mbed. But i go more deeply. Is there anybody who can tell me if i can redefine an exception handler that is previously defined in startup_LPC17xx.c?

I'm talking about PendSV_Handler(). How can i know how it is defined in Mbed? As we don't have the startup_LPC17xx.c file.

Many thanks

 

Bye

raphael bendel wrote:

 

raphael bendel wrote:

 

hello everybody!

I'm still having problem with Coos RTOS in Mbed. But i go more deeply. Is there anybody who can tell me if i can redefine an exception handler that is previously defined in startup_LPC17xx.c?

I'm talking about PendSV_Handler(). How can i know how it is defined in Mbed? As we don't have the startup_LPC17xx.c file.

Many thanks

 

In fact i saw that it is originally defined as default handler i.e. an infinite loop. So maybe with Mbed, we couldn't redefine this handler (because it is already compiled: startup_LPC17xx.o) and that's why i'm blocked in my application while it makes a switch context. This is my last assumption...Am i right? Any other suggestion?

 

 

Bye

i don't understand why the linker doesn't send any error message...

Hi Raphael,

The PendSV_Handler is defined as a "weak" function which is an infinite loop, so you can overwrite this if you choose.

Remember to make sure you use the correct C linkage, else it won't overwrite it:

extern "C" void PendSV_Handler() {
// ... my implementation ...
}

Simon

Simon Ford wrote:

Hi Raphael,

The PendSV_Handler is defined as a "weak" function which is an infinite loop, so you can overwrite this if you choose.

Remember to make sure you use the correct C linkage, else it won't overwrite it:

 

extern "C" void PendSV_Handler() {
// ... my implementation ...
}

This should get you what you want.

 

Simon

many thanks

Raphael

Simon, thank you very much! It works well with my test function written in C.

Unfortunately, the cOOcos's PendSV_Handler() redefinition use assembler like this:

__asm  void PendSV_Handler(){

}

Do you know what i must add before its name in order it works?

Many thanks

Raphael

Sorry it works also with _asm.

Ok! So it seems that CooxRTOS works with Mbed, i'm very happy!!

Bye

Raphael

@ Raphael. Can you make the whole CoOS solution public? May be in the Cookbook-Section. I guess there are a lot of people interested in. By the way i found on GitHub a solution for FreeRTOS https://github.com/hugovincent/mbed-freertos . It compiles with the arm-none-eabi GNU toolchain (https://github.com/hugovincent/arm-eabi-toolchain). Has anyone managed to get this run or only the kernel itself with the normal web based compiler? There is a lot of stuff inside which comes directlly with the mbed and the libraries provided here. The same stuff from the GitHub-Code can be kicked out i guess. Any ideas?

Bye

Eric

Hi Eric,

My freertos port cannot current be made to work in the online compiler as it needs more control over the linking process than what is available (things have to be linked at specific addresses for the memory protection stuff to work). Of course, if someone would like to prove me wrong, please go ahead!

Also, regarding the stuff which I/we had to write for https://github.com/hugovincent/mbed-freertos but which mbed already provides, I only rewrote stuff I *had* too. Partly, this was because (until recently) it was not possible to link against the mbed binary libraries using the available GCC-based toolchains, but mainly it is because the mbed libraries assume they have exclusive access to certain things (hardware or CPU time) - these assumptions aren't necessarily valid in an RTOS environment. Using an RTOS with the mbed libraries may (or may not) work most of the time, but can't be relied on to meet hard real time guarantees, or to not deadlock. Aside: we can't check for or fix deadlocks or resource clashes or otherwise make the libraries safe for a preemptive-multithreading environment as mbed still don't publish library source code, grrr!! So no, the code can't be "kicked out" (otherwise I would have removed it myself) :-)

Finally, using the MPU (memory protection unit) in a comprehensive way demands quite significant changes to many parts of the system (e.g. library code and parts of the kernel have to be marked as privileged so they can access hardware, while for instance the malloc() functions have to be able to place unprivileged user memory in unprivileged segments so the MPU can do it's job. And the MPU has very particular segment size and alignment requirements that would be difficult or more likely impossible to achieve in the current online compiler environment (we use custom linker scripts to do this)).

Hope this information is useful.

Regards,

Hugo

Hi Hugo,

i see, there are a lot reasons to do the FreeRTOS coding outside of the online compiler. I'll give the GCC enviroment a try. So i have to take the hard way and implement the drivers on my own, that are not provided by the FreeRTOS code from GitHub. From some point of view it would be nice to extend the mbed-library by an RTOS covering the aspects you wrote above. But this can only be done by the mbed developers itself(closed source). May be in future releases of the mbed lib we have some features to manage all the different tasks in embeded systems by a Task-Oriented system with priorities (like FreeRTOS). Another possibility i have looked at is: http://scmrtos.sourceforge.net/ScmRTOS where a port is running in the Online-Compiler This works out of the Box with simple LED-Blinking example. But i dont know so far if it also works with events from Ethernet/USB-Controller. I guess there are some problems like the ones described above.

BTW: Do you know if there is a way to do a JTAG-Like debuging with the embed? I have another LPC1768-Bord from Steitec with JTAG and i managed to run the mbed library also on that board(using the Keil-Compiler provided by Steitec). This is at the moment the way of debugging my code for the mbed hardware and copy the code back to online compiler for the mbed or build directly with Keil.

HI Eric

About COox you just have to put an extern "C" before __asm void PendSV_Handler() definition in port.c for keil version. I have also modified this lines in os_config.h file:

#define CFG_CPU_FREQ            (1000000000)

#define CFG_SYSTICK_FREQ        (20)

The example given seems to work but each task are done only once. I will see later if it's normal. Moreover setting above 20 the SYSTICK FREQUENCY makes the example out of order.

Do you have the same results?

Bye

hi everybody

i went deeper: you also have to put an extern "C" before void SysTick_Handler(void) in arch.c file, otherwise your systick handler will never be executed at each systick, because it is defined as an infinite loop by default. Now the example works normally

Bye

Raphael

Hi Raphael,

thanks. I did your updates in the code at:  http://dl.dropbox.com/u/768445/CoOS.zip . I cant test it at the moment but i will give you an update if i see that it works. May be you can try it also.

Regards,

Eric

Hi Raphael,

my CoOs runs too. I can run it with:

in os_config.h file:
#define CFG_CPU_FREQ            (960000000) 
#define CFG_SYSTICK_FREQ        (1000)

 Without any problems now.

You should see in Terraterm something like this with fast update rate(depending on CFG_SYSTICK_FREQ):

CooCox RTOS Demo

 CoInitOS done.
 CoCreateTask  init_task done.
Signal from Task A
Signal from Task B
Signal from Task A
Signal from Task B

I published the code now, because it works quite well:

CoOS So Simply load it from here. And i'll remove the Dropbox-Links.

Regards,

 Eric

Hi everybody!

i try to execute the CoIdleTask() by adding a function inside it. But nothing happens. I don't understand the body of the SetEnvironment function:

__asm  void SetEnvironment(OS_STK *pstk)

{

SUBS    R0,#28

MSR     PSP, R0             ; Mov new stack point to PSP

//ORR lr, lr, #4

BX      LR

ALIGN

}

Does the compiler link R0 register to pstk pointer automatically? if yes, what does   SUBS    R0,#28   mean? DO i have to make other changes in the code in order that the idle task works and execute my function?

Hi everybody

In the InitTaskContext function, i would like to know what these  lines mean:

*(context--) = (U32)0x01000000L;              -> is it the T flag?

*(context)   = (U32)0xFFFFFFFEL;              -> why this value?

context      = context - 5;                                 -> why 5? = length of param?

*(context)   = (U32)param;            /* R0: argument */

context      = context - 8;                                -> why 8?

Many thanks in advance

Is it possible to know which are the mbed's APIs that can be used in an RTOS such as CoOs?I mean which are the APIs that  can be preempted without causing deadlocks or other errors?

Hi Andrea,

In general, pre-emption is probably not going to cause many problems, unless there is something timing critical (I can't think of anything off the top of my head).

The thing which you will generally need to look out for is that peripheral functions will generally not be re-entrant. For example, you read from the ADC using AnalogIn, and then an interrupt fires and you try and read an AnalogIn in the interrupt whilst the previous one is "in flight". Or you printf, and an interrupt tries to printf too whilst that is in flight.

Accessing these sort of things could therefore need to be protected (e.g. mutex) depending on how your code is structured.

Simon

And library routines that aren't reentrant, such as the printf() family and some time routines. At least they were problmatic in years past.

In my opinion, look hard at the alternatives like multiple state machines or run-to-completion cooperative scheduling, before going to the complexity and overhead of a preemptive scheduler.

Steve you're right, but I'd like to learn more about RTOS and it is for this reason that I want to use CoOS or FreeRTOS....

However, few weeks ago Hugo Vincent wrote on this topic saying that some mbed's API can't be used into a RTOS 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. I understand the necessity to use non-blocking delays, but I still don't undesatnd which is the effect of setting "own interrupt handlers". Can you help with this?

I also have two other another questions:

1)How can I understand which library is thread-safe and which not since they aren't open source?

2)Is it true that moslty every hardware resource access must be regulated by mutexes or semaphores, because they can't be preempted (with mbed or any other microcontroller...)?If not can you give me an example of an hardware resource that can be accessed to without?

This because I need to know if mbed will be suitable to try some scheduling algorithms :)

Again, be certain you NEED an RTOS, and then that you NEED preemption since it adds great complexity and heightens the need for really well experienced software design to be correct.

The traditional C libraries contain many non-reentrant functions such as vprint and the related printf, fprintf, et al, and the time calls, and others. Some professional grade run time libraries mated with good compilers have reentrant versions. I don't know how to know which are and are not reentrant, other than by looking at a linker's map and see if a given module has static variables in it.

One can design a multi-tasking system to have a single task do all printf's, (or be the single task using any other resource or I/O device). Other tasks then use a message queue to pass data to the single task. That avoids the reentrancy issues.

mbed is a great tutoring device. It's not intended for a production product. You can start with the issue that it's a demo/eval item, not a production item, so it typically will go away in a year or less, and/or mutate.

The contributed code for mbed is neat, but it has no unifying basis for compatibility. The projects are demos, stove-pipe-like, and not intended to be anything more than that. in the main, as I see it. Again, it's a rapid demo/experiment or one-of-a-kind app platform, not a rapid product development platform.

ARM, to their credit, is providing CMSIS as a basis help reduce duplication of effort for more product oriented work, or so it seems.

Hi,

i think Steve is right. Sometimes it would be enough to use a simple state machine like:

int state=0; //initialize the state variable
bool question = false;
while (1)
  {
    switch (state) //perform states
    {
        case 0: //state 0
          state=1; //next state
          break;
        case 1: //state 1
          question = doSomething();
          if (question == true) //match
            state=2; //next state
          else
            state=0; //no match -> reset state machine
          break;
       case 2: //state 2
          question = doSomethingElse();
          if (question == true) // match
            state=1; //next state
          else
            state=0; //no match -> reset state machine
          break;
     }
}

I guess this is the simplest form of a state machine "RTOS". You can use interrupts and the mbed libs and take easily control of what happends when between the different components in your system.

For people who like better graphical state machine editors there is a free solution using Qfsm(http://qfsm.sourceforge.net/) and Ragel (http://www.complang.org/ragel/).

For a production system using the mbed lib you can find here http://mbed.org/cookbook/Reference-Design some Eagle-Files. Using the mbed lib in the f.e. Keil ARM Compiler and a self build PCB you can do JTAG-Debugging and all that stuff. Of course the mbed Hardware it self is optimized for prototyping. Of course there can be errors in the lib and the lib will change. So take a relative stable state and find out where problems could occur. I think you dont need to update every development cycle. Most important point is to know exactly what your own system does. Here you can find the mbed lib code: http://mbed.org/projects/libraries/svn/mbed/trunk and some Informations how to use http://mbed.org/forum/mbed/topic/518/?page=1#comment-2595.

Regards

Eric

Thank you for your help! I'm not going to develop a production product or something like this, I just want to implement some scheduling policy with algorithms like RM, EDF or DM and so on and make them work with simple tasks to see a practical application of what I've been studying. That's why I need an RTOS and state machines or infinit loop won't be enough... :)

Regards

Andrea

I didn't say they can't be used, I said they can't be relied upon but probably work most of the time:

Regarding the interrupt handlers, what I meant was: most interrupt handlers appear to disable interrupts for their duration - so the interrupt handlers can't be interrupted. While it depends on if they disable just their interrupt or all interrupts (again: can't easily check, no source code :-( ), some (admittedly strict) real time guarantees can't be made when there are non-deterministic periods during which interrupts are disabled.

I think this discussion is getting a bit out of control, and off topic. I think for most applications you only need to worry about the reentrancy issue and don't need to worry about any of these other issues we've been discussing.

Regarding reentrancy in my FreeRTOS port, the system is structured (albeit not currently completely implemented and debugged) so that printf etc and other library functions are all fully reentrant, because each thread keeps it's own instance of the static variables, and some important types of output (e.g. serial console) are buffered and multiplexed. This means you can safely printf from multiple threads and it'll work fine. Other things which present reentrancy problems (e.g. some IO drivers) are handled by locks/mutexes so only one thread can interact with them at once.

I didn't want to be off topic, I'm sorry...However thank you for your help :)