ChibiOS Free Embedded RTOS

An hard realtime system is a system whose response time can be guaranteed while operating under the conditions it has been designed for.

Interrupts are not even a problem, just consider them tasks whose priority range lies above the soft tasks and factor them in.

Context switch time, latencies etc can all be calculated or measured and be accounted for. RMA is just an analysis method usable under certain constraints, it is not a different scheduling strategy than it is currently implemented.

Giovanni

offtopic:
Sad, but "real time OS" became some zombo marketoidal buzzword last time. Lots of people (potential clients of company where I work now) want "hard real time"(c)(r)(tm), but when I ask them "how hard this time must be real", or "what is real time in your opinion", or "why do you think you need real time" they are can not answer.

Let it be my feature request for v 3.0
viewtopic.php?f=3&t=1135

Hi,

A small update about this.

Regarding the current plan: http://www.chibios.org/dokuwiki/doku.ph ... _and_ideas

1) Created a branch for Kernel 3.0: /branches/kernel_3_dev
2) Implemented the planned changes to the virtual timers, it is now significantly faster and the VT API more complete. The list is no more a delta list but an absolute time list which offers advantages in timers deletion and is a step toward the tick-less mode (but I have still doubts about this one).
3) Some VT functions have been renamed for consistency.
4) Most VT macros become static inline code.

Giovanni

I see that you plan to offer support for multicore processors. Can you please be more specific about what you plan to do? The threads will be able to migrate from one core to another or they will be locked on a specific core? Do you plan to support homogenous multicore, heterogenous multicore or both?
Do you have any multicontroller in mind when you're thinking about multicore? I know that NXP has a dual core ARM (LPC435x) and also Freescale (MPC551x, MPC5643L etc.)

Hi,

It is not yet a "plan", just something we are evaluating. The initial target would be the FSL/ST xPC56xx family. Threads would be able to float between cores unless locked to a specific core. The doubt is if such a feature should go in ChibiOS/RT 3.0 or into another RTOS with a different name, the problem is conflicting requirements.

A simpler SMP could already be implemented using ChibiOS by running two independent instances and use the HW semaphores for synchronization between the threads on different instances. This approach would fit better the LPC435x where the two cores are not symmetric and require different compiler options.

Giovanni

With RT3.0 stm32f4disco demo (under CBS5) it seems all benchmarks are better except the "Test Case 11.10 (Benchmark, virtual timers set/reset)" which is much lower - is that ok?

It is because the tickless mode, there is less load for all tests caused by systick but the VT unit itself is more complex.

Giovanni

Hey Giovanni,

If I port the STM32 DAC code to 3.0, would you like to include it in the main repo?

I just need the high level driver files, like you did for 2.6.

Thanks.

Hi,

The 3.0 HAL is not 100% ported yet, not just the DAC is missing.

I am looking into making 3.0 the new "trunk", I will open a topic about it tomorrow.

Giovanni