Wyniki wyszukiwania - BazTech

1

System zwalniania wątków VRTS jako alternatywa dla RTOS

Świtalski Emilian, Górecki Krzysztof

Przegląd Elektrotechniczny

|

2023

|

R. 99, nr 9

258--261

PL

Artykuł opisuje implementację systemu zwalniania wątków VRTS, dostępnego na platformie GitHub pod adresem https://github.com/Xaeian/VRTS. Jest to alternatywa dla systemów czasu rzeczywistego RTOS w systemach wbudowanych. Przedstawiono różne koncepcje programowania mikrokontrolerów, zwracając uwagę na różnice między nimi. Omówiono funkcjonalności biblioteki VRTS, przedstawiając jej wykorzystanie w układzie zasilającym elektrolizer alkaliczny.

EN

The article presents VRTS - cooperative multitasking, searchable on GitHub at https://github.com/Xaeian/VRTS. It is an alternative to real-time operating systems (RTOS) in embedded systems. Various concepts of programming microcontrollers were presented, paying attention to the differences between them. The functionalities of the VRTS library were discussed, presenting its use in the supply system of alkaline electrolyzer.

2

Event-driven firmware design with hardware handler scheduling on Cortex-M-based microcontroller

Mazur G.

Measurement Automation Monitoring

|

2018

|

Vol. 64, No. 1

20--22

EN

The paper describes the concept and the design principles of a purely event-driven firmware for a Cortex-M core microcontroller used in an embedded system, based on hardware-scheduled event handling routines. The concept may be a practical alternative to the design paradigm based on an event loop or a real-time operating system, especially for not overly complex designs. When compared to an RTOS-based approach, the presented technique enables much shorter event response time and simpler synchronization of accesses to critical shared resources.

3

Experience Report: Towards Extending an OSEK-Compliant RTOS with Mixed Criticality Support

Gupta T., Luit E. J., van den Heuvel M. M. H. P., Bril R. J.

e-Informatica Software Engineering Journal

|

2018

|

Vol. 12, nr 1

305--320

EN

Background: With an increase of the number of features in a vehicle, the computational requirements also increase, and vehicles may contain up to 100 Electronic Control Units (ECUs) to accommodate these requirements. For cost-effectiveness reasons, amongst others, it is considered desirable to limit the growth of, or preferably reduce, the number of ECUs. To that end, mixed criticality is a promising approach that received a lot of attention in the literature, primarily from a theoretical perspective. Aim: In this paper, we address mixed criticality from a practical perspective. Our prime goal is to extend an OSEK-compliant real-time operating system (RTOS) with mixed criticality support, enabling such support in the automotive domain. In addition, we aim at a system (i) supporting more than two criticality levels; (ii) with minimal overhead upon an increase of the so-called criticality level indicator of the system; (iii) requiring no changes to an underlying operating system; and (iv) featuring further extensions, such as hierarchical scheduling and multi-core. Method: We used the so-called adaptive mixed criticality (AMC) scheme as a starting point for mixed criticality. We extended that scheme from two to more than two criticality levels (satisfying (i)) and complemented it with specified behavior for criticality level changes. We baptized our extended scheme AMC*. Rather than selecting a specific OSEK-compliant RTOS, we selected ExSched, an operating system independent external CPU scheduler framework for real-time systems, which requires no modifications to the original operating system source code (satisfying (iii)) and features further extensions (satisfying (iv))). Results: Although we managed to build a functional prototype of our system, our experience with ExSched made us decide to rebuild the system with a specific OSEK-compliant RTOS, being µC/OS-II. We also briefly report upon our experience with AMC* and suggest directions for improvements. Conclusions: Compared to extending ExSched with AMC*, extending µC/OS-II turned out to be straightforward. Although we now have a basic system operational and available for experimentation, enhancements of the AMC*-scheme are considered desirable before exploitation in a vehicle. Background: With an increase of the number of features in a vehicle, the computational requirements also increase, and vehicles may contain up to 100 Electronic Control Units (ECUs) to accommodate these requirements. For cost-effectiveness reasons, amongst others, it is considered desirable to limit the growth of, or preferably reduce, the number of ECUs. To that end, mixed criticality is a promising approach that received a lot of attention in the literature, primarily from a theoretical perspective. Aim: In this paper, we address mixed criticality from a practical perspective. Our prime goal is to extend an OSEK-compliant real-time operating system (RTOS) with mixed criticality support, enabling such support in the automotive domain. In addition, we aim at a system (i) supporting more than two criticality levels; (ii) with minimal overhead upon an increase of the so-called criticality level indicator of the system; (iii) requiring no changes to an underlying operating system; and (iv) featuring further extensions, such as hierarchical scheduling and multi-core. Method: We used the so-called adaptive mixed criticality (AMC) scheme as a starting point for mixed criticality. We extended that scheme from two to more than two criticality levels (satisfying (i)) and complemented it with specified behavior for criticality level changes. We baptized our extended scheme AMC*. Rather than selecting a specific OSEK-compliant RTOS, we selected ExSched, an operating system independent external CPU scheduler framework for real-time systems, which requires no modifications to the original operating system source code (satisfying (iii)) and features further extensions (satisfying (iv))). Results: Although we managed to build a functional prototype of our system, our experience with ExSched made us decide to rebuild the system with a specific OSEK-compliant RTOS, being µC/OS-II. We also briefly report upon our experience with AMC* and suggest directions for improvements. Conclusions: Compared to extending ExSched with AMC*, extending µC/OS-II turned out to be straightforward. Although we now have a basic system operational and available for experimentation, enhancements of the AMC*-scheme are considered desirable before exploitation in a vehicle.