[Hands-On RTOS with Microcontrollers] Introducing Real-Time Systems

Hands-On RTOS with Microcontrollers: Building real-time embedded systems using FreeRTOS, STM32 MCUs, and SEGGER debug tools

---

What is real-time anyway?

• Any system that has a deterministic response to a given event can be considered "real-time"
• If a system is considered to fail when it doesn't meet a timing requirement, it must be real-time
• How failure is defined can vary widely
  • speed of the timing requirement
  • severity of consequences if the required real-time deadlines are not met

The ranges of timing requirements

• To illustrate the range of timing requirements that can be encounted,
• let's consider a few different systems that acquire readings from analog-to-digital converters (ADCs)
  • The first system
    • control the temperature of a soldering iron
    • The parts of the system
      • MCU, ADC, sensor, and heater
    • The MCU is responsible for the following
      • Taking readings from a temperature sensor via the ADC
      • Running a closed-loop control algorithm
      • Adjusting the output of the heater as needed
    • Frequency
      •  50Hz
        • The temperature of the tip  doesn't change incredibly quickly,
        • The MCU may only need to acquire 50 ADC samples per second (50Hz)
      • 5Hz
        • The control algorithm responsible for adjusting the heater runs at an even slower pace, 5Hz
    • Both of these cases are examples of real-time requirements
      • The MCU reading the ADC has up to 20 ms to transfer data from the ADC ti internal memory before a new reading needs to be taken
      • The MCU also needs to be running the control algorithm to calculate the updated values for the heater output at 5 Hz
• How fast is real-time? it depends 
  • There is a high bandwidth network analyzer or ocsilloscope that is going to be reading an ADC at a rate of tens of GHz
  • closed-loop motion controllers, which will typically need to execute ther PID control loops between hundreds of Hz to tens of kHz
• In some of the previous cases, failure to meet a timing requirement results in poor performance of incorrect data being reported

The ways of guaranteeing real-time behavior

• Make sure a system is as simple as possible while still meeting the requirements.
• Solve the problem as simply as possible, without adding additional complexity
• If the functionality of the device is single-purposed, there are many cases where a full-blown RTOS can simply get in the way

Types of real-time systems

Hardware

• The original real-time system, hardware, is still the go-to for extremely tight tolerance and/or fast timing requirements.
• It can be implemented with 
  • discrete digital logic
  • analog components
  • programmable logic
    • Programmable logic devices (PLDs)
    • complex Programmable logic devices (CPLDs)
    • field-programmable gate arrays (FPGAs)
  • application-specific integrated component (ASIC)
• hardware has the advantage of performing operations in parallel and instantly
• downside for real-time hardware development
  • The inflexibility of non-programmable devices
  • The cost of full-featured programmable devices
  • The high cost of developing a custom ASIC

Bare-metal firmware

• The firmware isn't built on top of a preexisting kernel/scheduler of some type
• A bare-metal implementation has the advantage that the user's code has total control of all aspects of the hardware
• The only way for the main loop code execution to be interrupted is if an interrupt fires
• In this case, the only way for anything else to take control of the CPU is for
  • the existing ISR to finish
  • or another higher-priority interrupt to fire
• Bare-metal firmware solutions excel when there is a small number of relatively simple tasks to perform

RTOS-based firmware

• Firmware that runs a scheduling kernel on an MCU is RTOS-based firmware
• The introduction of the scheduler and some RTOS-primitives allows tasks to operate under the illusion they have the processor to themselves
• Using an RTOS enables the system to remain responsive to the most important events while performing other complex tasks in the background
• downsides
  • Inter-dependencies can arise between tasks sharing data
    • if not handled properly, the dependency will cause a task to block unexpectedly
    • Although there are provisions for handling this, it does add complexity to the code
• Interrupts will generally use task signaling
  • to take care of the interrupt as quickly as possible
  • and defer as much processing to a task as possible

Defining RTOS

 

Hard real-time systems

 

Firm real-time systems

 

Soft real-time systems

 

The range of RTOSes

 

The RTOS used in the book

 

Deciding when to use an RTOS

 

Summary