FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

ARM Cortex M0 and M0+ processors are supported.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Class FB EFB FCFS RRS PPS
Deferred Interrupt Handlers * * * * *
Event Action Routines * * * * *
Foreground tasks * * * * *
Background tasks * * *
Alarms and Timers * * * * *
Queues * * * * *
Event Groups * * * * *
Semaphores * * * *
Memory Pools * * * *
Mutexes * * *

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. Except for the Novos FB environment, all objects can be closed to further use.

Back to the top of FAQs

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.

Back to the top of FAQs

No. The Novos environments are not based on any standard.

Back to the top of FAQs

Not specifically. However, the Novos EFB environment does many of the same things that are found in OSEK BCC1.

Back to the top of FAQs

02. Distribution and Pricing

Yes. The complete source code for the selected Novos environment is included in the download package.

Back to the top of FAQs

No. Scaling occurs as a result of what services the application uses.

Back to the top of FAQs

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.

Back to the top of FAQs

Each Novos service is described in the Services Reference Guide, which does contain examples.

Back to the top of FAQs

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.

Back to the top of FAQs

No. Novos documentation is generic with respect to a specific processor or microcontroller.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

A minimum of 5% of profits is given away to charitable causes, for example organisations providing humanitarian aid.

Back to the top of FAQs

03. Scheduling

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.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. Both the Novos RRS and the Novos PPS environments support round robin scheduling, which is also called Time Sliced scheduling.

Back to the top of FAQs

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.

Back to the top of FAQs

04. Background Tasks

There is no defined limit. The only real limitation is defined by the amount of available RAM in the system.

Back to the top of FAQs

Yes. runtime creation of tasks (as well as all other objects) is the only method supported in all Novos environments.

Back to the top of FAQs

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.

Back to the top of FAQs

There is no defined limit but a practical limit is 255.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

No. The priority of a FG task is defined when it is created.

Back to the top of FAQs

Yes, provided that the Novos library has been compiled with the DIAGNOSTICS conditional compilation switch defined.

Back to the top of FAQs

 

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

No. The priority of an EAR is defined when it is created.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. See answer to question 7.1.

Back to the top of FAQs

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.

 

Back to the top of FAQs

Yes. Novos services are permitted in the Deferred Interrupt Handler. Only one service is permitted in the Immediate Interrupt Handler part of the ISR.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

 

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.

Back to the top of FAQs

No. The priority of the DIH is defined at the time of its creation and is not modifiable.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. The Novos environment initialization procedure automatically creates a system time base counter that is incremented each time a time base tick occurs.

Back to the top of FAQs

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.

Back to the top of FAQs

10. Alarms

There is no practical limit. The only real limit is the amount of RAM available.

Back to the top of FAQs

Yes. As with other objects, alarms are created at any time after the initialization of the Novos environment.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

11. Passing Data

All Novos environments support queues to allow FIFO or LIFO passing of data in fixed size blocks.

Back to the top of FAQs

There is no practical limit to the number of queues an application can have except that limited by the amount of RAM.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. As will all Novos objects, queues are defined at runtime.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

No. A queue can only process one entry or retrieval per request.

Back to the top of FAQs

 

Yes. However, the Idle Task cannot pend to await an entry being put into the queue by another entity.

Back to the top of FAQs

Yes. However, the Idle Task cannot pend to await an entity removing an entry from the queue, creating room to put another entry.

Back to the top of FAQs

Yes. However, a Deferred Interrupt Handler cannot pend on a Full or Empty queue because it is a Foreground entity and cannot suspend execution.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. Event Flags are grouped by convenience into Event Groups.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes, except for the Novos FB environment, all Novos environments support Semaphores.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. This the purpose of the Event Group class.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. A single Event Group can contain event flags on which multiple Background tasks can pend.

Back to the top of FAQs

No. Foreground tasks cannot pend for any reason. However, they may test the contents of an Event Group without pending.

Back to the top of FAQs

Yes. Event Groups are accessible to all Novos execution entities.

Back to the top of FAQs

14. Semaphores

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.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes. The Semaphore model used by the Novos environments uses a counter to maintain the state of the semaphore.

Back to the top of FAQs

There is no defined limit except that of the available RAM.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

Yes, it is possible to send a signal post to several semaphores simultaneously in the Novos PPS environment.

Back to the top of FAQs

15. Memory Management

All Novos environments except the Novos FB environment support RAM management via the Memory Pool class.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

No. It is the user’s responsibility to keep within the boundaries of the mamory block.

Back to the top of FAQs

Yes. RAM can be allocated from a memory pool or directly from available User RAM or System RAM.

Back to the top of FAQs

 

Yes. However, a Deferred Interrupt Handler cannot pend to await a requested RAM block if the referenced memory pool is empty.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

17. Tools

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.

Back to the top of FAQs

Look on the website for the current list of supported tools.

Back to the top of FAQs

Debugging tools are not currently provided although that may change for some processors that have a sufficient amount of RAM to support them.

Back to the top of FAQs

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.

Back to the top of FAQs

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.

Back to the top of FAQs

 

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.

Back to the top of FAQs