A Real-Time Operating System (RTOS), sometimes known as a Real-Time Executive or Real-Time Kernel, is a library of functions that implements time-critical allocation of a computer system’s resources. Scheduler The scheduler, the central element in an RTOS, determines which application code entities get access to the CPU and in what order. In most commercial RTOSes there are three scheduling models: preemptive, cooperative (also called Round Robin), and time-sliced. Function Library The function library of the RTOS serves as the interface between the application code and the kernel. Often known as Application Program Interfaces (APIs), these functions encapsulate the operational requirements of the RTOS into its various services. Application code entities make requests to the kernel through these APIs in order to cause the desired programmatic behavior of the application. Classes and User-defined Data Objects RTOSes use data structures generally organised into groups or classes by operation type. The user defines the set of objects in each class that the RTOS will use in controlling the application. The names may be somewhat different, depending on the RTOS, but Table 1 shows the most common classes and how they relate to RTOS functionality: RTOS Functionality Classes Used to Meet the Functionality Application code entities used to manage orderly use of the processor Tasks, Threads, Interrupt Service Routines (ISRs) Synchronizing with events Counting Semaphores, Event Flags Moving data between application entities Queues, Mailboxes, Pipes Managing the demands of the application with respect to time or some other independent variable. Timers, Counters, Event Sources, Alarms Managing RAM usage RAM Pools, Memory Partitions, Memory Regions Controlling exclusive access to a resource Binary Semaphores, Mutexes RTOS Properties and Functions Primary: Manage the microprocessor and other resources to meet the requirements of the application Respond to, and synchronize with, events Move data efficiently between processes Manage the demands of the process with respect to an independent variable such as time Perform in a predictable manner with operations that take place within a predictable period of time Secondary: Efficiently manage RAM Ensure exclusive access to resources ...
Is Heartbleed the inevitable result of open source software?
Is open source software safe to deploy? Damien Choizit has written a thoughtful opinion piece in Software Development Times in the aftermath of the Heartbleed OpenSSL debacle. He writes, “the question on everyone’s mind is, ‘What does this mean for open-source software development?’ The truth of the matter is, Heartbleed wasn’t the real problem. Rather, it was with how we currently view and deploy open-source and outsourced code.” Choizit goes on to blame, not the OpenSSL team, but the mindless OEM and ODM development teams who blindly use open source software with the assumption that it must be solid. At Quadros Systems we have long been skeptical of the lemming-like move to open source without a commensurate look at what is really in the code. The lure of “free” software has blinded many to some of the inherent risks. 1. Does the ready availability of open source software and the ability by malicioius hackers to study it make it more prone to trapdoors and backdoors? 2. Do developers assume that because it is open source, thousands of others must have already checked out the code, so it must be safe? In this new era of “the Internet of Everything” your embedded device may be more vulnerable than ever. ...
Atollic and Quadros Systems Partner to Offer RTOS-Aware Debugging
The Atollic® TrueSTUDIO® C/C++ embedded development suite for ARM® microcontrollers now offers debug visibility for the RTXC™ Quadros™ real-time operating system. Thirteen dockable windows provide deep insight into the status of the RTOS during a debug session. This feature is included in Atollic TrueSTUDIO v4.1 which was just released last week. (click on images for larger view) Get more information here Atollic® TrueSTUDIO® is the leading C/C++ development tool for ARM® developers, reducing time to market and increasing efficiency in your next embedded systems project. Atollic TrueSTUDIO is based on one of the most widely used compilers in the world, thus providing proven and reliable code generation, compact code and high performance for ARM7™, ARM9™ and ARM Cortex™ projects. Atollic TrueSTUDIO conforms to open standards, such as the ECLIPSE™ IDE framework and the GNU toolchain, significantly reducing training and porting costs across teams and projects. More information on Atollic TrueSTUDIO can be found here: http://www.atollic.com/index.php/truestudio ...
Biggest problems for embedded systems developers?
A recent thread in the Real Time Embedded Engineering Group on LinkedIn raised some interesting issues among developers when they were asked about their most difficult problem areas. Do these sound familiar? Unrealistic development schedules set by managers who don’t understand development Deficient documentation of the processor Insufficient errata; struggling with a problem for two years, contacted the manufacturer with no result, and 1 year later there is the errata. Finding and resolving timing issues Weak or poor tools: debuggers, emulators Bosses expecting if I kneel or spend time with the device it may relent and start working Learning NEVER to use a device/processor/controller if there aren’t many ‘how to, why, when” questions on Google. The device is too good to be true or else you end being the only using and fighting the problem. Low level debugging and overall performance of the system Hardware/software co-development. Finding root causes when both the code and the hardware are suspect. A paucity of available low-level-embedded example code Hardware debugging, especially during software integration on a new design where all hardware unit tests showed OK but putting it altogether creates a side effect. A badly written device driver delivered with the H/W; caused havoc and a delay of more than 4 months S/W interface which was way too complex to interpret on an embedded system Of course at Quadros Systems we would argue that starting with the right software platform can make a big difference. RTXC Quadros RTOS-based software is delivered fully integrated with working drivers and interfaces with a binding to your chosen tool environment. Start with the provided sample project and you are good to go. Our Release Notes with tool caveats can reduce the learning curve up front, and save valuable time when development crunch time begins. We know our customers save weeks, if not months, over developing a product using free or poorly tested software. Find out more about how Quadros Systems can save you time and aggravation. ...
RTOS Source code vs. Object Libraries
Why would anyone pay for an RTOS or other embedded software?
Maybe this is a question you have asked. Maybe it’s a question you live by. After all, why pay for software when you can download something similar at no cost? You’ve heard it before but you do get what you pay for. That doesn’t mean that a free RTOS is worthless. What it does mean is that you are on your own. Maybe you’re the hero type; a talented embedded engineer that can code yourself out of any situation. Maybe you trust the “community” to help you out if you get into trouble. Maybe you are a newbie and a bit naive about the complexity of embedded development. It’s not really free. What I mean is that it may be free to you (to use) but somebody paid for it. Maybe it was a microcontroller supplier trying to lure you in to using their platform. User beware; you could be locking yourself in to an software platform with limited functionality & support and no upgrade path. Or maybe the license locks you in to a particular processor supplier. What if you want to change? What about middleware? So you downloaded a free RTOS but then you realize you need USB or TCP/IP or a file system? What do you do? License a bunch of software pieces from different suppliers and then piece them together? At Quadros Systems you are purchasing value and expertise, with years of embedded development expertise. A company that will stand by you, to get you through those days when you are stuck on a difficult problem and behind schedule. Developing reliable embedded systems is not easy. The smallest integration detail or incorrect parameter can take weeks to debug. Getting the right advice at the beginning of your project can be of critical importance. At Quadros Systems we take the time to understand your project and the assumptions and requirements behind it. And then we try to match our software to what you need. If we don’t have it, we won’t try to force-fit a substandard solution to make a sale. Want to work with an RTOS company that cares about results? Contact us at +1 832-351-2830, use our information request form to tell us about your project, or send an email to info@quadros.com. Get more information about the Quadros Difference here. ...
RTOS Explained: Understanding Interprocess Communications
A key feature of any kind of operating system is to be able to pass data between processes (tasks, threads, and interrupt service routines). The best RTOSes give the application developer as much flexibility as possible in how to do this. A single messaging option could be good for one situation but not for another. The RTXC Quadros RTOS provides three different object classes for passing data. Each class has unique properties that support interprocess communication according to the needs of the application. All three allow both synchronous and asynchronous communication between execution entities through the use of kernel services. And all three support a design that allows multiple producers and consumers for maximum application flexibility. The Queue class allows user-defined, fixed-size data to be passed in First-In-First-Out (FIFO) order between tasks, preserving its chronological nature. Queues are circular. The kernel copies data from a source buffer into the queue (enqueue) and from the queue into a destination buffer (dequeue) in three variants: simple enqueue/dequeue; enqueue/dequeue waiting on full/empty conditions; and enqueue/dequeue with limited duration waiting on full/empty conditions. The RTXC kernel maintains the status and ensures proper operation on EMPTY and FULL conditions. Under normal conditions the services associated with the Queue class provide the necessary synchronization. However, in the case of certain transitional conditions when special synchronization is required, queue semaphores are also supported. These queue semaphores are used in connection with RTXC services that operate on a set of semaphores associated with multiple queues or other types of events in order to eliminate polling for available data. The Mailbox/Message class allows variable length data to be passed from a sending task to a receiving task with or without a priority. Mailboxes are globally available to all tasks and are exchange points for messages sent by a sending task to a receiving task. The sender and the receiver must agree on the mailbox they will use for passing Messages between them. Messages are prepared by the sending task and consist of a message envelope and a message body. As a matter of system safety, the Message envelope is allocated by the sender but maintained by the kernel.The kernel has no interest in the message body other than to see to its delivery at the designated mailbox. Only the sender and the receiver tasks know the form and content of the message. Due to the fact that messages sizes can vary, message services do not copy the data into a mailbox. Instead, they manipulate pointers to the message. The result is a clean, efficient means for passing data of any size. The developer can choose to pass data in a FIFO manner or in one of two priorities, Urgent or Normal. The receiver task gets Urgent priority messages before those of Normal priority. A task can send Messages synchronously or asynchronously. For synchronous messages the sending task sends the message and waits for the receiver to acknowledge its receipt before proceeding. (NOTE: it is possible to associate an alarm with the receipt of the acknowledgement so that the duration of any waiting condition can be limited.) For asynchronous message transfers, the sending task sends the message but continues without waiting for an acknowledgement. The task can choose to wait at a later time for an acknowledgement. Normal send/receive operations have the same three variants as Queues: simple send/receive; send/receive waiting for successful completion; and send/receive with limited duration waiting for success. Like Queues, Mailboxes have related semaphores intended for use with transitional events to eliminate the necessity of polling for available data. The Pipe class, allows data to be passed from a producer task, thread or Interrupt Service Routine (ISR) to a consumer task, thread or ISR. Pipes are data passing mechanisms in the RTXC Quadros RTOS that permit rapid, unidirectional transfers from one or more producers to one or more consumers. The producer or the consumer may be an ISR, a thread or a task. Pipes are ideally suited to communications applications where data is acquired and buffered at a high frequency and then must be processed rapidly while the next block is being acquired. Functionally, pipes are buffers of data that are filled by the producer and processed by the consumer. The RTXC Quadros pipe services perform the necessary functions of managing the buffers in the pipe while the actual reading and writing of the data in the pipe buffers is the responsibility of the consumer and producer, respectively. In operation, the producer allocates a free buffer from the pipe, fills it with data, puts it back into the pipe. The consumer gets the full buffer, processes the data in it, and then frees the empty buffer back to the pipe where it can be re-used. Normally, pipe buffers are allocated sequentially and processed in the same order. However, RTXC also permits the producer to put a full buffer at the front of the pipe instead of at the tail, causing the consumer to process it next. Pipes can also be associated with thread gates (in the RTXC/ss configuration) so that certain pipe operations can result in operations on associated thread gates. Such a capability permits close synchronization between pipe producers and consumers and minimizes the amount of RAM required for pipe buffers. Summary The three flexible interprocess communications object classes in the RTXC Quadros RTOS eliminates the necessity of trying to force-fit one method of moving data into all situations a design might require. The developer can choose the one that best fits the application’s needs and have the appropriate kernel services to implement efficient data transfers for optimal time and memory considerations. ...
RTXC Quadros RTOS supports CEVA-X DSPs
We have been working closely with CEVA, Inc. to support their versatile CEVA-X family of low power, high performance DSP cores using the CEVA-Toolbox™ suite of development tools. CEVA holds 90% of the market for DSP cores and boasts adoption by many leading SoC developers. Today we announced our support for CEVA-X1622, CEVA-X1641 and CEVA-X1643 DSP cores. Read more about RTXC/CEVA integration here. ...
RTOS Explained: Understanding Event Flags
To fully understand event flags it will be helpful to read the previous blog entry on semaphores since both semaphores and event flags are techniques used by RTOSes for synchronizing tasks. Semaphores and event flags must have the inherent capability to capture and retain information about an event’s occurrence since the system may be otherwise occupied when the event happened. Event flags are bits and the usual way of handling them is to group them into larger data elements. Different efficiencies can be obtained with different sizes, so it is not uncommon to see one RTOS that uses an event flag grouping of a byte and others that use a short or a word. Whatever the grouping, it is usually called an event group. The application developer assigns the association of flags in the group to their related events. At time of initialization, the common procedure is to set all flags in an event group to a value, indicating that the associated events have not occurred. From there on, the content of the event group at any given moment is a joint effort between the tasks that use it and the operating system. The system may set a flag to indicate the event’s occurrence but it is usually the responsibility of the task to cause the flag to be reset. This shared responsibility exposes the vulnerability of event flags – if the task doesn’t reset the flag before the next event arrives, an event can be lost, which can have varying degrees of consequence. While there is that glaring vulnerability, event flags still have some very attractive features. For one, it is very simple to perform logical testing of the flags. A task can test on a certain configuration of flags in an event group and wait if that condition is not met. Testing on the logical OR condition of a set of event flags allows a task to wait until any one of the events occurs and to identify which one simply and easily. In the same way a task can wait for a logical AND condition in which all of the event in a set must occur before the waiting task can proceed. Event flags can be designed so that they are reset upon a trigger or left intact so that the testing task can determine which one of them happened. This is most likely to be the case when using a set of event flags in a logical OR manner. When the testing task has made its determination as to which event triggered the task’s release, it must issue a request to reset them in order to prepare for the next occurrences. When the event flags are used in a logical AND condition, the task does not get triggered until all of the events in the set have occurred, leaving no question about which events happened. In this condition, resetting of the event flags can be managed by the system to reset on triggering, which is much less likely to run into the race condition one can easily encounter if the task resets the event flags in an Or condition. So within the boundaries of response time for the various events and their frequency of occurrence, event flags can be a very useful object for managing events and synchronizing with them. While event flags are easy to use, one downside to their use is that it can be difficult to process an event deterministically. For system designs where the event groups are available to all tasks, it is possible (and quite likely) that a single event group may hold event flags that are tested by multiple tasks. Such usage demands that each task have a unique testing trigger set up for that event group. When any one of the events in the group occurs, the set of triggering conditions must be examined to see if any of the triggers have occurred. It might be a bounded operation dependent on the number of triggering conditions in action, but it is not deterministic. Event flag objects can be included in an RTOS with a minor increase in code footprint. For that reason alone, they are worthwhile to include provided that the vulnerability to event loss is not a concern. ...
RTOS Explained: Understanding Semaphores
A fundamental requirement of a competent multitasking system is a flexible means to detect occurrence of an event and then to synchronize a task with that event (external or internal; synchronous or asynchronous). The requirement is usually met by either semaphores or event flags. Whichever object type is used (and some RTOSes support both) their purposes are identical: synchronize a task as near as possible to the actual time of the event’s occurrence. Semaphores and event flags must have the inherent capability to capture and retain information about an event’s occurrence since the system may be otherwise occupied when the event happened. This is known as event memory. The methodology for this event memory constitutes the primary difference between semaphores and event flags. The term “semaphore” is derived from the nautical use of signaling flags to spell out messages in which the message’s characters are based on the position of the two flags, the semaphores. Except for the concept of signaling, the analogy ends there. In the world of computing, there are many variations to how semaphores are designed and operate, especially in conjunction with real-time operating systems. The most commonly used semaphore model is one that has a counter and a set of tasks that are waiting on the associated event. This is the counting semaphore model and it is found in most commercial RTOS products today. The count element of the semaphore serves as the event memory. In its basic implementation, the semaphore’s count increments each time its associated event occurs and decrements it each time a task tests it when its count is greater than zero. A count greater than 0, means events have happened for which tasks have not yet tested. A count of 0 means that no events have occurred since the last time the semaphore was tested. The set of waiter tasks is a record of those tasks that are waiting for the event to occur before proceeding further. Of course, it is not necessary to wait on an event if it has not occurred at the time of the test. It is certainly possible for a task to poll a semaphore and to continue processing depending on whether the associated event has or has not happened. That’s not usually what is considered good design, so let’s put it aside and focus on how the semaphore would normally be used. When the counting semaphore is initialized, its count element and the set of waiting tasks are cleared to null states. If a task tests the semaphore associated with an event and it has not yet occurred, its count isn’t changed but the task becomes blocked and is added to the set of waiters. When the event eventually occurs, the semaphore’s count is incremented by 1. And if it has waiters, one or more of them can be resumed, depending on the design of the system. But regardless of the manner in which the system releases waiter tasks, the semaphore’s count would be reduced by 1. In the RTXC Quadros kernel, the application developer may choose to have waiting tasks released from the semaphore’s set of waiting tasks in priority order or all at once. If, on the other hand, the event occurs before a task has come around to testing for it, the count element is incremented by one, setting the semaphore’s event memory. When the next test of the semaphore occurs, the operating system reduces the semaphore’s count by 1 and allows the testing task to continue without loss of CPU control. A semaphore may be organized in various ways and takes various amounts of RAM, depending on that organization. Some counting semaphores can be organized as a single byte, others can require many more. Regardless of the organization, the counting semaphores’ can accurately maintain the count of multiple occurrences of the associated event without losing even one. This is one of the reasons the RTXC Quadros kernel uses counting semaphores as the primary mechanism for synchronizing tasks with those events. Variations on this basic semaphore permit multiple semaphores to be signaled when one event occurs. Likewise, one task can synchronize with any one of a set of events to occur by waiting on their respective semaphores, producing a logical OR condition. There are other types of semaphore testing options. One is to have the testing task blocked for a certain number of ticks (instead of an indeterminate wait). In RTXC Quadros kernel, it is permissible to set a semaphore’s count to a negative value in order to have tasks wait for multiple occurrences of the associated event before being triggered. The RTXC Quadros RTOS also allows semaphores to be associated with events in other classes. For instance, a semaphore can be associated with an alarm’s expiration or an empty queue receiving an entry. This provides additional synchronizing flexibility that allows disparate objects to be logically combined so that the developer can trigger a task to start at some determined period when any one of them occurs. ...