www.faqs.org/faqs/realtime-computing/faq -> www.faqs.org/faqs/realtime-computing/faq/
These articles are repeated periodically for the benefit of new readers. Updated the HTML version locations (note that the two first one are real html whereas the others are text converted to html). Added the problem of year 2000 in real-time or embedded systems. Added RTOS Market Polling results (Mainly Japan Market Study) Added RMA Definition Book section updated Table of contents I- INTRODUCTION What is the purpose of this FAQ? III- PUBLICATIONS COVERING REAL-TIME TOPICS Books Magazines Other newsgroup and mailing lists dealing with real-time topics. IV- POLEMIC TOPICS Is Windows NT (or windows 95) a Real-Time Operating System? Which methodology should I use to design a Real-Time System? Which programming language should I use to develop a Real-Time System? What kind of processor should I use for my Real-Time System? V- MARKET Where can I find informations related to real-time products? Where can I find informations about real-time Conferences, Workshops and Tradeshows? RTOS Market Study (Mainly Japan Market) VI- RESEARCH AND FREE PRODUCTS Which Research Institute and Universities are involved in the Real-Time field? Free Real-Time Product lists VII- CONTRIBUTIONS AND FAQ LOCATION Where can I get the current copy of the FAQs? The purpose of this FAQ is to give sufficient knowledge to a new user in the Real-Time field and to serve as a reference to the engineer working in this field. This FAQ gives an overview about each topic and refers to other ressources (Internet, Publications, Company) for a more complete information. If there was a formal charter for the newsgroup at the time of its creation, we don't have access to it at the moment. However, if you are asking about a particular real-time system, see below for a (possibly) better place to start. If you are requesting information, consider setting: -- When following up, please change the Subject: line if the subject has really changed. However, short offers by vendors to provide further information by email are usually seen as acceptable. There are _several_ definitions of real-time, most of them contradictory. Unfortunately the topic is controversial, and there doesn't seem to be 100% agreement over the terminology. Guaranteeing timing behavior requires that the system be predictable. The piece is moving, and the robot has a small window to pick up the object. If the robot is late, the piece won't be there anymore, and thus the job will have been done incorrectly, even though the robot went to the right place. If the robot is _early_, the piece won't be there yet, and the robot may block it. Another example is the servo loops in an airplane when on auto-pilot. The sensors of the plane must continuously supply the control computer with proper measurements. If a measurement is missed, the performance of the airplane can degrade, sometimes to unacceptable levels. It would be soft real time if the robot arriving late meant a loss of throughput. Much of what is done in real time programming is actually soft real time system. Good system design often implies a level of safe/correct behavior even if the computer system never completes the computation. So if the computer is only a little late, the system effects may be somewhat mitigated. One will occasionally see references to "real-time" systems when what is meant is "on-line", or "an interactive system with better response time than we used to have". For instance, although some have queried whether running "rn" is real-time, it is not, as it is interacting with a human who can tolerate hundreds of milliseconds of delays without a problem. Similarly, on-line stock quotation systems interact with humans. One will also see references to "real-time" systems when what is meant is just "fast". It might be worth pointing out that "real-time" is not necessarily synonymous with "fast"; In particular, frequently, algorithms that guarantee bounded latency responses are less efficient overall than algorithms that don't. One will also occasionally see discussions of "soft" vs. In many of these discussions, "hard" real-time means the type of real-time system discussed above, and "soft" real-time means systems which have reduced constraints on "lateness" but still must operate very quickly and repeatably. However, the definition is controversial, as some mean by "hard" and "soft" the degree of time constraints. For instance, a real-time process attempting to recognize images may have only a few hundred microseconds in which to resolve each image, but a process that attempts to position a servo-motor may have tens of milli-seconds in which to process its data. Robert Bristow-Johnson adds the following distinction (in the case of DSP): In a real-time DSP process, the analyzed (input) and/or generated (output) samples (whether they are grouped together in large segments or processed individually) can be processed (or generated) continuously in the time it takes to input and/or output the same set of samples independent of the processing delay. A common life example I like to make is standing in a line (or queue) waiting for the checkout in a grocery store. If the line asymtotically grows longer and longer without bound, the checkout process is not real-time. If the length of the line is bounded, customers are being "processed" and outputted as rapidly, on average, as they are being inputted and that process _is_ real-time. The grocer might go out of business or must at least lose business if he/she cannot make his/her checkout process real-time (so it's fundamentally important that this process be real-time). The last definition is the one used for real-time audio and video, for phone call over Internet, and so on. It means that the processing time is less than the time to get a sample. Note that in the case of Internet it is easy to get starvation because the sample arrivals depend on the bandwidth. A good O'Reilly text is "POSIX Programmer's Guide: Writing Portable UNIX Programs". Credit card in-hand, phone +1 202 371 0101 to place an order. Another contact is the IEEE-USA Customer Service Center at 800 678 4333 (+1 908 981 1393 for outside of 800 zone); A RTOS (Real-Time Operating System) has to be multi-threaded and preemptible. The notion of thread priority has to exist as there is for the moment no deadline driven OS. The OS has to support predictable thread synchronisation mechanisms 4. OS Behaviour should be known So the following figures should be clearly given by the RTOS manufacturer: 1. This value depends on the number of simultaneous pending interrupts. It should be predictable and independent from the number of objects in the system; The following points should also be known by the developer: 1. A good RTOS should have a good documentation, should be delivered with good tools to develop and tune your application. So even if some figures like the Interrupt latency, Context switch time are important, there are a lot of other parameters that will make a good RTOS. For example a RTOS supporting many devices will have more advantages than a simple very good nano-kernel. It refers to the real-time performance analysis of a system design that uses static-priority driven scheduling, in particular, the "rate-monotonic" static priority assignment, where tasks with shorter periods get the higher priorities, in a typical static-priority driven real-time operating system like pSOS VxWorks VRTX etc. You need to break your software into "tasks" with "periods" and "deadlines" (relative to the period) and you must be able to guess or prototype a rough "execution time" for each task. Also, for more precise analysis, it helps to know all the critical sections and their runtimes and who shares them, or at the least, the length of the longest critical section in all of your software. If you workload does not meet deadlines, the better tools can help you to explore changes to your workload, in order to meet all the deadlines. Stankovic and Krithi Ramamritham, IEEE Computer Society reprint series, Computer Society order number 819. It covers: Real-Time Environment, Distributed Solutions, Global Time, Modeling Real-Time Systems, Real-Time Entities and Images...
|
http://csua.com/feed/