RTOS

Great work, was waiting since the beginnig of mbed,if anyone could achieve this! Really cool. Thanks a lot!

Well done Emilio!

The 25% of RAM is a bit scary though ... it's RAM that's fighting me at the moment. Have you looked into using some of the other banks of RAM for say the stack etc to give more room for application code?

Yes, you are right. This is mainly due to the need to specify statically at compile time the maximum number of tasks and the stack size.

At the moment, the rtos library cannot be compiled by the online build system, otherwise we could expose this configuration to the user. (although in the future we will also look for alternative CMSIS-RTOS implementations without this constraint).

My next task is going to be a "revamp" of the online build system to be able to compile libraries like the rtos and mbed itself.

We are aiming at dogfooding for every mbed software development.

Cheers, Emilio

That is great with dedicated and support from mbed team.

Well done Emilio, this looks really cool!

Just tried the first demo and it works!

What about the networking code examples being used with the RTOS?

Has anyone tried it and/or is a RTOS version of the networking code in the works?

Hi Jim, All,

FYI, we're now also starting an "official" networking code stack too; we really wanted to have an RTOS in place to allow networking to use a sockets-like interface without the need for polling. Now that is in place, we're on it! More soon...

Simon

Regarding our forthcoming TCP/IP stack, I would like to emphasize that its use will not require the use of our RTOS library, but it will require the use of our RTOS API.

In other words, with our RTOS library release, we would like to get the attention of the mbed community on the proposed RTOS API.

During the years many RTOS solutions for mbed have been proposed and we are not assuming that our RTOS library implementation is going to be better than the ones proposed by other mbed developers.

What we care to establish instead is a higher level API that we can rely on to provide useful middle-ware (the TCP/IP stack being an example of that).

Cheers, Emilio

So you mean to use your new stack without your RTOS, one would have to implement the same RTOS API? Will the full API be necessary, or you will be relying only on some subset of it? Also, do you mean the CMSIS-RTOS API or the high-level C++ API (rtos::Thread etc)?

Yes, correct.

Very likely, it will rely only on a small subset (ie: Thread, Mutex and Queue), but we are still experimenting with it and we cannot yet specify it.

We intend to support CMSIS-RTOS API on mbed. Every middle-ware based on it will be supported.

Although, for our internal libraries we will be using the higher level API that you see documented on this page and implemented in this library. On the mbed platform we will encourage to base the development of new middleware on this mbed RTOS API.

Cheers, Emilio

This is awesome! I'm looking at the .h files and your constructor looks reminiscent of uC/OS-II of the function for creating a task. Am I able to adjust that last parameter and use custom stack sizes?

When I use the sprintf function to format a string my program stops functioning, why might this be?

Yes you are.

In our implementation, we had to configure statically the size of the memory pool allocated for the stacks (MAX_THREADS_NUM * DEFAULT_STACK_SIZE), although you can rearrange the consumption of this pool among your threads: each thread can use a custom stack size.

Do you have a published program presenting the issue?

The simpler explanation would be the use of sprintf in a ISR.

The C standard library is protecting the access to stdio with mutexes. This is why the use of printf/sprintf in ISR can deadlock the system.

It'd be nice if the RtosTimer api had a templated form like for example the InterruptIn one:

template<typename T> void fall(T *tptr, void (T::*mptr)(void))

for member method callbacks.

Why should sprintf deadlock? It doesn't access stdio and shouldn't need protecting with a mutex.

If you un-comment out one of the sprintf() function calls, the application fails at that point. The way I published it, the first led comes on and then it stops and does nothing more. I'm using the cortex-m3 based mbed board.

+1. Ticket opened.

Good point. My second guess would be a stack overflow, but of course I should see the program to know what is going wrong...

edit: Great, in the mean time the program has been published... :-)

OK, that was simpler than expected. You just need to specify a buffer for your sprintf to work.

Change that:

char* teststring = "";

With that:

char teststring[40];

Thankyou for helping with my problem with sprintf. That was a dumb question.

It'd be nice if there was an option to set MAX_THREADS_NUM to something greater than 7. That number seems arbitrarily low.

I'd like it if there was an option to work with smaller stacks and max treads of something larger like 64.

