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
[RFC] Ideas for ChibiOS/RT 3.0
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [RFC] Ideas for ChibiOS/RT 3.0
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.
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.
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [RFC] Ideas for ChibiOS/RT 3.0
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
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
Re: [RFC] Ideas for ChibiOS/RT 3.0
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.)
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.)
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [RFC] Ideas for ChibiOS/RT 3.0
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
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
Re: [RFC] Ideas for ChibiOS/RT 3.0
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?
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [RFC] Ideas for ChibiOS/RT 3.0
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
Giovanni
Re: [RFC] Ideas for ChibiOS/RT 3.0
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.
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.
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: [RFC] Ideas for ChibiOS/RT 3.0
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
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