source: rtems-docs/user/overview/index.rst @ e52906b

5
Last change on this file since e52906b was e52906b, checked in by Sebastian Huber <sebastian.huber@…>, on 01/09/19 at 15:14:06

Simplify SPDX-License-Identifier comment

  • Property mode set to 100644
File size: 9.6 KB
Line 
1.. SPDX-License-Identifier: CC-BY-SA-4.0
2
3Introduction
4============
5
6Overview
7--------
8
9You 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
19Features
20--------
21
22The Real-Time Executive for Multiprocessor Systems (:ref:term:`RTEMS`) is a
23multi-threaded, single address-space, real-time operating system with no
24kernel-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
27RTEMS 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
30software used and distributed by RTEMS which may be linked to the application
31is licensed under permissive open source licenses.  Everything necessary to
32build RTEMS applications is available as open source software.  This makes you
33completely vendor independent.
34
35RTEMS 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
185Real-time Application Systems
186-----------------------------
187
188Real-time application systems are a special class of computer applications.
189They have a complex set of characteristics that distinguish them from other
190software problems.  Generally, they must adhere to more rigorous requirements.
191The correctness of the system depends not only on the results of computations,
192but also on the time at which the results are produced.  The most important and
193complex characteristic of real-time application systems is that they must
194receive and respond to a set of external stimuli within rigid and critical time
195constraints referred to as deadlines.  Systems can be buried by an avalanche of
196interdependent, asynchronous or cyclical event streams.
197
198Deadlines can be further characterized as either hard or soft based upon the
199value of the results when produced after the deadline has passed.  A deadline
200is hard if the results have no value after the deadline has passed, or a
201catastrophic event results from their intended use if not completed on time.  In
202contrast, results produced after a soft deadline may still have some value.
203
204Another distinguishing requirement of real-time application systems is the
205ability to coordinate or manage a large number of concurrent activities. Since
206software is a synchronous entity, this presents special problems.  One
207instruction follows another in a repeating synchronous cycle.  Even though
208mechanisms have been developed to allow for the processing of external
209asynchronous events, the software design efforts required to process and manage
210these events and tasks are growing more complicated.
211
212The design process is complicated further by spreading this activity over a set
213of processors instead of a single processor. The challenges associated with
214designing and building real-time application systems become very complex when
215multiple processors are involved.  New requirements such as interprocessor
216communication channels and global resources that must be shared between
217competing processors are introduced.  The ramifications of multiple processors
218complicate each and every characteristic of a real-time system.
219
220Real-time Executive
221-------------------
222
223Fortunately, real-time operating systems, or real-time executives, serve as a
224cornerstone on which to build the application system.  A real-time multitasking
225executive allows an application to be cast into a set of logical, autonomous
226processes or tasks which become quite manageable.  Each task is internally
227synchronous, but different tasks execute independently, resulting in an
228asynchronous processing stream.  Tasks can be dynamically paused for many
229reasons resulting in a different task being allowed to execute for a period of
230time.  The executive also provides an interface to other system components such
231as interrupt handlers and device drivers.  System components may request the
232executive to allocate and coordinate resources, and to wait for and trigger
233synchronizing conditions.  The executive system calls effectively extend the
234CPU instruction set to support efficient multitasking.  By causing tasks to
235travel through well-defined state transitions, system calls permit an
236application to demand-switch between tasks in response to real-time events.
237
238By properly grouping stimuli responses into separate tasks a system can now
239asynchronously switch between independent streams of execution. This allows the
240system to directly respond to external stimuli as they occur, as well as meet
241critical performance specifications that are typically measured by guaranteed
242response time and transaction throughput.  The multiprocessor extensions of
243RTEMS provide the features necessary to manage the extra requirements
244introduced by a system distributed across several processors.  It removes the
245physical barriers of processor boundaries from the world of the system
246designer, enabling more critical aspects of the system to receive the required
247attention. Such a system, based on an efficient real-time, multiprocessor
248executive, is a more realistic model of the outside world or environment for
249which it is designed.  As a result, the system will always be more logical,
250efficient, and reliable.
251
252By using the directives provided by RTEMS, the real-time applications developer
253is freed from the problem of controlling and synchronizing multiple tasks and
254processors.  In addition, one need not develop, test, debug, and document
255routines to manage memory, pass messages, or provide mutual exclusion.  The
256developer is then able to concentrate solely on the application.  By using
257standard software components, the time and cost required to develop
258sophisticated 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.
Note: See TracBrowser for help on using the repository browser.