RTX assumes that you are in control of your configuration file, where you can edit any maximum number of threads.

We will soon release the sources and you will be able to edit the configuration as you like.

Additionally, in the future, for the mbed RTOS, we will favour implementations that do not require the editing of a configuration file to specify the maximum number of threads.

Summarizing, let me empathise that this is a temporary implementation detail and it is not part of the mbed RTOS API.

By the way, today we have released a set of example programs running on mbed based on the CMSIS-RTOS API: /handbook/CMSIS-RTOS

Is there a way to pause a thread to keep it from executing?

You can terminate it, you can yeld in it, you can wait for a certain time in it, or you can wait for a certain event in it (mutex or semaphore availability, signal, message or mail, timeout).

This is a diagram of the thread states:

Does this require re-enterable libraries? Which C libraries are you using and are they all re-enterable?

It is not a requirement, but it is a design goal. Making non re-entrant functions thread-safe has a cost.

There are different ways to make non reentrant function thread-safe:

• Use mutexes
• Keep a separate area of memory for each thread

We are using two separate C standard libraries: ARM C standard library (on the Cortex-M3) and microlib (on the Cortex-M0).

Both libraries are not completely re-entrant, the ARM C standard library is thread safe, microlib is not.

At system initialization we provide to the ARM C standard library a set of mutexes and a separate area of memory for each thread:

 static uint32_t std_libspace[OS_TASK_CNT][96/4];
 static OS_MUT   std_libmutex[OS_MUTEXCNT];

When a non-reentrant function has to store some state in memory it can point to a thread specific area of memory calling __user_perthread_libspace:

void *__user_perthread_libspace (void) {
  /* Provide a separate libspace for each task. */
  uint32_t idx;

  idx = runtask_id ();
  if (idx == 0) {
    /* RTX not running yet. */
    return (&__libspace_start);
  }
  return ((void *)&std_libspace[idx-1]);
}

When a shared resource (ie stdio) has to be accessed a mutex is acquired.

How does lib function do this without modifying library code?

Generally how did you know which lib function is reenterable and which is not? Do you protect every library function call with mutex?

This is a feature provided by the ARM C standard library: http://www.keil.com/support/man/docs/armlib/armlib_Chdhgdid.htm

This is well documented in the library documentation.

For the ARM C standard library the user can use any library call in the RTOS threads, all the non-reentrant functions do use a separate area of memory.

For microlib, at the moment, the user needs to check in the documentation if the function is reentrant, or not, and need to code accordingly. There are plans to make microlib thread safe.

Cheers, Emilio

can you estimate a date that you will be able to release the configurable RTOS? I'm looking at using the cortex m0 but need a few more threads...

Many thanks,

Joe.

Hi guys, what is the OS tick rate? 1000 Hz?

- Brian

I could release the source code of the RTOS today, the problem is that it does not yet compile with the online build system.

Our plan is to unify the offline and online build system, but this has been scheduled after another major release of "mbed.org", therefore there are two separate release cycles before that happen. It could take up to a couple of months.

Yes: 1000Hz (Period: 1ms).

//   <o>Timer tick value [us] <1-1000000>
//   <i> Defines the timer tick value.
//   <i> Default: 1000  (1ms)
#ifndef OS_TICK
 #define OS_TICK        1000
#endif

Emilio

Hi all

When I include the rtos.h, the serial rx isr block the program when an interrupt is asserted. If I remove the "#include..." line and the rtos.h from the project, the programm works...

#include "mbed.h"
#include "rtos.h"

DigitalOut led1(LED1);
DigitalOut led2(LED2);

const char test_string[]="pc";
char c;
Serial pc(USBTX, USBRX);

void callback() {
    
    led2 = !led2;
   return;   
}

int main() {
    pc.attach(callback);
    pc.printf("%s\r\n",test_string);
    while (1) {
      wait(1.0);
    }
}

Hi Emilio Monti,

Is there any way to get the state of a thread? I'd like to monitor a bunch of threads and see when they complete. I don't want to just use a flag at the end of the function because of a race condition.

- Brian

At the moment, there is not an mbed RTOS API to get the state of a thread. It is possible to retrieve it using the RTX implementation internals.

Of course, it is a sensible request and I will open a ticket to add it in the next release.

Emilio