Glossary of Terms
Actuators change the system’s environment.
Alarms set up points in the future when some action is to take place.
API is the abbreviation for Application Program Interface. Continue reading
What does real-time mean?
There are a number of time elements involved in the characteristics of a task. One of those is the term “real-time” when applied to a task (or even to an entire application). Applied to a task, that usage alone is insufficient and can even be misleading.
It is important to understand what this commonly used term means. A misunderstanding can lead to a poor choice of a system architecture. A poor choice could lead to less than desirable system performance if not outright failure of the application. Continue reading
Types of Tasks in Novos Environments
An embedded system is one in which one or more program tasks execute in some order to perform the work of the application. Each one is designed and coded to take care of a particular aspect of the application.
How many tasks are required depends on the application and its requirements, especially the requirements that deal with time and deadlines. There are several types of tasks, each of which has a particular nature when it comes to its temporal performance. Continue reading
Code Models of Novos Tasks
All Novos environments support a mix of Foreground and Background operations. Foreground operations may consist of one or more Foreground execution entities such as Deferred Interrupt Handlers (DIH), Event Action Routines (EAR) or Foreground tasks (FG Task).
Background operations consist of one or more Background tasks (BG Task). Each type of execution entity has its own characteristics. Continue reading
Novos Task Model Selection
Selection of the right type of task model depends on what the task is trying to do and what its requirements are. The typical multitasking RTOS products only support one type of task which it schedules with a pre-emptive priority policy.
That may not be the best choice, especially for RAM-constrained microcontrollers where it could prove totally unworkable because of that model’s potentially large RAM usage for stacks. Continue reading
Effects of Task Model Choice on RAM Usage in ARM Cortex M0/M0+ Applications
Selecting the right application framework (a.k.a. environment) for an embedded system can lead to use of a smaller, less expensive microcontroller, or lower power consumption, or a simpler system architecture supporting application code that is easier to debug, test and document.
The Cortex-M0/M0+ processors are ideal for small, high volume applications that are often very cost-sensitive. Selecting the right application framework and supported task models can have a substantive effect on ease of application development, maintainability and recurring costs, all of which affect the bottom line. This article will discuss some ways to capture those effects.
Super Loop – a Good Approach?
A Super Loop embedded design should not be rejected out of hand for lack of formality. Aside from the simplicity of a Super Loop, one of its greatest advantages is the need for a single stack, which can be important for processors with limited memory like the Arm Cortex M0 and M0+.
There is one major issue with a basic Super Loop application design: inconsistent timing. Continue reading
Keeping your code footprint small for Arm Cortex M0/M0+ Applications
Processors using Arm Cortex M0/M0+ cores typically have a limited amount of memory, necessitating efficient, compact application code. So, a small code size becomes an absolute necessity.
The first approach an embedded developer might consider is to “strip down” an RTOS, but even with a drastic pruning of unwanted functions, the resultant code would most likely still be a complete overkill in terms of size and complexity. Continue reading