Issues of using Intel Atom for embedded realtime tasks
After the Atom architecture showed itself in netbooks, some companies began to use Atom for Embedded Realtime applications. They make industrial controllers, drive on them the PLC code .
The same chips as in the netbook are usually not used in the factories. There is a special platform. At first there was Crown Beach , it is now starting to be used in Queens Bay designs. For IVI (car computer) has its own platform .
Naturally, meeting realtime requirements is a prerequisite. More on this under the cut.
What is “realtime” for x86? There are many criteria. Most often the first requirement is that the guaranteed time should pass between the triggering of an interrupt and the start of execution of its handler code (ISR). For some, it is 2 microseconds, for someone 10, some are willing to put up even with a 20 microsecond delay. With 100 microsecond delay, even if it happens once a week, few people are willing to work.
')
When this main requirement is satisfied, the client, choosing a platform, begins to take into account other factors: productivity, price, how much electricity he wants to eat, how hot it is, how supported by the vendor, how easy it is to write software for it.
Atom processors work quite fast, there is a SIMD. Unlike the usual desktop / netbook options, the chips included by Intel in the Embedded Roadmap are maintained and produced for a long time (from 7 to 10 years). On x86, developing software or using ready-made is relatively easy - after all, the most common architecture. Another useful VT - hardware support for virtualization. For example, only on x86 you can drive RTOS at the same time to control the equipment and Windows XP for the GUI. By the way, in this industry it is fashionable to call the user interface not the GUI, but the HMI (Human Machine Interface). And before it was MMI. Like, men used to work with machines, and now - human beings.
If I already wrote - “interrupt latency”, then it is necessary to determine which one. legacy, MSI, local? The two most important cases are the local APIC timer, and the MSI-X peripheral interrupt.
What OS are used? VxWorks, Integrity, QNX, Windows CE, heavily doped with Linux. Happens, is used Windows Embedded and even ordinary Windows XP SP3. In the latter cases, the realtime code is executed exclusively in the ISR.
How to measure? It depends on the OS. On Windows, you can use DPC analyzer from Microsoft. If there is a problem with the ISR delay, then the DPC delays will also be. But not the other way around. Therefore, it is a good indicator, but not 100% accurate. I sometimes use Beckhoff Twincat. (By the way, Beckhoff just can do hard realtime industrial controllers on ordinary Windows XP) You can download a trial version from the site, start an empty project, and watch the interrupt latency from the local APIC timer. The easiest and most accurate way for Windows. It’s not so difficult to check if your netbook is suitable as a controller for a modern milling machine or an industrial robot. If it works, then there is a chance that even additional iron will not be needed - if suddenly the machine has a hole to control via EtherCAT.
A similar driver that measures the time to the Linux interrupt handler from 100 lines is written in half a day, or you can simply patch 20 lines in drivers / rtc / rtc-cmos.c to output the average delay.
Why is there an interruption delay of more than 5 microseconds on Atom? For example, on all X86 processors there is SMI - a very big evil from the point of view of an industrial controller. There is also a useful instruction - WBINV. Any driver will execute it - and the interrupt handler will have to drag the data from the memory for a long time first. There are a few more possible reasons. With all this you can fight.
In addition to the predictability of the start time of the interrupt handler, the code in the ISR should also work with constant performance. The two main factors that can reduce predictability are shared cache and hyper-trading. Unfortunately, the most energy efficient Atom processors are single-core. Hypertrending helps to get a slightly better performance, but affects the predictability of code execution in RTOS, if at a time GPOS is running on hyperthread. About this you can write a separate article, if it would be interesting to someone.
The same chips as in the netbook are usually not used in the factories. There is a special platform. At first there was Crown Beach , it is now starting to be used in Queens Bay designs. For IVI (car computer) has its own platform .
Naturally, meeting realtime requirements is a prerequisite. More on this under the cut.
What is “realtime” for x86? There are many criteria. Most often the first requirement is that the guaranteed time should pass between the triggering of an interrupt and the start of execution of its handler code (ISR). For some, it is 2 microseconds, for someone 10, some are willing to put up even with a 20 microsecond delay. With 100 microsecond delay, even if it happens once a week, few people are willing to work.
')
When this main requirement is satisfied, the client, choosing a platform, begins to take into account other factors: productivity, price, how much electricity he wants to eat, how hot it is, how supported by the vendor, how easy it is to write software for it.
Atom processors work quite fast, there is a SIMD. Unlike the usual desktop / netbook options, the chips included by Intel in the Embedded Roadmap are maintained and produced for a long time (from 7 to 10 years). On x86, developing software or using ready-made is relatively easy - after all, the most common architecture. Another useful VT - hardware support for virtualization. For example, only on x86 you can drive RTOS at the same time to control the equipment and Windows XP for the GUI. By the way, in this industry it is fashionable to call the user interface not the GUI, but the HMI (Human Machine Interface). And before it was MMI. Like, men used to work with machines, and now - human beings.
If I already wrote - “interrupt latency”, then it is necessary to determine which one. legacy, MSI, local? The two most important cases are the local APIC timer, and the MSI-X peripheral interrupt.
What OS are used? VxWorks, Integrity, QNX, Windows CE, heavily doped with Linux. Happens, is used Windows Embedded and even ordinary Windows XP SP3. In the latter cases, the realtime code is executed exclusively in the ISR.
How to measure? It depends on the OS. On Windows, you can use DPC analyzer from Microsoft. If there is a problem with the ISR delay, then the DPC delays will also be. But not the other way around. Therefore, it is a good indicator, but not 100% accurate. I sometimes use Beckhoff Twincat. (By the way, Beckhoff just can do hard realtime industrial controllers on ordinary Windows XP) You can download a trial version from the site, start an empty project, and watch the interrupt latency from the local APIC timer. The easiest and most accurate way for Windows. It’s not so difficult to check if your netbook is suitable as a controller for a modern milling machine or an industrial robot. If it works, then there is a chance that even additional iron will not be needed - if suddenly the machine has a hole to control via EtherCAT.
A similar driver that measures the time to the Linux interrupt handler from 100 lines is written in half a day, or you can simply patch 20 lines in drivers / rtc / rtc-cmos.c to output the average delay.
Why is there an interruption delay of more than 5 microseconds on Atom? For example, on all X86 processors there is SMI - a very big evil from the point of view of an industrial controller. There is also a useful instruction - WBINV. Any driver will execute it - and the interrupt handler will have to drag the data from the memory for a long time first. There are a few more possible reasons. With all this you can fight.
In addition to the predictability of the start time of the interrupt handler, the code in the ISR should also work with constant performance. The two main factors that can reduce predictability are shared cache and hyper-trading. Unfortunately, the most energy efficient Atom processors are single-core. Hypertrending helps to get a slightly better performance, but affects the predictability of code execution in RTOS, if at a time GPOS is running on hyperthread. About this you can write a separate article, if it would be interesting to someone.
Source: https://habr.com/ru/post/106598/
All Articles