Frequently Asked Questions
01. General Questions
We use the term “environment” because it covers the spectrum of operational choices for embedded systems. Some call such foundation software a “real-time operating system”, or RTOS. Some use the term “Executive” or “Kernel”. Some just say “Scheduler”. Each of these terms implies certain capabilities or methodologies. Because the Novos family of products covers all of those terms, we chose a single description for all of them – Environment.
There are many ways to organize an embedded system’s application. We have selected the most popular ways and have built an environment for each one. Thus, we have very simple single task environments to fully capable multitasking environments. We leave it to the application designer to choose the one that most closely fits the application’s requirements.
ARM Cortex M0 and M0+ processors are supported.
The Novos environments source code can be compiled with tools from various tool manufacturers. We work with most tool providers who support the processors we support. You can find a list of the tool providers we currently support on the website.
The Novos environment source code is written in ANSI C. There are a few lines of assembly code in each environment that are necessary to take care of some very low-level details or processor management, usually where interrupts or context switching is concerned.
The short answer to this question is “Yes”. Hard real-time capability depends largely on the design of an environment, not just a Novos environment. It depends on whether the services offered by the environment are implemented in a deterministic manner or how the environment responds to internal or external events. The Novos environments are designed in such a way that the services support deterministic operations.
All but one of the Novos environments support the use of fixed priority Foreground tasks that can be organized to guarantee their schedulability to meet real-time requirements. You set their priorities using Rate/Deadline Monotonic Analysis based on their rates of execution periods or deadlines. If they pass a simple schedulability test, their real-time performance is assured.
Background tasks can also meet hard real-time requirements, especially in the Novos PPS environment. It uses pre-emptive priority scheduling of Background tasks and has the ability to respond very quickly to events.
The Novos environments are intended to be capable of being used in most applications. However, not every Novos environment is a good choice for a given application. We have targeted low power, IoT and sensor-based application, just about anything that would make use of a RAM-constrained processor.
Yes. Each Novos environment is designed to be an object code library of services when compiled. That library is linked with the application’s object code to form the load module for the target. Scaling takes place during the link phase when the linker discards unreferenced services.
There is no single answer to this question because there are many variables, including the specific Novos environment, the processor for which the source code is compiled and the efficiency of the compiler itself. The number of services used in the application also determines the ROM footprint. Compilers give the compiled size of the entire library but it is highly unlikely that an application would use every single service in the library. Consequently, the ROM footprint is almost always much smaller than the total size of the compiled Novos environment library.
There is no single answer for this question because the amount of RAM required varies by Novos environment and the processor being used. Typical numbers for this question range from a few tens of bytes to a couple hundred bytes. It could be more or less as there are many dependencies. These numbers do not include the amount of RAM used for stacks or the various objects created and used by the application, however.
The Novos environments support objects in several classes but not every Novos environment supports every class. The following table shows which classes are supported by which Novos environment.
|Deferred Interrupt Handlers||*||*||*||*||*|
|Event Action Routines||*||*||*||*||*|
|Alarms and Timers||*||*||*||*||*|
Yes. With the exception of the Super Loop or Idle Task, depending on the Novos environment being used, and a Counter for the system timebase created during the Novos initialization procedure, all objects in all Novos environments are created programmatically at run-time.
Yes. Except for the Novos FB environment, all objects can be closed to further use.
Yes. As a means of conserving RAM, closed objects are recycled when new objects in the same class are created. In some cases, even the user-specified RAM in a closed object can be preserved and recycled.
No. The Novos environments are not based on any standard.
02. Distribution and Pricing
Yes. The complete source code for the selected Novos environment is included in the download package.
No. Scaling occurs as a result of what services the application uses.
There is a Services Reference Guide and a User Guide for each Novos environment. The Services Reference Guide details every service supported by the Novos environment. The User Guide provides information about the design of the Novos environment, the classes of objects it supports and how they work.
Each Novos service is described in the Services Reference Guide, which does contain examples.
Both the User Guides and Service Reference Guides are available for a modest cost – refer to the FREE Downloads & Shop tab in the menu bar. The number of pages of user documentation for each Novos environment varies according to the environment. There are two volumes of user documentation for each Novos environment. The Novos FB environment has the fewest pages. The Novos PPS environment has the most pages. For all Novos environments, there are over 1,400 pages.
No. Novos documentation is generic with respect to a specific processor or microcontroller.
Nothing for basic use, which does not include support or maintenance. There are fees for supported usage and there is a fee for a commercial license. Additional developer licenses cost nothing, except for fees related to purchase of additional documentation volumes.
With the basic (Unsupported) license, there is no support offered. For a Supported license, email support may be purchased in tranches for a fee. Please contact us for fee structures and conditions.
The Novos environments support the scheduling policies most commonly used in embedded systems. Novos FB uses simple foreground/background scheduling. Novos EFB uses foreground/background scheduling but enhances the foreground with preemptive priority scheduling of fixed priority foreground tasks. Novos FCFS is a multitasking design that schedules fixed priority Background tasks on a first come, first served basis and also employs preemptive priority scheduling of fixed priority Foreground tasks. The Novos RRS environment is also a cooperative scheduling design that uses fixed priority round robin scheduling of Background tasks along with preemptive priority scheduling of fixed priority Foreground tasks. The Novos PPS environment combines all of the scheduling policies: Background tasks scheduled by preemptive priority scheduling, fixed priority first come, first served scheduling or fixed priority round robin scheduling. In the Foreground, the Novos PPS environment also supports preemptive priority scheduling of fixed priority Foreground tasks.
The time to switch tasks is always a difficult metric because there must first be an agreement on when the operation starts and ends. We like to say that it starts at a point in a Novos service where it determines that a context switch is required. It ends when a new task gains control of the CPU.
However it is measured, there is no single number. The time to switch contexts from one entity to another depends on the type of entity (e.g., Foreground task or Background task), processor and clock rate and compiler efficiency.
Yes. Both the Novos RRS and the Novos PPS environments support round robin scheduling, which is also called Time Sliced scheduling.
Yes. In the Novos PPS environment, Background tasks can use all three scheduling policies, first come, first served, round robin or preemptive priority scheduling. In addition, preemptive priority scheduling of fixed priority Foreground tasks is also available in all environments except Novos FB.
04. Background Tasks
There is no defined limit. The only real limitation is defined by the amount of available RAM in the system.
Yes. runtime creation of tasks (as well as all other objects) is the only method supported in all Novos environments.
Dynamic priority modification of Background task priority is permitted only in the Novos PPS environment. Background tasks are used in the Novos FCFS and RRS environments but those tasks must all run at the same priority and there is no support to change their priorities.
There is no defined limit but a practical limit is 255.
When the conditional compilation switch DIAGNOSTICS is defined, checks of parameters takes place on most Novos services. Nonexistent tasks (or other objects) will be detected.
Yes. Novos FCFS and RRS environments support non-preemptive Background tasks. The Novos PPS allows preemption based on task priority. The Idle Task is always subject to preemption in any Novos multitasking environment.
05. Foreground Tasks
Most but not all Novos environments support Foreground tasks. The Novos FB environment is the only one that does not explicitly support them.
A Foreground task has no stack of its own whilst a Background task does. Thus, a Background task can pend on an event and a FG task cannot. Once the FG task starts to run, it must continue to a point of completion. A BG task can run and block (pend) in order to wait on some event.
The default model is for four priority levels for Foreground task in all Novos environments. However, the number of priority levels is easily changed by a simple definition.
There is no practical limit to the number of FG tasks that run at a given priority level. FG task within a priority level are scheduled on a fist come, first served basis.
No. The priority of a FG task is defined when it is created.
Yes, provided that the Novos library has been compiled with the DIAGNOSTICS conditional compilation switch defined.
Yes. a Foreground task is pre-emptible by Foreground tasks of higher priority as well as by other foreground execution entities that have higher priority.
Yes. A parameter can be defined as a fixed value to be passed to the FG task when it executes. Alternatively, it is possible to define a dynamically determined value of a parameter to pass to the FG task.
06. Event Action Routines
An Event Action Routine is a Foreground execution entity that runs when a Novos service detects the occurrence of the event with which it is associated. For example, when an alarm expires, an associated EAR could run to perform some special operations tied to that alarm expiration. An EAR executes at a priority that is higher than those of Foreground tasks. The EAR can perform any operations legal for a Foreground execution entity and there is no restriction on its runtime. It may be interrupted and is pre-emptible.
They are both Foreground execution entities. The only real difference between the two is that the EAR has a higher priority than the Foreground task. Otherwise, they are the same.
No. The priority of an EAR is defined when it is created.
Yes. A parameter can be defined as a fixed value to be passed to the Event Action Routine when it executes. Alternatively, it is possible to define a dynamically determined value of a parameter to pass to the EAR.
07. Interrupt Handling
All Novos environments use the same two-level interrupt servicing model. The higher level is called the Immediate Interrupt Handler (IIH) and its purpose is to service the physical device that is causing the interrupt in order to clear it. Other than invoking the lower level of the ISR, the Deferred Interrupt Handler (DIH), the IIH does not involve and Novos services. The DIH is a Foreground execution entity with a priority higher than those of EARs and FG tasks. Multiple DIH priority levels are supported. The DIH can perform any operation it needs and invoke any supported Novos service. There is no restriction on its runtime. The DIH is interruptible and pre-emptible by higher priority DIHs.
Yes. See answer to question 7.1.
Depending on the processor being used, interrupts may be disabled for a few instructions when the interrupt is first recognized. Then by the Immediate Interrupt Handler when it schedules its associated Deferred Interrupt Handler. Otherwise, interrupts remain enabled in order to provide a high degree of responsiveness. However, if the user needs to disable interrupts, that is permitted.
Yes. Novos services are permitted in the Deferred Interrupt Handler. Only one service is permitted in the Immediate Interrupt Handler part of the ISR.
Interrupt latency depends on the processor and how long interrupt are disabled by the Novos environment. Novos services do not disable interrupts to ensure that interrupt latency is a function of the processor design rather than software. However, if an interrupt occurs during the Immediate Interrupt Handler of a previous ISR, a very small window where interrupts are disabled will have to be added to the normal processor-dependent latency.
Yes. This type of interrupt servicing must take place completely outside of the Novos environment and no Novos service can be invoked by the “zero latency” ISR.
08. Deferred Interrupt Handlers
The Deferred Interrupt Handler provides a place where application-specific operations take place relative to the associated interrupt. It is a Foreground execution entity and has the ability to invoke any Novos service supported for Foreground use.
The only real difference between the two is that a DIH has the higher priority. It also has a higher priority than the Event Action Routines. Otherwise, they are the same.
No. The priority of the DIH is defined at the time of its creation and is not modifiable.
Yes. A parameter can be defined as a fixed value to be passed to the DIH when it executes. Alternatively, it is possible to define a dynamically determined value of a parameter to pass to the DIH.
09. Managing Time
No. There is no class called “Timer” in the Novo environments. However, there is a class called “Alarm” that serves the purpose of permitting time-relative operations.
Yes. The Novos environment initialization procedure automatically creates a system time base counter that is incremented each time a time base tick occurs.
There is no specific value but many embedded systems use a very practical value of 1 msec. However, the smaller the tick interval, the more load there is on the processor. It is best to look at what interrupt load the processor can handle and then choose the most appropriate tick interval.
There is no practical limit. The only real limit is the amount of RAM available.
Yes. As with other objects, alarms are created at any time after the initialization of the Novos environment.
Yes. But the task must be a Background task. The Idle Task may not pend on an alarm expiration either even though it is a Background task. Foreground tasks may test an alarm for being expired but they cannot wait for it to expire.
If an alarm is cancelled and a Background task is pending on it, the pended service will return a Novos Service Completion Code (NSCC) to indicate the alarm was cancelled. It is your responsibility to check the NSCC to detect the cancelation.
11. Passing Data
All Novos environments support queues to allow FIFO or LIFO passing of data in fixed size blocks.
There is no practical limit to the number of queues an application can have except that limited by the amount of RAM.
The size of a queue is determined by two user-defined numbers – the number of bytes in a queue entry and the number of entries in the body of the queue.
Yes. As will all Novos objects, queues are defined at runtime.
Yes, options exist to put or get data from the head or the tail of a queue. In addition, it is possible to peek at the data at either end of the queue without removing the entry.
When a queue becomes Full or Empty, it may trigger an Event Action Routine. During the time that a queue is Full, no more data can be put into it. Likewise, when a queue is Empty, no data can be retrieved from it.
No. Queue entries are of a fixed size as specified by a user-specified property during creation of the queue. The entry size of a queue cannot be changed once the queue has been created.
If the application tries to put more bytes into a queue than the number of bytes specified for the queue’s entry size, the bytes in excess of the queue’s entry size will be discarded.
No. A queue can only process one entry or retrieval per request.
Yes. However, the Idle Task cannot pend to await an entry being put into the queue by another entity.
Yes. However, the Idle Task cannot pend to await an entity removing an entry from the queue, creating room to put another entry.
Yes. However, a Deferred Interrupt Handler cannot pend on a Full or Empty queue because it is a Foreground entity and cannot suspend execution.
12. Event Synchronization
All Novos environments support Event Groups, which are groupings of event flags. The event flags do not have to be related and the Event Groups are simply an efficient management device for handling events. All Novos environments except for the Novos FB environment support Semaphores as an additional means of event management and to provide low level exclusive access to an associated resource.
Yes. Event Flags are grouped by convenience into Event Groups.
There is no pre-defined maximum number of event flags allowed in an application except that defined by the amount of available RAM. Event flags require only a single bit and may be grouped into a larger data element, typically 16-bits.
13. Event Flags
Yes. All Novos environments support event flag grouping with the Event Group class. However, only Background tasks, excluding the Idle Task, can pend on a specific pattern of event flags in an Event Group.
Yes. This the purpose of the Event Group class.
The event flags in an Event Group may be tested by any execution entity in either the Foreground or the Background. However, only Background tasks can pend. Testing of the event flags in an Event Group is performed by Boolean AND or OR logic with a application-defined bit mask. For the AND condition to be TRUE, all event flags in a logic 1 state must match the corresponding bits in the bit mask that are also in a logic 1 state. For the OR test to be TRUE, any event flag in a logic 1 state must match the corresponding bit in a logic 1 state in the test mask.
Yes. A single Event Group can contain event flags on which multiple Background tasks can pend.
No. Foreground tasks cannot pend for any reason. However, they may test the contents of an Event Group without pending.
Yes. Event Groups are accessible to all Novos execution entities.
Yes. They are ideal for synchronizing Background tasks with events, especially in the Novos PPS environment. In the Novos FCFS and Novos RRS environments, a task that is pending on an event associated with a semaphore will be released when the event occurs but because there is no preemption, the task may not gain CPU control immediately.
Yes. A low level exclusive access capability is afforded by the Novos Semaphore model. However, it does not offer any support for handling priority inversions as does the Mutex class.
Yes. The Semaphore model used by the Novos environments uses a counter to maintain the state of the semaphore.
There is no defined limit except that of the available RAM.
Yes. Semaphores are associated with events by the application designer and are independent of any task. As such, any Foreground or Background task can reference a semaphore.
Normally, a Background task can pend on one object in the Novos FCFS, Novos RRS and Novos PPS environments. However, it is possible in the Novos PPS environment for a BG task to pend on any one of several semaphores to receive a signal post. This is a Boolean OR condition for the events.
Yes, it is possible to send a signal post to several semaphores simultaneously in the Novos PPS environment.
15. Memory Management
All Novos environments except the Novos FB environment support RAM management via the Memory Pool class.
No. Allocation of RAM blocks from a memory pool does not fragment the RAM because all blocks in the memory pool have the same size. Thus, they can be allocated and freed in any order without fragmentation occurring.
If there is an available block of RAM in a memory pool, the allocation of that block as well as freeing the block are deterministic operations. If there is no block available and the memory pool was created as a Dynamic Memory Pool, the requested block may be allocated from other sources, which may not be deterministic operations.
No. It is the user’s responsibility to keep within the boundaries of the mamory block.
Yes. RAM can be allocated from a memory pool or directly from available User RAM or System RAM.
Yes. However, a Deferred Interrupt Handler cannot pend to await a requested RAM block if the referenced memory pool is empty.
16. Exclusive Access
All Novos environments except the Novos FB environment support a counting semaphore model that includes the use of binary semaphores for low level exclusive access. In the multitasking Novos environments, Novos FCFS, Novos RRS and Novos PPS, support exists for the Mutex class, for more capable exclusive access management.
Yes. Once acquired, a mutex can be re-acquired by its owner task but not by another task. Any level of nesting is allowed but for each level of nested acquisition, there must be a balancing release of the mutex. When the number of nested levels balances with the number of releases, the mutex becomes available for acquisition by another task.
Only the Novos PPS environment supports management of priority inversions. It does so with either Immediate Inheritance Protocol (IIP) or Basic Inheritance Protocol (BIP) or none at all. The selection is defined by the user when the mutex is created.
In the multitasking Novos environments, it is possible to pend on acquisition of a mutex for a defined period of time. If there is a deadlock, the expiration of the expected completion time of the mutex acquisition provides a way to escape the deadlock.
No. The Novos environments are provided as C source code. You compile it to get the object library. Novos services are not generally reentrant but they are interruptible.
Look on the website for the current list of supported tools.
Debugging tools are not currently provided although that may change for some processors that have a sufficient amount of RAM to support them.
18. Driver Support & Evaluation Boards
Generally the Novos environments are delivered with a UART driver and a driver for the system timebase. Other drivers may be available and will be included at no extra cost.
Drivers, when they exist, are available at no charge. Tools may or may not carry a license fee for their use. You would have to consult the tool manufacturer.
See the website for the list of currently supported evaluation boards. Primarily, the Novos environment is delivered for a particular processor core. Due to the high volume of evaluation boards produced by the semiconductor manufacturers, it is very difficult to maintain board support for each and every one. If you have special needs for a particular eval board, contact us know. It may already be on our roadmap.