1 | .. SPDX-License-Identifier: CC-BY-SA-4.0 |
---|
2 | |
---|
3 | .. Copyright (C) 2016 Chris Johns <chrisj@rtems.org> |
---|
4 | |
---|
5 | Introduction |
---|
6 | ************ |
---|
7 | |
---|
8 | .. _Overview: |
---|
9 | |
---|
10 | Overview |
---|
11 | ======== |
---|
12 | |
---|
13 | You are someone looking for a real-time operating system. This document |
---|
14 | |
---|
15 | - presents the basic features of RTEMS, so that you can decide if it is worth to |
---|
16 | look at, |
---|
17 | |
---|
18 | - gives you a :ref:`quick start <QuickStart>` to install all the tools |
---|
19 | necessary to work with RTEMS, and |
---|
20 | |
---|
21 | - helps you to build an example application on top of RTEMS. |
---|
22 | |
---|
23 | Features |
---|
24 | ======== |
---|
25 | |
---|
26 | The Real-Time Executive for Multiprocessor Systems (:ref:term:`RTEMS`) is a |
---|
27 | multi-threaded, single address-space, real-time operating system with no |
---|
28 | kernel-space/user-space separation. It is capable to operate in an |
---|
29 | :ref:term:`SMP` configuration providing a state of the art feature set. |
---|
30 | |
---|
31 | RTEMS is licensed under a |
---|
32 | `modified GPL 2.0 or later license with an exception for static linking <https://git.rtems.org/rtems/tree/LICENSE>`_ |
---|
33 | [#]_. It exposes no license requirements on application code. The third-party |
---|
34 | software used and distributed by RTEMS which may be linked to the application |
---|
35 | is licensed under permissive open source licenses. Everything necessary to |
---|
36 | build RTEMS applications is available as open source software. This makes you |
---|
37 | completely vendor independent. |
---|
38 | |
---|
39 | RTEMS provides the following basic feature set: |
---|
40 | |
---|
41 | - :ref:term:`APIs <API>` |
---|
42 | |
---|
43 | - :ref:term:`POSIX` with |
---|
44 | `pthreads <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html>`_ |
---|
45 | (enables a broad range of standard software to run on RTEMS) |
---|
46 | |
---|
47 | - `Classic <https://docs.rtems.org/branches/master/c-user.pdf>`_ |
---|
48 | |
---|
49 | - :ref:term:`C11` (including |
---|
50 | `thread <https://en.cppreference.com/w/c/thread>`_ support) |
---|
51 | |
---|
52 | - :ref:term:`C++11` (including |
---|
53 | `thread <https://en.cppreference.com/w/cpp/thread>`_ support) |
---|
54 | |
---|
55 | - Newlib and :ref:term:`GCC` internal |
---|
56 | |
---|
57 | - Programming languages |
---|
58 | |
---|
59 | - C/C++/OpenMP (RTEMS Source Builder, RSB) |
---|
60 | |
---|
61 | - Ada (RSB, ``--with-ada``) |
---|
62 | |
---|
63 | - Erlang |
---|
64 | |
---|
65 | - Fortran (RSB, ``--with-fortran``) |
---|
66 | |
---|
67 | - Python and MicroPython |
---|
68 | |
---|
69 | - Parallel languages |
---|
70 | |
---|
71 | - :ref:term:`EMB²` |
---|
72 | |
---|
73 | - Google Go [#]_ |
---|
74 | |
---|
75 | - :ref:term:`OpenMP` 4.5 |
---|
76 | |
---|
77 | - Thread synchronization and communication |
---|
78 | |
---|
79 | - Mutexes with and without locking protocols |
---|
80 | |
---|
81 | - Counting semaphores |
---|
82 | |
---|
83 | - Binary semaphores |
---|
84 | |
---|
85 | - Condition variables |
---|
86 | |
---|
87 | - Events |
---|
88 | |
---|
89 | - Message queues |
---|
90 | |
---|
91 | - Barriers |
---|
92 | |
---|
93 | - :ref:term:`Futex` (used by :ref:term:`OpenMP` barriers) |
---|
94 | |
---|
95 | - Epoch Based Reclamation (libbsd) |
---|
96 | |
---|
97 | - Locking protocols |
---|
98 | |
---|
99 | - Transitive Priority Inheritance |
---|
100 | |
---|
101 | - :ref:term:`OMIP` (SMP feature) |
---|
102 | |
---|
103 | - Priority Ceiling |
---|
104 | |
---|
105 | - :ref:term:`MrsP` (SMP feature) |
---|
106 | |
---|
107 | - Scalable timer and timeout support |
---|
108 | |
---|
109 | - Lock-free timestamps (FreeBSD timecounters) |
---|
110 | |
---|
111 | - Responsive interrupt management |
---|
112 | |
---|
113 | - C11/C++11 :ref:term:`TLS` [#]_ |
---|
114 | |
---|
115 | - Link-time configurable schedulers |
---|
116 | |
---|
117 | - Fixed-priority |
---|
118 | |
---|
119 | - Job-level fixed-priority (:ref:term:`EDF`) |
---|
120 | |
---|
121 | - Constant Bandwidth Server (experimental) |
---|
122 | |
---|
123 | - Clustered scheduling (SMP feature) |
---|
124 | |
---|
125 | - Flexible link-time configuration |
---|
126 | |
---|
127 | - Job-level fixed-priority scheduler (:ref:term:`EDF`) with support for |
---|
128 | one-to-one and one-to-all thread to processor affinities (default SMP |
---|
129 | scheduler) |
---|
130 | |
---|
131 | - Fixed-priority scheduler |
---|
132 | |
---|
133 | - Proof-of-concept strong :ref:term:`APA` scheduler |
---|
134 | |
---|
135 | - Focus on link-time application-specific configuration |
---|
136 | |
---|
137 | - Linker-set based initialization (similar to global C++ constructors) |
---|
138 | |
---|
139 | - Operating system uses fine-grained locking (SMP feature) |
---|
140 | |
---|
141 | - Dynamic memory allocators |
---|
142 | |
---|
143 | - First-fit (default) |
---|
144 | |
---|
145 | - Universal Memory Allocator |
---|
146 | (`UMA <https://www.freebsd.org/cgi/man.cgi?query=uma&sektion=9>`_ , |
---|
147 | libbsd) |
---|
148 | |
---|
149 | - File systems |
---|
150 | |
---|
151 | - :ref:term:`IMFS` |
---|
152 | |
---|
153 | - :ref:term:`FAT` |
---|
154 | |
---|
155 | - :ref:term:`RFS` |
---|
156 | |
---|
157 | - :ref:term:`NFSv2` |
---|
158 | |
---|
159 | - :ref:term:`JFFS2` (NOR flashes) |
---|
160 | |
---|
161 | - :ref:term:`YAFFS2` (NAND flashes, GPL or commercial license required) |
---|
162 | |
---|
163 | - Device drivers |
---|
164 | |
---|
165 | - Termios (serial interfaces) |
---|
166 | |
---|
167 | - I2C (Linux user-space API compatible) |
---|
168 | |
---|
169 | - SPI (Linux user-space API compatible) |
---|
170 | |
---|
171 | - Network stacks (legacy, libbsd, lwIP) |
---|
172 | |
---|
173 | - USB stack (libbsd) |
---|
174 | |
---|
175 | - SD/MMC card stack (libbsd) |
---|
176 | |
---|
177 | - Framebuffer (Linux user-space API compatible, Qt) |
---|
178 | |
---|
179 | - Application runs in kernel-space and can access hardware directly |
---|
180 | |
---|
181 | - libbsd |
---|
182 | |
---|
183 | - Port of FreeBSD user-space and kernel-space components to RTEMS |
---|
184 | |
---|
185 | - Easy access to FreeBSD software for RTEMS |
---|
186 | |
---|
187 | - Support to stay in synchronization with FreeBSD |
---|
188 | |
---|
189 | .. _ecosystem: |
---|
190 | |
---|
191 | Ecosystem |
---|
192 | ========= |
---|
193 | .. index:: Ecosystem |
---|
194 | |
---|
195 | The RTEMS Ecosystem is the collection of tools, packages, code, documentation |
---|
196 | and online content provided by the RTEMS Project. The ecosystem provides a way |
---|
197 | to develop, maintain, and use RTEMS. It's parts interact with the user, the |
---|
198 | host environment, and each other to make RTEMS accessible, useable and |
---|
199 | predicable. |
---|
200 | |
---|
201 | The ecosystem is for users, developers and maintainers and it is an ongoing |
---|
202 | effort that needs your help and support. The RTEMS project is always improving |
---|
203 | the way it delivers the kernel to you and your feedback is important so please |
---|
204 | join the mailing lists and contribute back comments, success stories, bugs and |
---|
205 | patches. |
---|
206 | |
---|
207 | What the RTEMS project describes here to develop, maintain and use RTEMS does |
---|
208 | not dictate what you need to use in your project. You can and should select the |
---|
209 | work-flow that best suites the demands of your project and what you are |
---|
210 | delivering. |
---|
211 | |
---|
212 | Rational |
---|
213 | -------- |
---|
214 | |
---|
215 | RTEMS is complex and the focus of the RTEMS Ecosystem is to simplify the |
---|
216 | complexity for users by providing a stable documented way to build, configure |
---|
217 | and run RTEMS. RTEMS is more than a kernel running real-time applications on |
---|
218 | target hardware, it is part of a project's and therefore team's workflow and |
---|
219 | every project and team is different. |
---|
220 | |
---|
221 | RTEMS's ecosystem does not mandate a way to work. It is a series of parts, |
---|
222 | components, and items that are used to create a suitable development |
---|
223 | environment to work with. The processes explained in this manual are the same |
---|
224 | things an RTEMS maintainer does to maintain the kernel or an experienced user |
---|
225 | does to build their production system. It is important to keep this in mind |
---|
226 | when working through this manual. We encourage users to explore what can be |
---|
227 | done and to discover ways to make it fit their needs. The ecosystem provided by |
---|
228 | the RTEMS Project will not install in a single click of a mouse because we want |
---|
229 | users to learn the parts they will come to depend on as their project's |
---|
230 | development matures. |
---|
231 | |
---|
232 | The RTEMS Ecosystem provides a standard interface that is the same on all |
---|
233 | supported host systems. Standardizing how a user interacts with RTEMS is |
---|
234 | important and making that experience portable is also important. As a result |
---|
235 | the ecosystem is documented at the command line level and we leave GUI and IDE |
---|
236 | integration for users and integrators. |
---|
237 | |
---|
238 | Standardizing the parts and how to use them lets users create processes and |
---|
239 | procedures that are stable over releases. The RTEMS Ecosystem generates data |
---|
240 | that can be used to audit the build process so their configuration can be |
---|
241 | documented. |
---|
242 | |
---|
243 | The ecosystem is based around the source code used in the various parts, |
---|
244 | components and items of the RTEMS development environment. A user can create |
---|
245 | an archive of the complete build process including all the source code for long |
---|
246 | term storage. This is important for projects with a long life cycle. |
---|
247 | |
---|
248 | Open Source |
---|
249 | ----------- |
---|
250 | |
---|
251 | RTEMS is an open source operating system and an open source project and this |
---|
252 | extends to the ecosystem. We encourage users to integrate the processes to |
---|
253 | build tools, the kernel and any third-party libraries into their project's |
---|
254 | configuration management processes. |
---|
255 | |
---|
256 | All the parts that make up the ecosystem are open source. The ecosystem uses a |
---|
257 | package's source code to create an executable on a host so when an example |
---|
258 | RTEMS executable is created and run for the first time the user will have built |
---|
259 | every tool as well as the executable from source. The RTEMS Project believes |
---|
260 | the freedom this gives a user is as important as the freedom of having access |
---|
261 | to the source code for a package. |
---|
262 | |
---|
263 | Deployment |
---|
264 | ---------- |
---|
265 | |
---|
266 | The RTEMS Project provides the ecosystem as source code that users can download |
---|
267 | to create personalised development environments. The RTEMS Project does not |
---|
268 | provide packaging and deployment for a specific host environment, target |
---|
269 | architecture or BSP. The RTEMS Project encourages users and organizations to |
---|
270 | fill this role for the community. The :ref:`RTEMS Source Builder <RSB>` |
---|
271 | provides some aid to :ref:`build and deploy tool binaries <RSBDeployment>`. |
---|
272 | |
---|
273 | Real-time Application Systems |
---|
274 | ============================= |
---|
275 | |
---|
276 | Real-time application systems are a special class of computer applications. |
---|
277 | They have a complex set of characteristics that distinguish them from other |
---|
278 | software problems. Generally, they must adhere to more rigorous requirements. |
---|
279 | The correctness of the system depends not only on the results of computations, |
---|
280 | but also on the time at which the results are produced. The most important and |
---|
281 | complex characteristic of real-time application systems is that they must |
---|
282 | receive and respond to a set of external stimuli within rigid and critical time |
---|
283 | constraints referred to as deadlines. Systems can be buried by an avalanche of |
---|
284 | interdependent, asynchronous or cyclical event streams. |
---|
285 | |
---|
286 | Deadlines can be further characterized as either hard or soft based upon the |
---|
287 | value of the results when produced after the deadline has passed. A deadline |
---|
288 | is hard if the results have no value after the deadline has passed, or a |
---|
289 | catastrophic event results from their intended use if not completed on time. In |
---|
290 | contrast, results produced after a soft deadline may still have some value. |
---|
291 | |
---|
292 | Another distinguishing requirement of real-time application systems is the |
---|
293 | ability to coordinate or manage a large number of concurrent activities. Since |
---|
294 | software is a synchronous entity, this presents special problems. One |
---|
295 | instruction follows another in a repeating synchronous cycle. Even though |
---|
296 | mechanisms have been developed to allow for the processing of external |
---|
297 | asynchronous events, the software design efforts required to process and manage |
---|
298 | these events and tasks are growing more complicated. |
---|
299 | |
---|
300 | The design process is complicated further by spreading this activity over a set |
---|
301 | of processors instead of a single processor. The challenges associated with |
---|
302 | designing and building real-time application systems become very complex when |
---|
303 | multiple processors are involved. New requirements such as interprocessor |
---|
304 | communication channels and global resources that must be shared between |
---|
305 | competing processors are introduced. The ramifications of multiple processors |
---|
306 | complicate each and every characteristic of a real-time system. |
---|
307 | |
---|
308 | Real-time Executive |
---|
309 | =================== |
---|
310 | |
---|
311 | Fortunately, real-time operating systems, or real-time executives, serve as a |
---|
312 | cornerstone on which to build the application system. A real-time multitasking |
---|
313 | executive allows an application to be cast into a set of logical, autonomous |
---|
314 | processes or tasks which become quite manageable. Each task is internally |
---|
315 | synchronous, but different tasks execute independently, resulting in an |
---|
316 | asynchronous processing stream. Tasks can be dynamically paused for many |
---|
317 | reasons resulting in a different task being allowed to execute for a period of |
---|
318 | time. The executive also provides an interface to other system components such |
---|
319 | as interrupt handlers and device drivers. System components may request the |
---|
320 | executive to allocate and coordinate resources, and to wait for and trigger |
---|
321 | synchronizing conditions. The executive system calls effectively extend the |
---|
322 | CPU instruction set to support efficient multitasking. By causing tasks to |
---|
323 | travel through well-defined state transitions, system calls permit an |
---|
324 | application to demand-switch between tasks in response to real-time events. |
---|
325 | |
---|
326 | By properly grouping stimuli responses into separate tasks a system can now |
---|
327 | asynchronously switch between independent streams of execution. This allows the |
---|
328 | system to directly respond to external stimuli as they occur, as well as meet |
---|
329 | critical performance specifications that are typically measured by guaranteed |
---|
330 | response time and transaction throughput. The multiprocessor extensions of |
---|
331 | RTEMS provide the features necessary to manage the extra requirements |
---|
332 | introduced by a system distributed across several processors. It removes the |
---|
333 | physical barriers of processor boundaries from the world of the system |
---|
334 | designer, enabling more critical aspects of the system to receive the required |
---|
335 | attention. Such a system, based on an efficient real-time, multiprocessor |
---|
336 | executive, is a more realistic model of the outside world or environment for |
---|
337 | which it is designed. As a result, the system will always be more logical, |
---|
338 | efficient, and reliable. |
---|
339 | |
---|
340 | By using the directives provided by RTEMS, the real-time applications developer |
---|
341 | is freed from the problem of controlling and synchronizing multiple tasks and |
---|
342 | processors. In addition, one need not develop, test, debug, and document |
---|
343 | routines to manage memory, pass messages, or provide mutual exclusion. The |
---|
344 | developer is then able to concentrate solely on the application. By using |
---|
345 | standard software components, the time and cost required to develop |
---|
346 | sophisticated real-time applications are significantly reduced. |
---|
347 | |
---|
348 | .. [#] The goal is to use the |
---|
349 | `BSD 2-Clause license |
---|
350 | <https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause>`_ for new code |
---|
351 | or code those copyright holder agreed to a license change, see `#3053 |
---|
352 | <https://devel.rtems.org/ticket/3053>`_ for the details. |
---|
353 | |
---|
354 | .. [#] See `#2832 <https://devel.rtems.org/ticket/2832>`_. |
---|
355 | |
---|
356 | .. [#] Thread-local storage requires some support by the tool chain and the |
---|
357 | RTEMS architecture support, e.g. context-switch code. It is supported |
---|
358 | at least on ARM, AArch64, PowerPC, RISC-V, SPARC, MicroBlaze, Nios II, |
---|
359 | and m68k. Check the `RTEMS CPU Architecture Supplement |
---|
360 | <https://docs.rtems.org/branches/master/cpu-supplement.pdf>`_ if it is |
---|
361 | supported. |
---|