1 | .. SPDX-License-Identifier: CC-BY-SA-4.0 |
---|
2 | |
---|
3 | Introduction |
---|
4 | ============ |
---|
5 | |
---|
6 | Overview |
---|
7 | -------- |
---|
8 | |
---|
9 | You are someone looking for a real-time operating system. This document |
---|
10 | |
---|
11 | - presents the basic features of RTEMS, so that you can decide if it is worth to |
---|
12 | look at, |
---|
13 | |
---|
14 | - gives you a :ref:`quick start <QuickStart>` to install all the tools |
---|
15 | necessary to work with RTEMS, and |
---|
16 | |
---|
17 | - helps you to build an example application on top of RTEMS. |
---|
18 | |
---|
19 | Features |
---|
20 | -------- |
---|
21 | |
---|
22 | The Real-Time Executive for Multiprocessor Systems (:ref:term:`RTEMS`) is a |
---|
23 | multi-threaded, single address-space, real-time operating system with no |
---|
24 | kernel-space/user-space separation. It is capable to operate in an |
---|
25 | :ref:term:`SMP` configuration providing a state of the art feature set. |
---|
26 | |
---|
27 | RTEMS is licensed under a |
---|
28 | `modified GPL 2.0 or later license with an exception for static linking <https://git.rtems.org/rtems/tree/LICENSE>`_ |
---|
29 | [#]_. It exposes no license requirements on application code. The third-party |
---|
30 | software used and distributed by RTEMS which may be linked to the application |
---|
31 | is licensed under permissive open source licenses. Everything necessary to |
---|
32 | build RTEMS applications is available as open source software. This makes you |
---|
33 | completely vendor independent. |
---|
34 | |
---|
35 | RTEMS provides the following basic feature set: |
---|
36 | |
---|
37 | - :ref:term:`APIs <API>` |
---|
38 | |
---|
39 | - :ref:term:`POSIX` with |
---|
40 | `pthreads <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html>`_ |
---|
41 | (enables a broad range of standard software to run on RTEMS) |
---|
42 | |
---|
43 | - `Classic <https://docs.rtems.org/branches/master/c-user.pdf>`_ |
---|
44 | |
---|
45 | - :ref:term:`C11` (including |
---|
46 | `thread <https://en.cppreference.com/w/c/thread>`_ support) |
---|
47 | |
---|
48 | - :ref:term:`C++11` (including |
---|
49 | `thread <https://en.cppreference.com/w/cpp/thread>`_ support) |
---|
50 | |
---|
51 | - Newlib and :ref:term:`GCC` internal |
---|
52 | |
---|
53 | - Programming languages |
---|
54 | |
---|
55 | - C/C++/OpenMP (RTEMS Source Builder, RSB) |
---|
56 | |
---|
57 | - Ada (RSB, ``--with-ada``) |
---|
58 | |
---|
59 | - Erlang |
---|
60 | |
---|
61 | - Fortran (RSB, ``--with-fortran``) |
---|
62 | |
---|
63 | - Python and MicroPython |
---|
64 | |
---|
65 | - Parallel languages |
---|
66 | |
---|
67 | - :ref:term:`EMB²` |
---|
68 | |
---|
69 | - Google Go [#]_ |
---|
70 | |
---|
71 | - :ref:term:`OpenMP` 4.5 |
---|
72 | |
---|
73 | - Thread synchronization and communication |
---|
74 | |
---|
75 | - Mutexes with and without locking protocols |
---|
76 | |
---|
77 | - Counting semaphores |
---|
78 | |
---|
79 | - Binary semaphores |
---|
80 | |
---|
81 | - Condition variables |
---|
82 | |
---|
83 | - Events |
---|
84 | |
---|
85 | - Message queues |
---|
86 | |
---|
87 | - Barriers |
---|
88 | |
---|
89 | - :ref:term:`Futex` (used by :ref:term:`OpenMP` barriers) |
---|
90 | |
---|
91 | - Epoch Based Reclamation (libbsd) |
---|
92 | |
---|
93 | - Locking protocols |
---|
94 | |
---|
95 | - Transitive Priority Inheritance |
---|
96 | |
---|
97 | - :ref:term:`OMIP` (SMP feature) |
---|
98 | |
---|
99 | - Priority Ceiling |
---|
100 | |
---|
101 | - :ref:term:`MrsP` (SMP feature) |
---|
102 | |
---|
103 | - Scalable timer and timeout support |
---|
104 | |
---|
105 | - Lock-free timestamps (FreeBSD timecounters) |
---|
106 | |
---|
107 | - Responsive interrupt management |
---|
108 | |
---|
109 | - C11/C++11 :ref:term:`TLS` [#]_ |
---|
110 | |
---|
111 | - Link-time configurable schedulers |
---|
112 | |
---|
113 | - Fixed-priority |
---|
114 | |
---|
115 | - Job-level fixed-priority (:ref:term:`EDF`) |
---|
116 | |
---|
117 | - Constant Bandwidth Server (experimental) |
---|
118 | |
---|
119 | - Clustered scheduling (SMP feature) |
---|
120 | |
---|
121 | - Flexible link-time configuration |
---|
122 | |
---|
123 | - Job-level fixed-priority scheduler (:ref:term:`EDF`) with support for |
---|
124 | one-to-one and one-to-all thread to processor affinities (default SMP |
---|
125 | scheduler) |
---|
126 | |
---|
127 | - Fixed-priority scheduler |
---|
128 | |
---|
129 | - Proof-of-concept strong :ref:term:`APA` scheduler |
---|
130 | |
---|
131 | - Focus on link-time application-specific configuration |
---|
132 | |
---|
133 | - Linker-set based initialization (similar to global C++ constructors) |
---|
134 | |
---|
135 | - Operating system uses fine-grained locking (SMP feature) |
---|
136 | |
---|
137 | - Dynamic memory allocators |
---|
138 | |
---|
139 | - First-fit (default) |
---|
140 | |
---|
141 | - Universal Memory Allocator |
---|
142 | (`UMA <https://www.freebsd.org/cgi/man.cgi?query=uma&sektion=9>`_ , |
---|
143 | libbsd) |
---|
144 | |
---|
145 | - File systems |
---|
146 | |
---|
147 | - :ref:term:`IMFS` |
---|
148 | |
---|
149 | - :ref:term:`FAT` |
---|
150 | |
---|
151 | - :ref:term:`RFS` |
---|
152 | |
---|
153 | - :ref:term:`NFSv2` |
---|
154 | |
---|
155 | - :ref:term:`JFFS2` (NOR flashes) |
---|
156 | |
---|
157 | - :ref:term:`YAFFS2` (NAND flashes, GPL or commercial license required) |
---|
158 | |
---|
159 | - Device drivers |
---|
160 | |
---|
161 | - Termios (serial interfaces) |
---|
162 | |
---|
163 | - I2C (Linux user-space API compatible) |
---|
164 | |
---|
165 | - SPI (Linux user-space API compatible) |
---|
166 | |
---|
167 | - Network stacks (legacy, libbsd, lwIP) |
---|
168 | |
---|
169 | - USB stack (libbsd) |
---|
170 | |
---|
171 | - SD/MMC card stack (libbsd) |
---|
172 | |
---|
173 | - Framebuffer (Linux user-space API compatible, Qt) |
---|
174 | |
---|
175 | - Application runs in kernel-space and can access hardware directly |
---|
176 | |
---|
177 | - libbsd |
---|
178 | |
---|
179 | - Port of FreeBSD user-space and kernel-space components to RTEMS |
---|
180 | |
---|
181 | - Easy access to FreeBSD software for RTEMS |
---|
182 | |
---|
183 | - Support to stay in synchronization with FreeBSD |
---|
184 | |
---|
185 | Real-time Application Systems |
---|
186 | ----------------------------- |
---|
187 | |
---|
188 | Real-time application systems are a special class of computer applications. |
---|
189 | They have a complex set of characteristics that distinguish them from other |
---|
190 | software problems. Generally, they must adhere to more rigorous requirements. |
---|
191 | The correctness of the system depends not only on the results of computations, |
---|
192 | but also on the time at which the results are produced. The most important and |
---|
193 | complex characteristic of real-time application systems is that they must |
---|
194 | receive and respond to a set of external stimuli within rigid and critical time |
---|
195 | constraints referred to as deadlines. Systems can be buried by an avalanche of |
---|
196 | interdependent, asynchronous or cyclical event streams. |
---|
197 | |
---|
198 | Deadlines can be further characterized as either hard or soft based upon the |
---|
199 | value of the results when produced after the deadline has passed. A deadline |
---|
200 | is hard if the results have no value after the deadline has passed, or a |
---|
201 | catastrophic event results from their intended use if not completed on time. In |
---|
202 | contrast, results produced after a soft deadline may still have some value. |
---|
203 | |
---|
204 | Another distinguishing requirement of real-time application systems is the |
---|
205 | ability to coordinate or manage a large number of concurrent activities. Since |
---|
206 | software is a synchronous entity, this presents special problems. One |
---|
207 | instruction follows another in a repeating synchronous cycle. Even though |
---|
208 | mechanisms have been developed to allow for the processing of external |
---|
209 | asynchronous events, the software design efforts required to process and manage |
---|
210 | these events and tasks are growing more complicated. |
---|
211 | |
---|
212 | The design process is complicated further by spreading this activity over a set |
---|
213 | of processors instead of a single processor. The challenges associated with |
---|
214 | designing and building real-time application systems become very complex when |
---|
215 | multiple processors are involved. New requirements such as interprocessor |
---|
216 | communication channels and global resources that must be shared between |
---|
217 | competing processors are introduced. The ramifications of multiple processors |
---|
218 | complicate each and every characteristic of a real-time system. |
---|
219 | |
---|
220 | Real-time Executive |
---|
221 | ------------------- |
---|
222 | |
---|
223 | Fortunately, real-time operating systems, or real-time executives, serve as a |
---|
224 | cornerstone on which to build the application system. A real-time multitasking |
---|
225 | executive allows an application to be cast into a set of logical, autonomous |
---|
226 | processes or tasks which become quite manageable. Each task is internally |
---|
227 | synchronous, but different tasks execute independently, resulting in an |
---|
228 | asynchronous processing stream. Tasks can be dynamically paused for many |
---|
229 | reasons resulting in a different task being allowed to execute for a period of |
---|
230 | time. The executive also provides an interface to other system components such |
---|
231 | as interrupt handlers and device drivers. System components may request the |
---|
232 | executive to allocate and coordinate resources, and to wait for and trigger |
---|
233 | synchronizing conditions. The executive system calls effectively extend the |
---|
234 | CPU instruction set to support efficient multitasking. By causing tasks to |
---|
235 | travel through well-defined state transitions, system calls permit an |
---|
236 | application to demand-switch between tasks in response to real-time events. |
---|
237 | |
---|
238 | By properly grouping stimuli responses into separate tasks a system can now |
---|
239 | asynchronously switch between independent streams of execution. This allows the |
---|
240 | system to directly respond to external stimuli as they occur, as well as meet |
---|
241 | critical performance specifications that are typically measured by guaranteed |
---|
242 | response time and transaction throughput. The multiprocessor extensions of |
---|
243 | RTEMS provide the features necessary to manage the extra requirements |
---|
244 | introduced by a system distributed across several processors. It removes the |
---|
245 | physical barriers of processor boundaries from the world of the system |
---|
246 | designer, enabling more critical aspects of the system to receive the required |
---|
247 | attention. Such a system, based on an efficient real-time, multiprocessor |
---|
248 | executive, is a more realistic model of the outside world or environment for |
---|
249 | which it is designed. As a result, the system will always be more logical, |
---|
250 | efficient, and reliable. |
---|
251 | |
---|
252 | By using the directives provided by RTEMS, the real-time applications developer |
---|
253 | is freed from the problem of controlling and synchronizing multiple tasks and |
---|
254 | processors. In addition, one need not develop, test, debug, and document |
---|
255 | routines to manage memory, pass messages, or provide mutual exclusion. The |
---|
256 | developer is then able to concentrate solely on the application. By using |
---|
257 | standard software components, the time and cost required to develop |
---|
258 | sophisticated real-time applications are significantly reduced. |
---|
259 | |
---|
260 | .. [#] The goal is to use the |
---|
261 | `BSD 2-Clause license |
---|
262 | <https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause>`_ for new code |
---|
263 | or code those copyright holder agreed to a license change, see `#3053 |
---|
264 | <https://devel.rtems.org/ticket/3053>`_ for the details. |
---|
265 | |
---|
266 | .. [#] See `#2832 <https://devel.rtems.org/ticket/2832>`_. |
---|
267 | |
---|
268 | .. [#] Thread-local storage requires some support by the tool chain and the |
---|
269 | RTEMS architecture support, e.g. context-switch code. It is supported |
---|
270 | at least on ARM, PowerPC, RISC-V, SPARC and m68k. Check the |
---|
271 | `RTEMS CPU Architecture Supplement <https://docs.rtems.org/branches/master/cpu-supplement.pdf>`_ |
---|
272 | if it is supported. |
---|