It is now possible to put together sophisticated and powerful embedded and control systems that are mostly composed of pre-existing working software. One of the demonstrations we showed at AMD’s recent embedded workshop was a small two processor (4 core) box running RTLinux and Windows XP. Embedded development teams for RTCore based products can mirror the decoupling of the RTCore architecture – one team can do the low level control application and other teams can work on all the non-time-dependent “enterprise” software. A printer controller might be developed by connecting a real-time component under RTCore that talks to sensors and actuators, a database and remote update/maintenance subsystem under Linux and an operator interface running under Windows XP. These three components can be developed independently by different teams as long as architects have correctly designed the interfaces. The RTCore component on current Opterons can guarantee either sub 10 microsecond or 1 microsecond worst case interrupt latency – depending on whether you share the processor core with Linux or dedicate a processor core to real-time. The Linux application could be made web accessible using Apache, for example, with a backend database either MySQL or Oracle or even DB2. The Windows application can go right to the video and our experience is that the double buffering of the Linux file system and Windows itself improves performance when running a virtualized windows kernel. A Sun Java application on the Linux side may connect to C# under Windows on one side and C++ or C executing in the RTCore environment on the other.
Let’s look at two example applications – a printer and an automobile “infotainment” system. One way to build a printer is as a system [FPGA: RTCore: Management: Operator] where RT software in RTCore manages a controlling FPGA on one side (that manages the sub microsecond requirements of the hardware) and provides paths for the Linux based Management and Windows based Operator subsystems to submit commands and get data. For a lighter infotainment system, perhaps using a single processor, we might need [Devices: RTCore: Display] where the RTcore component acts as a device accelerator, replacing dedicated hardware (such as a smart MPEG ) with software, a Windows based Display manages multimedia, and Linux is just used essentially as a BSP.
Security can be easily improved by making the three components cross check each other. For example, a remote update connecting to the Java based server under Linux may ask the Windows based and Rtcore based components to cross check certificates. An attacker would have to deal with three different operating system environments working together. Reliability can also be improved – e.g. by having Rtcore force a reboot of Linux or Windows if progress is not being made.
The underlying theme here which shows how far this new type of embedded software has moved from the traditional “hand crafted” embedded development process. Programmers have large functional components available to use in development instead of starting from the traditional impoverished low level embedded environment. The implications for both productivity and creativity are significant.