ECROS Real-Time
Operating System
|
ECROS Real-Time |
Q - If ECROS is Non-Preemptive, can I use it in a hard real-time system?
A - There is nothing magic about preemption that makes it essential for hard real-time systems. (In fact, if you consider magic to be something that happens that you can't figure out the reason for, preemption can be a liability until you learn how to use it safely.) If you have deadlines in your system that cannot be missed, you can still use a collaborative RTOS such as ECROS. As compared to using a preemptive RTOS, you may have to perform more work in interrupt service routines and you may achieve a slightly lower overall CPU utilization. You will also have to be extra careful about dividing up the work of each task into "chunks" that can executed in a short time by the task function. This is to make sure that control is returned promptly to the scheduler in case a higher priority task is waiting to run.
Q - Can I use Rate Monotonic Analysis (RMA) with ECROS?
A - If you understand the limitations of this type of analysis, you can use Modified Rate Monotonic Analysis to help find out if all the deadlines in your system design will be met. Basic RMA assumes so many things about your tasks that it rarely maps to a practical system. For example, it assumes that all tasks are periodic (become runnable at precise regular intervals) and have constant execution time. It also assumes that tasks are never blocked, but this assumption is relaxed by Modified Rate Monotonic Analysis (MRMA). You can use MRMA with ECROS by simply including the maximum execution time of any task, not just of higher priority tasks, in the blocking time calculation. This is because ECROS is non-preemptive so a task that becomes ready to run must wait for the currently executing task to yield even if that task is of lower priority.
Q - What happens if I destroy a one-shot timer after it has fired?
A - When you destroy a one-shot timer because it is no longer needed, it is a good idea to check first whether it has already fired and has therefore been automatically destroyed by ECROS. This is possible in the task that is the recipient of the events or message that the timer sends. It is not possible from a different task and in this case it is necessary to destroy a timer that might have already fired. A hazard exists in this case only if the timer resource has been reused for a new active timer and has the same handle. If this happens, the new timer will be erroneously destroyed. If the timer resource has not been reused or has a different handle, ECROS will recognize the attempt to destroy a non-existent timer and quietly ignore it. To decrease the probability of the hazard, ECROS recycles resources in a first-in-first out manner and cycles the handle of a resource through more than one value. In an application that makes extensive use of one-shot timers that may be destroyed by tasks other than the recipient of their events or messages, you should be aware of the existence of this hazard. The hazard exists as a convenience and efficiency tradeoff. Specifically, having ECROS automatically destroy and recycle timers as they fire saves effort in the application.
Q - Why can't ECROS just tell me if a timer has fired when I want to destroy it?
A - When a timer fires and ECROS destroys it, the timer resource (the memory used by the timer) is made available for reuse. Eventually, the same handle will be used for a different timer. Asking ECROS if the old timer has fired using its handle will result in the incorrect answer since ECROS will be looking at the new timer using the same handle. The way to tell if a timer has fired is to look for the events or message it sends. If this cannot be done, it is no less safe to go ahead and destroy the timer than it would be to ask ECROS if it has fired and destroy it based on the answer.
Q - When I send a lot of output to the UART, why do only pieces of it appear?
A - The reason that ECROS provides buffered stream I/O at the UARTs is to avoid user programs blocking while characters are transmitted. The output is instead stored in a buffer and sent out of the UART by interrupts while the application continues with something else. However, the buffer can only hold so many characters and if you put in more than it can hold it will overflow. The transmit buffer size is established at compile time up to a maximum of 128 bytes. You must pace output to the UART streams to avoid buffer overflow. ECROS cannot overcome the limited rate at which data can be transmitted from the UART. However, it does allow you to get on with other work while that is going on. A planned enhancement to ECROS will allow you to receive an event when the transmit buffer becomes empty. You will be able to use this to resume sending to the stream.
ZiLOG and Z8 Encore! are registered trademarks of ZiLOG Inc.
Copyright © 2004, ECROS Technology, all rights reserved.