Custom system integration
Embedded Redesign
Board Support Package for System Houses
Three sample architectures for time-critical functions
Depending on response time, peripheral connectivity, and system architecture, different approaches may be appropriate. The following examples illustrate how time-critical functions in embedded systems can be specifically separated from the main logic.
Internal microcontroller core in the SoC
External microcontroller via SPI
Dedicated controller via USBWhy Real-Time Capabilities in Embedded Systems Is a Matter of Architecture
Time-critical responses cannot be evaluated solely at the level of general system software. What matters is which signals need to be processed within what timeframe and how direct the response path is.
Main System
The main system typically handles tasks such as communication, data processing, visualization, and high-level control logic. Its primary focus is on functionality and integration capabilities.
Time-Critical Triggering
Limit switches, overload signals, limit violations, triggers, or fast input signals require short and predictable response paths and often benefit from a low-level implementation close to the hardware.
Architectural Decision
Time-critical subfunctions are specifically offloaded to appropriate components. This results in clearly separated responsibilities and more robust embedded systems.
Embedded real-time system with i.MX 8 and internal ARM Cortex-M4
Embedded real-time system with i.MX 8 and internal ARM A particularly compact way to separate time-critical functions is to distribute them within a heterogeneous SoC. In this example, an i.MX 8 with an integrated ARM Cortex-M4 handles the low-level response logic, while the more powerful Cortex-A cores execute complex application functions in parallel.
Advantages:
- Short response paths within the same SoC
- Reduces the load on the main platform for time-critical functions
- Well-suited for low-power and wake-up scenarios
Suitable Tasks:
- GPIO events
- Sensor processing
- Audio-related control logic
- Trigger and clock functions
- Low-power monitoring
- Wake-up mechanisms
This allows high-level tasks such as communication, data processing, or user interface design to be separated from time-critical signals and responses. This approach is particularly valuable in situations involving short internal communication paths and energy-related requirements.
Why You Should Implement Time-Sensitive Functions Separately
Not every embedded system requires all of its software to meet the same requirements for response time and predictability. It often makes more sense to isolate time-critical subfunctions from the main logic rather than designing the entire system around the same response logic.
Connecting real-time-capable peripherals via SPI
When an embedded system needs to be expanded with clearly defined time-critical functions, an external microcontroller connected via SPI is often a practical solution. In this example architecture, an i.MX6 handles the main logic, while an ATmega acts as a near-real-time coprocessor to process hardware-related tasks locally.
Typical Functions of the Microcontroller
An ATmega can acquire data from analog sensors via ADC inputs, generate precise PWM signals for actuators, monitor digital I/Os, or serve as a local port expansion. Encoder signals, small displays, or additional interfaces can also be connected in this way.
Technical Advantage
Local processing reduces the load and jitter on the Linux system. Time-critical responses occur closer to the periphery, while the main system only transmits the relevant information or setpoints.
Hardware aspects
- Different logic levels between i.MX6 and ATmega
- i.MX6 typically operates at 1.8 V or 3.3 V
- ATmega-based systems often operate at 5 V
- Appropriate level conversion is required for SPI interfacing
SIGMA Chemnitz worked with great expertise and dedication to stabilize the entire system. As a result, the product is now significantly more robust in use, and customer satisfaction has increased.
Ing. Gerald Schloffer
CEO at AUG Elektronik GmbH
Initial Situation
SIGMA assisted AUG Elektronik GmbH in stabilizing and optimizing the overall system for an existing embedded system. The system was based on WEC7, custom drivers, and an application. The project involved a time-critical SPI interface between an ARM NXP i.MX6DL and an ATmega.
Technical Challenge
The central challenge lay not in a single software component, but in the interaction between the involved layers. According to the reference report, error patterns in such systems frequently arise at the interfaces between the operating system, driver logic, and application. Accordingly, the focus was on timing, the interaction of the software layers, and robust handling of communication via the SPI interface.
Our Approach
- Systematic analysis of the entire system
- Focus on the interaction between the operating system, customer-specific drivers, and the application
- Investigation of timing and layer interaction
- Stabilization of the time-critical SPI connection between the i.MX6DL and ATmega
- Optimization of robust communication processing via the SPI interface
By optimizing the interaction between WEC7, custom drivers, the application, and SPI communication, the overall system became significantly more robust in operation. A key outcome was an improvement in system reliability, which in turn had a direct impact on customer satisfaction.
Read the full case study to learn how SIGMA contributed to the stabilization of a WEC7 system.
Start download
Read the full case study to learn how SIGMA contributed to the stabilization of a WEC7 system.
Start downloadWhich signals and functions should often be considered separately
Not every function in an embedded system has the same requirements in terms of response time and predictability. Especially in cases where signals must be processed immediately or responses must be triggered without unnecessary delay, it makes sense to treat the main system and the response logic separately.
![[Translate to English:] Echtzeit Endschalter und Freigabesignale](/fileadmin/user_upload/echtzeit_ueberlast_grenzwert.webp "Echtzeit Überlast & Grenzwertsignale")
![[Translate to English:] Echtzeit Überlast und Grenzwertsignale](/fileadmin/user_upload/echtzeit_endschalter.webp "Echtzeit Endschalter & Freigabesignale")
USB as a bridge between the main system and the time-critical controller
In addition to SPI, there is another reliable way to combine the main system with time-critical control logic: connecting an application processor to a dedicated controller via USB. One example of this is connecting an i.MX6 to a TM4C129 based on an ARM Cortex-M4.
In this architecture, the i.MX6 typically acts as the USB host, while the TM4C129 functions as the device. USB 2.0 serves as the standardized communication bridge between the two computing domains. This is particularly useful when the controller side is required not only to process individual signals but also to handle more extensive peripheral and control logic.
The TM4C129 offers a wide range of interfaces and peripherals for this purpose. UART, I2C, SPI, CAN, ADC, PWM, QEI, and other hardware-level functions make it possible to establish a standalone real-time and peripheral layer alongside the main system. This allows time-critical or peripheral-related functions to be clearly separated and implemented robustly.
- i.MX6 as USB host
- TM4C129 as device
- Main system for complex system functions
- Controller for time-critical and peripheral-related tasks
- More extensive peripheral connectivity
- Additional communication interfaces
- Clear separation between the main system and the control logic
- Projects with a dedicated controller level
How We Evaluate Real-Time Capabilities in Embedded Systems from an Architectural Perspective
Real-time capability isn’t simply a matter of labeling a system as “real-time capable” across the board. What matters is which functions an embedded system must actually process, trigger, or monitor, and within what timeframe. We therefore do not evaluate operating systems, microcontroller-based architectures, and dedicated controller solutions in isolation, but always as part of a well-considered system-level decision.
Analyzing Real-Time Requirements
Which response times are actually critical? Where do jitter, interrupt load, or unclear responsibilities arise?
Clearly Separate Responsibilities
Which functions remain on Embedded Linux, and which are offloaded to the M4, RTOS-related components, or external controllers?
Define the Architecture
Depending on the application, various interfaces between the SoC and a real-time microcontroller may be appropriate.
Implementing Integration
Quality is determined by the implementation. Interfaces, communication logic, drivers, and hardware-related software must work together seamlessly.
We speak of real-time when it is not only the correct result that matters, but also the timing of the response. In embedded systems, this primarily applies to functions that must process or trigger signals within clearly defined time limits.
Not in every case. The key factors are where the time-critical function is actually executed and how short and robust the response path is. Depending on the system, it may therefore make sense to include a separate hardware or controller layer.
This is because higher-level tasks such as communication, visualization, or data processing can often be more effectively separated from hardware-level response chains. This results in clearer responsibilities and more manageable signal paths.
Typical tasks include GPIO events, wake-up functions, sensor processing, trigger and clock logic, PWM, encoder evaluation, and other hardware-related response chains.
Yes, provided the tasks are clearly separated. SPI is very well suited for connecting a microcontroller to a main system as a near-real-time coprocessor. The controller handles local processing, while the main system exchanges control values or results.
USB is a good option when a standardized connection is needed between the main system and a standalone controller domain. This is particularly true for complex peripheral setups, additional interfaces, or clearly separated control functions.
Not necessarily. An integrated microcontroller core is one possible architectural approach. The best solution depends on response time, peripherals, power requirements, communication overhead, and system architecture.
No. The examples shown are possible architectural approaches used in practice. The appropriate solution always depends on the specific application and the technical constraints.
We will be happy to present solutions for your industry and your processes. Talk to the specialists for SMEs.
request now
