The hidden co-worker
Given the fact that silicon vendors do not pay much attention to the requirements of an embedded PC, most of the necessary embedded features are not supported by the chipset. It's for this reason that a specially designed onboard microcontroller on the COM can play an important role in making the PC an embedded PC.

By fully isolating most of the embedded PC features from the x86 core architecture, a COM offering a separate microcontroller frees up the x86 CPU and ensures 100% compatibility amongst various COM-based designs. Once this microcontroller is designed it can be reused again and again on different platforms.

Multi-Stage Watchdog. A watchdog (Figure 1, below) helps to prevent application software lock-ups. When the software hangs it can no longer trigger the watchdog. As a result of the missing trigger the watchdog will cause an interrupt, which allows the software to react to the problem, or it can force a system reboot or shut down.

In many cases it is a requirement that the watchdog is supported by separate hardware that is not part of the x86 platform itself. Moving the watchdog functionality to an onboard microcontroller allows both a fully-featured and isolated solution. Flexible watchdog implementations support a multistage-stage solution that can be triggered by software and/or external OEM hardware on the carrier board.

The watchdog should be designed to either cause an NMI, a hardware reset, a power button event or an ACPI event to inform an ACPI OS to restart or shut down. With multi-stage support the watchdog can be initialized to cause an NMI first and in case the interrupt service routine fails to fix the problem, reset or shutdown the system. This approach allows for a more flexible monitoring of the embedded software application.

Figure 1.It is important to have a watchdog that is supported by hardware that is not part of the X86 platform itself

High Speed I2C Bus. Many embedded devices such as sensors, converters or data storage can be easily connected to the I2C bus interface. Due to the simple protocol and the high availability of devices, the I2C bus is a frequently used low-speed bus interface in embedded applications.

If the onboard microcontroller supports a real I2C bus host controller, the embedded PC can offer an up to 400kHz, multi-master I2C bus that provides maximum I2C bandwidth to ensure fast transmission of large amounts of data.

Non-volatile User Data Storage. Some embedded applications may require non-volatile storage of critical and important operating data. This can be offered in the form of an EEPROM or flash memory chip. For small amounts of data a 32 byte area in an EEPROM may be sufficient.

To prevent end users from changing this data, it should be possible to lock the 32 byte EEPROM area and thereby making it read only. For larger amounts of data a 64kB flash sector in the BIOS Firmware Hub (FWH) device could be used.

Even if the mass storage media that holds the operating system is not functioning and needs replacement, the user data stored in EEPROM or flash memory will not be lost.

Manufacturing and Board Information. The EEPROM in the microcontroller can also provide a rich data set of manufacturing and board information. This information might include serial number, article number, EAN code, manufacturing and repair date and so on.

It can also keeps track of dynamically changing running time and boot count data. During the manufacturing process the static data must be written to the non-volatile memory within the microcontroller.

This can be read out later by the end users software in order to obtain detailed information about the COM used in the system. Boot counter and running-time meter provide information about how many times the system has booted and the number of hours the system has been running. This is very helpful information for product maintenance, RMA service and upgrades in the field.

BIOS CMOS Data Backup in NVRAM. A backup copy of the BIOS CMOS settings must be held in non volatile memory, e.g. the flash memory device. This allows battery less applications. If a backup battery is used it will also help prevent "non-booting systems" when the backup battery has failed since the system configuration is always maintained.

Power Loss Control. The onboard microcontroller could also provide an AC power loss control feature that defines the behavior of the module once power has been restored. The following modes of operation are typically supported:

* Turn On (Server Mode)
* Remain Off (Desktop Mode)
* Last State (Restores the previous power state before power loss occurred)

Flat Panel Auto Detection and Backlight Control. Extended Display Identification Data (EDID) is a well-known industry standard established by VESA. By understanding the basic EDID data structure, a fully-featured embedded BIOS can automatically detect and configure an attached flat panel.

When the EDID data is provided to the BIOS, panel selection in setup or configuration via proprietary data sets is no longer necessary. Additionally, the BIOS should have the ability to adjust the backlight intensity via a setup node as well as application software.

Figure 2. When the EDID data is provided to the BIOS, panel selection in setup or configuration via proprietary data sets is no longer necessary.

Built in CMB Battery. COMs are well suited for battery powered mobile applications. To simplify system integration in creating a battery powered device the embedded PC should come with built in support for a battery sub system.

The ACPI BIOS and the onboard microcontroller must be designed specifically to support a control method battery (CMB). The vendor is responsible for providing detailed information about how the BIOS interfaces to the battery system. If the guidelines set forth are followed then designers can easily implement their own battery solutions.

When using an ACPI OS, most of the battery functionality associated with portable computers can be supported on the embedded platform.

Figure 3. The ACPI BIOS and the onboard microcontroller must be designed specifically to support a control method battery (CMB).

Programming Interface. In today's market many COM manufacturers are offering a variety of features but these features are only as good as the customer's ability to access them. If easy access is not provided then the value is nil.

In addition to all those embedded PC features supported by hardware and BIOS, it is mandatory to offer a uniform API for easy access from the application software to the embedded PC feature set. With the API, application software developers can quite easily take advantage of the embedded PCs add-ons listed above.

Ideally, the API has been implemented as a generic board independent OS driver and is available for all common embedded operating systems. Whether it's triggering the watchdog, transferring data over I2C, reading hardware monitoring numbers or changing the backlight adjustment of the flat panel, it only requires a call to the API. Most importantly, such an API saves development time and guaranties software compatibility.

Figure 4. A uniform API implemented as a board independent OS driver guaranties software compatibility.

Ideally, the API driver itself will call the BIOS for low-level hardware routines. When doing so there will be no need for end users to update application software or an API driver when the embedded PC is going to be changed.