Changeset ea0777e in rtems-docs
- Timestamp:
- 04/01/16 01:20:13 (7 years ago)
- Branches:
- 4.11, 5, am, master
- Children:
- b412038
- Parents:
- aae09e2
- git-author:
- Chris Johns <chrisj@…> (04/01/16 01:20:13)
- git-committer:
- Amar Takhar <verm@…> (05/03/16 00:51:27)
- Location:
- user
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
user/overview/index.rst
raae09e2 rea0777e 7 7 Welcome to the :ref:term:`RTEMS` User Manual. 8 8 9 This document covers all the topic required as a user of RTEMS to use the RTEMS10 operating system.9 This document covers all the topics required as a user of RTEMS to use the 10 RTEMS operating system. 11 11 12 12 RTEMS, Real-Time Executive for Multiprocessor Systems, is a real-time executive … … 16 16 .. sidebar:: Developers 17 17 18 Developers should look at the :r:url:`devel` for technical information the18 Developers should look at the :r:url:`devel` for technical information. The 19 19 design and development of RTEMS is located there. 20 20 … … 62 62 Deadlines can be further characterized as either hard or soft based upon the 63 63 value of the results when produced after the deadline has passed. A deadline 64 is hard if the results have no value or if their use will result ina65 catast rophic event. In contrast, results which are produced after a soft66 deadline mayhave some value.64 is hard if the results have no value after the deadline has passed, or a 65 catastophic event results from their intended use if not completed on time. In 66 contrast, results produced after a soft deadline may still have some value. 67 67 68 68 Another distinguishing requirement of real-time application systems is the … … 85 85 =================== 86 86 87 Fortunately, real-time operating systems or real-time executivesserve as a87 Fortunately, real-time operating systems, or real-time executives, serve as a 88 88 cornerstone on which to build the application system. A real-time multitasking 89 89 executive allows an application to be cast into a set of logical, autonomous … … 100 100 application to demand-switch between tasks in response to real-time events. 101 101 102 By proper grouping of responses to stimuli into separate tasks, a system can103 now asynchronously switch between independent streams of execution, directly 104 responding to external stimuli as they occur. This allows the system design to 105 meet critical performance specifications which are typically measured by 106 guaranteed response time and transaction throughput. The multiprocessor 107 extensions of RTEMS provide the features necessary to manage the extra 108 requirements introduced by a system distributed across several processors. It 109 removes the physical barriers of processor boundaries from the world of the 110 system designer, enabling more critical aspects of the system to receive the 111 required attention. Such a system, based on an efficient real-time, 112 multiprocessor executive, is a more realistic model of the outside worldor113 environment for which it is designed. As a result, the system will always be 114 more logical,efficient, and reliable.102 By properly grouping stimuli responses into separate tasks a system can now 103 asynchronously switch between independent streams of execution. This allows the 104 system to directly respond to external stimuli as they occur, as well as meet 105 critical performance specifications that are typically measured by guaranteed 106 response time and transaction throughput. The multiprocessor extensions of 107 RTEMS provide the features necessary to manage the extra requirements 108 introduced by a system distributed across several processors. It removes the 109 physical barriers of processor boundaries from the world of the system 110 designer, enabling more critical aspects of the system to receive the required 111 attention. Such a system, based on an efficient real-time, multiprocessor 112 executive, is a more realistic model of the outside world or environment for 113 which it is designed. As a result, the system will always be more logical, 114 efficient, and reliable. 115 115 116 116 By using the directives provided by RTEMS, the real-time applications developer … … 125 125 =========== 126 126 127 RTEMS is an open source operating and an open source project. As a user you128 have access to all the source code and we encourage you to work with the source129 code and to integrate the processes used to build tools, the kernel and any 3rd 130 party libraries into your project's configuration management processes. The 131 RTEMS project is always improving the way it develivers the kernel to you and 132 so your feedback is important.127 RTEMS is an open source operating system and an open source project. As a user, 128 you have access to all the source code. We encourage you to work with the 129 source code and integrate the provided processes used to build tools, the 130 kernel and any 3rd party libraries into your project's configuration management 131 processes. The RTEMS project is always improving the way it develivers the 132 kernel to you and so your feedback is important. 133 133 134 134 What we used in the RTEMS project to develop and maintain RTEMS does not 135 dictate what you use to develop and maintain your project. You can and should135 dictate what you use to develop and maintain your project. You can, and should, 136 136 select the work-flow that best suites the demands of your project and what you 137 137 are delivering. -
user/start/basics.rst
raae09e2 rea0777e 7 7 ======== 8 8 9 You will see the term **prefix** referred to thoughout this documentation and 10 in a wide number of software packages you can download from the internet. A 11 **prefix** is a path on your computer a software package is built and installed 12 under. Packages that have a **prefix** will place all parts under the *prefix 13 path*. On a host computer like Linux the packages you install from your 14 distribution typically use a platform specific standard *prefix*. For example 15 on Linux it is :file:`/usr` and on FreeBSD it is :file:`/usr/local`. 9 You will see the term :ref:term:`prefix` referred to thoughout this 10 documentation and in a wide number of software packages you can download from 11 the internet. A **prefix** is the path on your computer a software package is 12 built and installed under. Packages that have a **prefix** will place all parts 13 under the **prefix** path. On a host computer like Linux the packages you 14 install from your distribution typically use a platform specific standard 15 **prefix**. For example on Linux it is :file:`/usr` and on FreeBSD it is 16 :file:`/usr/local`. 16 17 17 We recommend you **do not** use the standard *prefix* when installing RTEMS 18 Tools. If you are building the tools as a normal user and not as ``root`` the 19 RTEMS Source Builder (RSB) will fail if the *prefix* is not writable. We 20 recommend you leave the standand *prefix* for the packages your operating 21 system installs. 18 We recommend you *DO NOT* use the standard **prefix** when installing the RTEMS 19 Tools. The standard **prefix** is the default **prefix** each package built by 20 the RSB contains. If you are building the tools when logged in as a *Standard 21 User* and not as the *Super User* (``root``) or *Administrator* the RTEMS 22 Source Builder (RSB) *will* fail and report an error if the default **prefix** 23 is not writable. We recommend you leave the standand **prefix** for the 24 packages your operating system installs or software you manually install such 25 as applications. 22 26 23 A further reason not use the standard *prefix* is to allow more than one27 A further reason not to use the standard **prefix** is to allow more than one 24 28 version of RTEMS to exist on your host machine at a time. The ``autoconf`` and 25 ``automake`` tools required by RTEMS are not versioned and vary between RTEMS 26 versions. If you use a single *prefix* there is a chance things from different 27 versions may interact. This should not happen but it could. 29 ``automake`` tools required by RTEMS are not versioned and vary between the 30 various versions of RTEMS. If you use a single **prefix** such as the standard 31 **prefix** there is a chance parts from a package of different versions may 32 interact. This should not happen but it can. 28 33 29 For POSIX or Unix hosts the RTEMS Project uses :file:`/opt/rtems` as a standard30 *prefix*. We view this *prefix* as a production level path and we place31 development versions under a different *prefix* away from the production 32 versions. Under this top level *prefix* we place the various versions we need 33 for development, for example the version 4.11.0 *prefix* would be 34 :file:`/opt/rtems/4.11.0`. If an update called 4.11.1 is released the *prefix* 35 would be :file:`/opt/rtems/4.11.1`. These are recommendations and the choice of 36 what you use is entirly yours. You may decide to have a single path for all 37 RTEMS 4.11 releases of :file:`/opt/rtems/4.11`.34 For POSIX or Unix hosts, the RTEMS Project uses :file:`/opt/rtems` as it's 35 standard **prefix**. We view this **prefix** as a production level path, and we 36 prefer to place development versions under a different **prefix** away from the 37 production versions. Under this top level **prefix** we place the various 38 versions we need for development. For example the version 4.11.0 **prefix** 39 would be :file:`/opt/rtems/4.11.0`. If an update called 4.11.1 is released the 40 **prefix** would be :file:`/opt/rtems/4.11.1`. These are recommendations and 41 the choice of what you use is entirely yours. You may decide to have a single 42 path for all RTEMS 4.11 releases of :file:`/opt/rtems/4.11`. 38 43 39 For Windows a typical prefixis :file:`C:\\opt\\rtems` and as an MSYS2 path44 For Windows a typical **prefix** is :file:`C:\\opt\\rtems` and as an MSYS2 path 40 45 this is :file:`/c/opt/rtems`. 41 46 … … 46 51 47 52 Project specific sandboxes let you have a number of projects running in 48 parallel with each project in its own sandbox. You simply have a prefix per 49 project and under that prefix you create a simple yet repeatable structure. 53 parallel with each project in its own sandbox. You simply have a 54 :ref:term:`prefix` per project and under that prefix you create a simple yet 55 repeatable structure. 50 56 51 57 As an example lets say I have a large disk mounted under :file:`/bd` for *Big -
user/start/index.rst
raae09e2 rea0777e 7 7 8 8 RTEMS is an open source real-time operating system. As a user you have access 9 to all the source code and this `Getting Started`_ section will show you how10 youbuild the RTEMS compiler tools, kernel and 3rd party libraries from source.9 to all the source code. This ``Getting Started`` section will show you how you 10 build the RTEMS compiler tools, kernel and 3rd party libraries from source. 11 11 12 12 .. include:: basics.rst
Note: See TracChangeset
for help on using the changeset viewer.