Processor

Embedded systems have at least one processor. The processor is the primary execution environment for the application. The processor usually runs an operating system, and the operating system hosts the applications required to run on the platform.

In modern systems, an embedded SOC sometimes contains additional processing elements that are designed for a more specific function in support of the application. Consider a modern smartphone; the application processor is the processor that runs the software visible to the user, the user interface, or one of the many thousandths of applications such as web browser, or angry birds, mapping applications and the like. There is often another processor running the wireless stack; this is sometimes known as the baseband processor. On other platforms specific processors may process audio and camera images. The software running on these adjunct processors is often called firmware. The software execution environment for this firmware is usually specific to the target function; often they do not run an operating system. As the application power/performance efficiency and the ability to partition the application processor to run multiple execution environments (with robust quality of service) continues to improve, the trend will be to consolidate these workloads on the central processing unit.

The processor is clearly at the center of the platform. The processor in modern systems is typically 32 bit, which means that all the registers within the processor are a maximum of 32 bits wide. That includes data and address registers. Low performance embedded systems often use 16-bit microcontrollers, but the increased workload and connectivity required by such systems are driving a migration to 32-bit processors. Similarly, when high performance or large amounts of memory are required, 64-bit systems are gaining in the market.

The instruction set of the processor may be classified as either Complex Instructing Set Computing (CISC) or Reduced Instruction Set Computing (RISC). The Intel® architecture processors are all CISC-based Instruction Set Architecture (ISA), where the ARM, MIPS, and PowerPC are all considered to be RISC architecture. A CISC instruction set usually contains variable length instructions that allow for more compact encoding of the instruction. RISC, on the other hand, usually has fixed size instructions (for example, all instructions are 4 bytes long on PowerPC architecture). Some architecture, such as ARM, has introduced processors that support a subset of the original instruction set, which is recoded to improve the code density. At this point in time, from the programmer’s perspective, the distinction is less meaningful. A primary consideration is the performance achieved by the implementation.

Another aspect of the processor is whether it is scalar or superscalar. These are attributes of the microarchitecture of the processor. A superscalar-based processor supports the parallel execution of instructions by having multiple copies of key functional units within the CPU. For example, the Intel Atom™ microarchitecture contains two arithmetic logic units. The replication of key features allows the processor to sustain execution of more than one instruction per clock cycle depending on the applications and cache hit rate. The trend in embedded processors has been toward superscalar implementations, where historically many implementations were scalar.

The processor itself needs support hardware for it to perform any useful work. The key capabilities required to support the execution of a multitasking operating system on the processor are as follows:

The processor sits at the center of the platform and interacts with all the other devices on the platform. The locations of the devices are presented through the memory map.

System Memory Map

A key to understanding any embedded system starts with a thorough understanding of the memory map. The memory map is a list of physical addresses of all the resources on the platform, such as the DRAM memory, the interrupt controllers, and I/O devices. The system memory map is generated from the point of view of the processor. It’s important to note that there can be different points of view from different agents in the system; in particular, on some embedded devices the memory map is different when viewed from I/O devices or from devices that are attached on an I/O bus, although this is not the case on Intel platforms.

IA-32-based platforms have two distinct address spaces, memory space and input/output space. The memory space is actually the primary address space and it covers the DRAM and most I/O devices. It occupies the entire physical address space of the processor. For example, on a 32-bit system the memory space ranges from 0 to 4 GB, although not all addresses in this range map to a device or memory. Access to memory space is achieved by memory read/write instructions such as MOV. The I/O space is far smaller (only 64 kB) and can only be accessed via IN/OUT instructions. Since accesses to I/O devices through I/O space are relatively time consuming, most cases avoid use of the I/O space except for supporting legacy features (Intel platform architecture features that have been retained through the many generations of processors to ensure software compatibility). Many other embedded processor architectures such as ARM or PowerPC have only a memory address space.

When the processor generates a read or write, the address is decoded by the system memory address decoders and is eventually routed to the appropriate physical device to complete the transaction. This decision logic might match the address to that of the system DRAM controller, which then generates a transaction to the memory devices; the transaction could be routed to a hardware register in an Ethernet network controller on a PCI bus to indicate that a packet is ready for transmission.

The address map within the memory address space on Intel systems (and in fact in most systems) is split into two separate sub ranges. The first is the address range that when decoded accesses the DRAM, and the second is a range of addresses that are decoded to select I/O devices. The two address ranges are known as the Main Memory Address Range and the Memory Mapped I/O (MMIO) Range. A register in the SOC called TOLM indicates the top of local memory—you can assume that the DRAM is mapped from 1 MB to TOLM. The IA-32 memory map from zero to 1 MB is built from a mix of system memory and MMIO. This portion of the memory map was defined when 1 MB of memory was considered very large and has been retained for platform compatibility. The Memory Mapped I/O Range in which I/O devices can reside is further divided into subregions:

Figure 4.2 shows an overview of the system memory map for an Intel architecture platform.

FIGURE 4.2 Memory Map Representation for an Intel Platform.

The PCIe bus portion of the memory map above is not fixed. The system software (BIOS/Firmware and/or the operating system) writes to the base address register within the device at system initialization time. By contrast, in many embedded systems, the address map (within the SOC) is static. All devices are assigned an address at the time of SOC design. This does simplify the hardware design, but the system software must now be aware of the static addresses used to access each device. That usually entails building a specific target image for the target SOC. In this model it can be a little more difficult to build a single software image that supports a number of different SOC devices. Having said that, in many cases the embedded systems software is targeted and tuned to a specific device.

Interrupt Controller

The processor requires the ability to interact with its environment through a range of input and output devices. The devices usually require a prompt response from the processor in order to service a real world event. The devices need a mechanism to indicate their need for attention to the processor. Interrupts provide this mechanism and avoid the need for the processor to constantly poll the devices to see if they need attention. Given that we often have multiple sources of interrupt on any given platform, an interrupt controller is needed. The interrupt controller is a component that gathers all the hardware interrupt events from the SOC and platform and then presents the events to the processor. At its fundamental level, the interrupt controller routes events to the processor core for action. The interrupt controller facilitates the identification of the event that caused the interrupt so that the exception processing mechanism of the processor can transfer control to the appropriate handling function. Figure 4.3 shows the simplest possible form of interrupt controller. It consists of three registers that can be read from or written to from the processor. The registers are composed of bit fields with a single bit allocated for each interrupt source within each register. The first is an interrupt status register. This reflects the current pin status for the incoming interrupt line. It will be set when the interrupt request is active and clear (0) when there is no pending interrupt from the device. The second register is an interrupt mask register. Pending interrupts from the device can be prevented from getting to the processor core through the use of the interrupt mask. If the interrupt bit is set in the interrupt mask register, no interrupts from the source will reach the processor interrupt line. The interrupt status register shows the unmasked state of the interrupt line. Any of the active unmasked interrupts are capable of generating an interrupt to the processor (all signals are logically ORed together).

FIGURE 4.3 Basic Interrupt Controller Functions.

In this simplistic case, we have a single interrupt line to the processor. When the interrupt line becomes active, the processor saves a portion of the processor’s state and transfers control to the vector for external processor interrupts. This example is quite common in ARM architecture devices. The interrupt handler reads the interrupt status register and reads the active status bits in a defined priority order. A common implementation is to inspect the interrupt status bits from least significant bit to most significant bit, implying that the interrupts routed to the least significant bits are of higher priority in servicing than the other bits. The priority algorithm is under software control in this instance, and you may restructure the order in which interrupt status bits are checked.

The interrupt pending registers often take the form of a latched register. When an unmasked interrupt becomes active, the bit associated with the interrupt in the interrupt pending register becomes set (one). Then even if the interrupt signal is removed, the interrupt pending bit continues to be set. When the interrupt handler comes to service the interrupt, the handler must write a logic one to the bit it wishes to acknowledge (that is, indicate that the interrupt has been serviced). Bits with this behavior within a device register are known as Write One to Clear.

The processing of searching for the highest priority in the system by scanning bits adds to the time required to identify that highest priority interrupt to service. In embedded systems we are typically trying to reduce the overhead in identifying which interrupt we should service. To that end, a hardware block is introduced that takes the unmasked active interrupt sources and generates a number derived from a hardware-based priority scheme. The number reflects the highest-priority interrupt pending. The objective is to use this hardware generated number to quickly execute the appropriate interrupt handler for the interrupting device(s). This interrupt number can be obtained by one of two mechanisms. In the first mechanism, the interrupt software handler reads the register, the register value is used as an index into a software-based vector table containing function pointers, and the interrupt handler looks up the table and calls the function for the incoming vector. This scheme is frequently used in ARM devices where the architecture defines a single interrupt request line into the processor. The second mechanism used is one in which the CPU hardware itself generates an interrupt acknowledge cycle that automatically retrieves the interrupt number when the interrupt has been raised to the processor. This interrupt number is then translated to the interrupt vector that the processor will transfer control to. The interrupt handler is called in both cases; there is a level of software interaction in the first case that is avoided in the second implementation. The process of reading the interrupt vector number from the interrupt controller whether it was done by software or hardware may form part of an implicit interrupt acknowledgment sequence to the interrupt controller. This implicit acknowledgment indicates to the controller that the processor has consumed that particular interrupt; the interrupt controller then re-evaluates the highest priority interrupt and updates the register. In other controller implementations the device source of the interrupt must be first cleared and the highest priority interrupt will automatically update. Figure 4.4 shows the two schemes discussed.

FIGURE 4.4 Interrupt Acknowledgment and Priority Schemes.

The interrupt signal designated in Interrupt A and B in Figure 4.4 may be an interrupt generated by an internal peripheral or an external general-purpose input/output (GPIO) that has interrupt generation capability. The interrupt lines typically may operate in one of the following modes:

As you may imagine, the system (and device drivers) must handle each interrupt type differently. A level-triggered interrupt remains active and pending to the processor until the actual signal level is changed to the inactive state. The device driver handling the level-triggered interrupt may have to perform specific operations to ensure the input signal is brought to the inactive state. Otherwise, the device would constantly generate interrupts to the processor. Edge-triggered interrupts, on the other hand, effectively self-clear the indication to the interrupt controller. In many cases devices have a number of internal events that cause the device to generate an interrupt. For edge-triggered interrupts, the interrupt handler must ensure it processes all interrupt causes from the device associated with the interrupt. Level-based interrupts, on the other hand, automatically re-interrupt the processor if the driver does not clear all of the internal device interrupt sources. Level-triggered interrupts can also be shared using wired-or configuration where any device attached to the line can bring the line interrupt request line active.

Timers

Hardware-based timers are critical to all computer systems. A hardware-based timer generally consists of a hardware counter that counts down from a provisioned value and triggers an event such as an interrupt to the CPU when the counter reaches zero. The timer usually automatically restarts counting from the provisioned value (free-run). At least one timer is required for the operating system, particularly if it is a preemptive operating system (which most are). The operating system timer is often called the OS tick. The interrupt handler for the OS tick triggers the operating system scheduler to evaluate whether the current process should be suspended in favor of executing another ready task.

You should be aware of a number of attributes of a timer when programming it:

Figure 4.11 shows the logical configuration for a generic timer block.

FIGURE 4.11 Logical Timer Configuration.

Hardware timers are often read in a tight busy loop by software delay routines. Especially if the delay is short, for longer delays it is best to call the appropriate operating system service to allow the operating system schedule some useful work while the thread is delayed.

DRAM Controllers

Dynamic random access memory is a form of volatile storage. The bit value at a memory location is stored in a very small capacitor on the device. A capacitor is much smaller than a logic gate, and therefore the densities are greater than memory technologies using logic such as caches for the processor or SRAM block on an SOC. The ratio is significant. For example, a level two cache of 1 MB is reasonably large for a cache on an embedded device, whereas a device such as the Intel Atom Processor E6xx Series supports up to 2 GB of DRAM.

Although the densities are considerably higher, the price per bit is lower. However, there is a system trade-off that takes place. The DRAM read time is usually far slower than memory that is made from logic gates, such as the CPU cache or SRAM devices (both internal or external).

The read latency is a key performance attribute of memory. Although many strategies are used in processor and cache design to reduce the effect of read latency to memory, in many cases it will directly impact the performance of the system. After all, eventually the processor will have to wait for the result of the read from memory before it can continue to make progress. In order to read a DRAM bit, a logic device must check the value stored on the capacitor for the bit. This is done using a sense amplifier. The sense amplifier takes a little time to figure out whether the bit has a charge or not.

Another key performance attribute is the overall bandwidth or throughput supported by the DRAM devices. Whereas the read latencies of DRAM technology have not been reduced at nearly the same pace as the increase in density or overall throughput performance, the throughput performance has increased dramatically over time. The key improvements in throughput performance of DRAM are accomplished by pipelining as many read and write requests to the memory devices as possible. The DRAM device duplicates many of the logic resources in the device to have many concurrent lookups (sensing) occurring. Figure 4.12 shows the increased performance through multiple parallel requests to the DRAM. DDR memories have separate requests and response lines; this allows the requester interface to enqueue multiple requests while waiting for the response to review requests.

FIGURE 4.12 Increased Performance through Pipelining.

It is important that memory interfaces are standardized to allow many different manufacturers to develop compatible devices for the industry. At the time of writing, DDR2 SDRAM is the predominant DRAM type used in embedded platforms. DDR3 is becoming the DRAM technology used on mainstream compute platforms. The adoption of memory technologies in embedded platforms usually lags behind the adoption of the technology in mainstream platforms. This is often due to a price premium for the memory when it is first introduced into the market.

The DRAM interface as well as many physical attributes are standardized by JEDEC. This organization is the custodian of the DDR1, 2, and 3 SDRAM standards. These devices are known as synchronous DRAMs because the data are available synchronously with a clock line. DDR stands for double data rate and indicates that data are provided/consumed on both the rising and falling edge of the clock. As we mentioned above, the throughput of the memory technology can be increased by increasing the number of parallel requests to the memory controller. Both the depth of pipelining and the clock speed have increased from DDR1 to DDR2, and DDR3 has resulted in a significant increase in throughput throughout the generations of DRAM (see Table 4.4).

Table 4.4. DRAM Performance

The memory controller on the Intel Atom Processor E6xx Series supports DDR2-667 and DDR2-800 megatransfers per second (MT/s).

Unlike mainstream computers, embedded platforms usually solder the memory directly down on the printed circuit board (PCB). This is often due to the additional cost associated with a module and connector, or mechanical/physical concerns with respect to having the memory not soldered to the platform. Clearly, if the memory is directly soldered to the platform, there is limited scope for upgrading the memory after the product has been shipped. The ability to expand the memory in an embedded system post-shipment is not usually required. When the memory is directly soldered down, the boot loader or BIOS software is typically preconfigured to initialize the exact DRAM that has been placed on the board. However, when modules are used such as the dual in-line modules (DIMM) prevalent on mainstream computers, the BIOS or boot loader has to establish the attributes of the DIMM plugged in. This is achieved by a Serial Presence Detect (SPD) present on the DIMM modules. The SPD is an EPROM that is accessed via a serial interface SPI explained later. The EPROM contains information about the DIMM size and memory timing required. The BIOS takes this information and configures the memory controller appropriately.

The memory cells within the DRAM device are organized in the device in a matrix of rows by columns, shown in Figure 4.13. A memory transaction is split into to two phases; the first is called the Row Address Strobe (RAS). In this phase an entire row of address bits is selected from the matrix; all the bits in the row are sent to the bit sense amplifiers and then into a row buffer (also called a Page). The process of reading a row of data from the capacitors is actually destructive, and the row needs to be written back to the capacitors at some point. Before entering the second phase for the transaction, the memory controller must wait for the RAS to CAS Latency, called RAS CAS Delay (tRCD). The second phase of the transaction is called the Column Address Strobe (CAS). In this phase the word being read is selected from the previous row selected. The CAS Latency (tCL) is often a figure quoted; it is the time from the presentation of the column address strobe to getting the data back to the memory controller. It is measured in memory clocks, not nanoseconds. Once the memory transaction has been completed, a command called Precharge needs to be issued unless the next request falls in the same row. Precharge closes the memory row that was being used. RAS Precharge Time (tRP) is the time taken between the Precharge command and the next active command that can be issued. That is, the next memory transaction generally won’t start until the time has been completed (more on that later). As you can see, the overall latency performance of the memory device consists of three separate latencies. If we can continue to make use of the row that has been loaded into the sense amplifier logic, then we can get subsequent data with much lower latency. To this end the memory devices and controller support a burst memory command. This is where the subsequent data are provided with much lower latency. The typical burst size supported is 4. Given that modern processors have a cache subsystem, the burst memory command is a very useful transaction to exchange data between the cache and memory.

FIGURE 4.13 DDR Overview.

The normal burst mode support expects the initial address to be aligned to the size of the burst; for example, if the DRAM were a 32-bit device with a burst size of 4, the initial address for a burst would have to be 0xXXXX,XX00. The initial data returned would be for the first double word, then 0xXXXX,XX04, 0xXXXX,XX08, and lastly 0xXXXX,XX0C. If, however, the processor were waiting for the last double word in the burst (0xXXXX,XX0C), then using a burst command would decrease the performance of the processor waiting for the read result. To mitigate this, many memory controllers support a feature called Critical Word First. This CRW feature provides the data that the processor are actually waiting for first and then returns the other data elements of the burst. In the example above, the device would return the data for 0xXXXX,XX0C, 0xXXXX,XX00, 0xXXXX,XX04, and finally 0xXXXX,XX08. This would reduce the overall latency experienced by the processor but would still make use of data locality to load the cache line while the DRAM row was still active.

Another optimization to the DRAM subsystem is to have a policy on how long to keep the row buffer (page) active. As we mentioned, subsequent access to an active or open page takes less time than that required to load a new row. Given that programs often have high degrees of spatial and temporal locality, it is often best for the controller to keep a page open until a new row is accessed. This does, however, delay the time to open the new row when a new row is needed. Keeping a row active until a request is made outside that row is known as a page open policy. If the controller proactively closes the page once the transaction is complete, it is known as having a page close policy. The page sizes are relatively large; on Embedded Atom SOCs the memory controller supports devices with 1-kB, 2-kB, and 4-kB pages. Since there can be a considerable advantage to reading from an open page, the DRAM devices are partitioned into independent banks, each with its own page (row buffer) support. The SOC supports 4- and 8-bank DRAM devices. With 4–8 banks, memory controllers can thus keep multiple pages open, improving chances of burst transfers from different address streams.

In an embedded system you often have more flexibility and control over how memory is allocated and portioned in the system. A reasonable performance advantage can be seen by allocating different usage patterns to different banks. For example, a gain of approximately 5% can in some cases be achieved in a simple network router where the memory allocated to the network packets, operating system code space, and applications were all allocated from a separate banks.

The memory devices come in varying bit densities and data bus widths (x4, x8, x16, x32). The total memory required can be built up using any number of options. For example, one could use a 256-Mb device that has a 32-bit interface or two 128-Mb devices each with a 16-bit interface connected to the memory bus. The DRAM controller needs to be set up with the appropriate configuration to operate correctly. The rationale for determining the appropriate configuration usually comes down to the size of the devices on the platform and the amount of space available, as fewer higher density devices are required. The decision also has an economic dimension; higher-density memories are usually more expensive than lower-density ones.

No discussion of DRAM is complete without mentioning the refresh cycle. The DRAM cells are made up of tiny capacitors, and because a capacitor’s charge can leak away over time, this could ultimately result in in a 1 bit turning into a 0 bit. Clearly, this is not acceptable. Each row in each device must go through a refresh cycle with sufficient frequency to guarantee that the cell does not discharge. Generally, each DRAM device must be entirely refreshed within 64 ms. If a device has 8192 ROWs, then the refresh cycle must occur every 7.8 μs. The refresh cycle consists of a CAS before RAS cycle where the ROW address to memory array determines the row to be refreshed. Some DDR devices have their own refresh counter, which updates ROW address during refresh cycle; the DRAM controller just triggers the refresh cycle and does not have to keep track of refresh ROW addresses. Some platforms support a DDRx’s self-refresh capability; in this case the DRAM device performs the refresh cycle while the device is in low power mode with most of its signals tristated. This is usually used to allow the memory controller to be powered down when the system is in a sleep state, thus reducing the power required by the system in this state. The ability of a capacitor to retain charge is temperature dependent; if you develop a platform that supports an extended temperature range, the refresh rate may need to be increased to ensure data retention in memory cells. It is important to refresh with the required interval. Most of your testing will probably be done at normal room temperature, where the chance of a bit fading is relatively low. However, when your platform is deployed and experiences real-world temperatures, you really don’t want to be trying to debug the random system crashes you might experience. I’ve been there, and it’s no fun at all.

Even if the DRAM is being refreshed with the required interval, there is a small probability that a capacitor may spontaneously change its value, or an error in the reading of a bit may occur. These errors are known as soft errors and are thought to be the result of cosmic radiation, where a neutron strikes a portion of the logic or memory cell. To mitigate the effects, designers add a number of extra redundant bits to the devices. These extra bits record the parity of the other bits, or an error correcting code covering the data bits. Parity protection requires just a single bit (for 8 bits of data) and allows the controller to detect a single bit error in the memory. It cannot correct the bit error, as there is insufficient information. When a parity error is detected, the memory controller will typically generate an exception to the processor, as the value read from memory is known to be bad. Using additional protection bits, single bit errors in the data can be corrected, while double bit errors can be detected. The most popular protection used today is known as Error Correcting Code (ECC). The scheme uses 2 bits per 8 bits covered. When the memory controller detects a single bit error, it has enough redundant information to correct the error; it corrects the value on the fly and sends the corrected value to the processor. The error may still exist in the memory, so the controller may automatically write back the correct value into the memory location, or in some systems an interrupt is raised and the software is responsible for reading the address and writing back the same value (while interrupts are disabled). A double bit error cannot be corrected and will raise an exception to the processor. When any new data are written to memory, the controller calculates the new ECC value and writes it along with the data. During the platform startup, there is no guarantee that the error bits in the device are consistent with the data in the device. The boot code or in some cases the memory controller hardware has to write all memory locations once to bring corresponding ECC bits to the correct state before any DDR location is read. Since ECC has the ability to correct a single bit error, it is prudent to have a background activity that reads all memory locations over a period of time and self-correct memory location if a single bit soft error is encountered. Such a process is known as scrubbing. Since fixing single bit errors obviously prevents a double bit error from occurring, scrubbing drastically reduces memory data loss due to soft errors.

SRAM Controllers

Static random access memory is a volatile storage technology. The technology used in the creation of an SRAM cell is the same as that required for regular SOC logic; as a result, blocks of SRAM memory can be added to SOCs (as opposed to DRAM, which uses a completely different technology and is not found directly on the SOC die). The speed of SRAM is usually much faster than DRAM technologies, and SRAM often responds to a request within a couple of CPU clock cycles. When the SRAM block is placed on die, it is located at a particular position in the address map. The system software and device drivers can allocate portions of the SRAM for their use. Note that it is unusual for the operating system to manage the dynamic allocation/de-allocation from such memory; it is usually left up to the board support package to provide such features. SRAM memory is commonly allocated for a special data structure that is very frequently accessed by the processor, or perhaps a temporal streaming data element from an I/O device. In general, these SRAM blocks are not cache-coherent with the main memory system; care must be taken using these areas and they should be mapped to a noncached address space. On some platforms, portions of the cache infrastructure can be repurposed as an SRAM, the cache allocation/lookup is disabled, and the SRAM cells in the cache block are presented as a memory region. This is known as cache as RAM; some also refer to this very close low-latency RAM (with respect to the core) as tightly coupled memory.

The cells in a CPU cache are often made from high-speed SRAM cells. There is naturally a trade-off; the density of SRAM is far lower than DRAM, so on-die memories are at most in the megabyte range, whereas DRAMs is often in gigabytes.

Given that the read/write access time of SRAM memory is far faster than DRAM, we don’t have to employ sophisticated techniques to pipeline requests through the controller. SRAM controllers typically either handle one transaction at time, or perhaps pipeline just a small number of outstanding transactions with a simple split transaction bus. There is no performance advantage from accessing addressing in a line as is the case for DRAM.

You should understand the memory sub-word write behavior of the system can be lower than you might expect. As the density of the memory cells reduces, they can fall victim to errors (as in the case of DRAM), so in many cases the SRAM cells have additional redundancy to provide ECC error bits. When the software performs a sub-word write (such as a single byte), the SRAM controller must first perform a word read, merge in the new byte, and then write back the update word into the SRAM with the correct ECC bits covering the entire word. In earlier SRAM designs without ECC, the SRAM often provided a byte write capability with no additional performance cost.

NOR Flash

NOR flash memory devices are organized as a number of banks. Each bank contains a number of sectors. These sectors can be individually erased. You can typically continue to read from one bank while programming or erasing another. When a device powers on, it comes up in read mode. In fact, when the device is in read mode, the device can be accessed in a random access fashion: you can read any part of the device by simply performing a read cycle. In order to perform operations on the device, the software must write specific commands to specific addresses and data patterns into command registers on the device. Before you can program data into a flash part, you must first erase it. You can perform either a sector erase or full chip erase. In most use cases you will perform sector erases. When you erase a sector, it sets all bits in the sector to one. Programming of the flash can be performed on a byte/word basis.

An example code sequence to erase a flash sector and program a word is shown below. This is the most basic operation, and there are many optimizations in devices to improve write performance. This code is written for a WORD device (16-bit data bus).

//Sector Erase

// ww(address,value) : Write a Word

// See discussion on volatile in GPIO section below

unsigned short sector_address

ww(sector_address + 0x555), 0x00AA); // write unlock cycle 1

ww(sector_address + 0x2AA), 0x0055); // write unlock cycle 2

ww(sector_address + 0x555), 0x0080); // write setup command

ww(sector_address + 0x555), 0x00AA); // write additional unlock cycle 1

ww(sector_address + 0x2AA), 0x0055); // write additional unlock cycle 2

ww(sector_address) ,0x0030); // write sector erase command ∗/

.. you should now poll to ensure the command completed succesfully.

// Word Program into flash device at program_address

ww(sector_address+ 0x555), 0x00AA); // write unlock cycle 1

ww(sector_address+ 0x2AA), 0x0055); // write unlock cycle 2

ww(sector_address+ 0x555), 0x00A0); // write program setup command

ww(program_address), data); // write data to be programmed

// Poll for program completion

When programming a byte/word in a block, you can program the bytes in the block in any order. If you need to program only one byte in the block, that’s all you have to write to.

A parallel NOR interface typically consists of the following signals:

The cycles used to access the device are consistent with many devices using a simplified address and data bus.

In order to discover the configuration of a flash device such as size, type, and performance, many devices support a Common Flash Interface. A flash memory industry standard specification [JEDEC 137-A and JESD68.01] is designed to allow a system to interrogate the flash.

Many flash devices designate a boot sector for the device. This is typically write-protected in a more robust manner than the rest of the device. Usually it requires a separate pin on the flash device to be set to a particular level to allow programming the device. The boot sectors usually contain code that is required to boot the platform (the first code fetched by the processor). The boot sector usually contains enough code to continue the boot sequence and find the location of the remaining code to boot from, and importantly it usually contains recovery code to allow you to reprogram the flash remainder of the flash device.

The initial program of flash devices that are soldered on to a platform is usually carried out through the JTAG chain. This is presented through a connector that can be attached to a JTAG programmer or ICE (see Chapter 17, “Platform Debug”). The device has access to the flash device directly and can program it by emulating the behavior of a host processor in read/writing the device.

On Intel platforms, the initial instructions fetched (BIOS or boot loader) are usually stored on a NOR flash device. The flash devices can provide either a serial or parallel interface. In most cases, a serial interface is used on Intel platforms, although many others use a parallel interface.

There are some reliability differences between NOR and NAND flash devices. NOR devices are more reliable and less susceptible to bit loss. As a result, NOR flash devices are often considered the safest memory type for storing the initial program sequence for the processor (although NAND devices do have techniques to mitigate this by duplicating copies of the boot block and adding additional ECC bits to the sectors).

With random access read/write capabilities, the NOR flash more naturally supports a mode of operation called eXecute in Place (XIP). This is where a program can run directly from the flash (without first copying the data from flash to DDR memory).

Flash devices are characterized by the number of erase cycles a device supports before it starts to fail. Current devices support up to 100,000 erase cycles per sector. If flash memory is being used for a file system or to store logs of frequently changed data, then the sectors are frequently erased and reprogrammed. Software drivers must ensure that all the activity is not focused on a small number of sectors. This strategy is known as wear leveling, and all flash file systems support the principle.

The Linux kernel uses the Memory Technology Device (MTD) interface. MTD provides a generic interface for flash devices. This layer manages the individual devices at the lowest level. There are a number of flash file systems that are also provided (with differing characteristics) built up on top of the MTD layer. The most commonly used at present is the Journaling Flash File System 2 (JFFS2).

We mentioned that erasing a block sets all bits to 1. Through programming you can convert any bit with a value of 1 to zero. You can even do this without erasing. You can never convert a 0 bit to a 1 without an erase cycle. Many flash file systems make use of this attribute to help to maintaining metadata associated with a file system.

In addition to programmable storage, many devices (NOR and NAND) offer One Time Protect/Programmable (OTP) storage. This is used to store permanent information such as a serial number IMEI/ESN information, secure boot code, or SIM-Lock. The OTP bits are programmed at the time of manufacturing and cannot be updated.

NAND Flash

In contrast to the NOR flash, NAND flash does not provide a direct random access address interface. The devices work in a page/block mode. To read the device the driver must first request a page before the data from the page can be accessed. This is not unlike other secondary storage mechanisms such as disk drives, and as such it is relatively straightforward to build a file system on top of NAND devices. Erasing and programming occur in block modes. Unlike the NOR device, the programming of a block must occur in serial fashion (incremental address programmed in order). Each block has a number of pages. The page size is typically 2 kB. The time taken to load the page into the page register is relatively slow in comparison to the subsequent reads from the page register. To improve performance, many divides contain a number of page registers.

NAND (and to a lesser extent NOR) devices may contain bad pages. These bad pages must be managed by the controller (hardware or software) that provides the interface to the device. To improve the yield of NAND devices, the devices may be released with marked bad blocks. NAND devices may start life with bad blocks and further degrade over the lifetime of the device. The bad blocks found during manufacture are typically marked in spare bits within each block. You must not erase or program pages that are marked as being bad. Also, the increased density of the NAND devices brings with it some compromises, such as a possibility of a spontaneous bit change. To ensure correct overall operation, a number of additional bits are set aside for error correct control (ECC).

A native NAND physical interface typically consists of the following signals:

A NAND read operation consists of loading a page from the flash array and then reading the data from the page register. Figure 4.14 shows the representation of the page register and blocks.

FIGURE 4.14 NAND Device Representation.

The following steps are required to read from the device:

There are device optimizations to improve the performance, but this is the general process of accessing the device. As you can see, it really is block oriented.

In order to reduce the need for both NAND and NOR devices in a system, some NAND devices provide a special boot block. The boot block is designed to be as reliable as a traditional NOR device (using additional ECC or reduced density or an actual NOR partition). This boot page is automatically placed in the read page buffer, so that a processor can start random accesses to this page when the system first boots.

Hard Disk Drives and Solid State Drives

Hard disks have been a traditional low-cost form of mass storage in platforms for many years. The hard disk drive is a device where data are stored on circular magnetically coated platters. This form of storage has the least cost per bit of all storage types considered. There are mechanical and environmental considerations that you must consider for these forms of mass storage device, and the environmental conditions associated with embedded devices often precludes their use. Because the media is revolving on a spindle, they are sometimes known as spindle-based drives. As the cost of NAND devices has come down, a new type of storage known as the solid state drive (SSD) has become cost-effective in many embedded cases. The SSD is a drive that is made up of NAND devices and a sophisticated NAND controller. The NAND controller presents a traditional hard disk drive interface to the host. The controller takes care of all the low-level flash management including wear leveling.

The latest drive interface is Serial Advanced Technology Attachment (SATA). It is defined by the Serial ATA International Organization (www.serialata.org). It is an interface used to connect host controller adaptors to mass storage devices. It is the natural evolution of the previous Parallel ATA standard. In most platforms the host controller follows a standard register level interface known as AHCI. The AHCI standard is defined by Intel (http://www.intel.com/technology/serialata/ahci.htm).

Most controllers can be configured in legacy Parallel ATA mode or the more advanced native interface. The native high-performance mode should be used for SATA drives. This native interface is a hardware mechanism that allows software to communicate with Serial ATA devices. AHCI is a PCI class device that acts as a data movement engine between system memory and SATA devices. The host bus adaptor (controller) supports programmed I/O mode, DMA modes (which are akin to the original legacy modes on PATA devices), and a mode known as native command queuing for SATA devices. The vast majority of operating systems provide some level of support for SATA drives, especially since the controller supports the most basic of operating modes (PIO). The source for the SATA drivers can be found in Linux/drivers/ata/∗ahci∗.c.

Table 4.5 summarizes some of the relative attributes for each mass storage device.

Table 4.5. Summary of NAND and NOR Flash and SSD

Peripheral Component Interconnect (PCI)

The predominant high-performance external interface standard is PCI. PCI has been on Intel platforms for many years and has evolved from a 32-bit parallel bus to a high-speed lower-pin-count serial bus (with many lanes to scale performance). Although the PCI standard has significantly increased I/O performance with every PCI generation, the logical view of the PCI system has been kept very consistent throughout the evolution of the standard. The approach to discover and access the device has remained the same, allowing full software compatibility over PCI generations.

PCI Express (PCIe) is the third generation of the PCI standard. It is a higher-performance I/O bus used to connect peripheral devices to compute systems. PCIe is the primary peripherals interconnect used on Intel architecture systems, but it has become popular on many platforms. The PCIe standard is developed by the PCI-SIG (http://www.pcisig.com).

The PCIe standard provides the capability to identify devices attached to a PCIe bus at runtime. Once these devices are discovered, the system software can allocate resources to these devices dynamically. This process is called bus enumeration. The enumeration process allocates a range of addresses in the system address map to access the device, as well as one or more interrupt vectors. To facilitate the enumeration process, there is a special PCIe bus space known as configuration space. The PCIe configuration space size is a total of 256 MB. The bus supports device discovery and initial configuration by responding to special configuration space transactions on the bus. The configuration space is partitioned into PCIe busses (up to 256), devices per bus (up to 32), and functions within a device (up to 8 per device). This three tuple address is known as the Bus Device Function (BDF) address. The BDF address for a device depends on where it is connected to on the PCIe fabric. The function is dedicated by the design of the device. For example, if a Ethernet card has two separate Ethernet interfaces, it will mostly likely present two separate functions. The process of enumeration is a runtime search through the PCI configuration space looking for devices. Figure 4.15 shows the physical topology of a PCIe system.

FIGURE 4.15 PCIe Physical Hierarchy.

The head of the PCIe hierarchy is known as the root complex. The root complex takes processor read/write transactions and routes them to the appropriate transaction type in the PCIe fabric. The root fabric takes upstream transactions from PCIe devices and routes them to the host memory. It also routes interrupts from the devices to the appropriate processor. Devices can also be integrated into the root complex; in this case the devices are presented in exactly the same way as devices that are attached via external physical PCIe links. This provides a consistent approach to discovering internal and external devices.

Each device has a configuration space header. Each device configuration space can be up to 256 bytes. A device can optionally have an extended capabilities register at offsets in range 256 to 4095. A total of 65,536 devices are theoretically supported on PCI. Processors cannot natively generate a PCI configuration cycle; the PCI configuration space transactions can be generated by either of the following mechanisms (on Intel architecture systems):

The enhanced MMIO mode of configuration can directly access all registers of any device on the PCI bus. The MMIO address bits are built up from the following bit fields:

Each device must have a base configuration header. Figure 4.16 shows a base configuration header. It allows the system software to identify the device type and to assign memory and interrupts to the device.

FIGURE 4.16 PCI Configuration Header.

The vendor ID identifies the manufacturer of the function. The IDs are assigned by the PCI-SIG. The vendor ID assigned to Intel devices is, somewhat humorously, 8086h. The device ID is assigned by the manufacturer and is used to indicate the device type. This device ID is usually used by operating systems to find the appropriate device driver to load and associate with the device. The device revision can be used to adapt the driver for specific versions of the device. The Class code can for some generic devices be used to provide a generic device driver support for a device. In this case the device ID is ignored and the operating system assigns the device driver based on class code. An example where a class code for a generic device is used is a simple VGA adaptor.

PCI devices are composed of two different register spaces, the configuration space and device registers. The configuration space is primarily used as part of the enumeration and allocating the driver to the device. The configuration space contains a number of base address registers. These base address registers are programmable decoders that are used to decode access to the actual device registers. There are six 32-bit or three 64-bit base address registers. The base address register contains some read-only low-order bits set to zero. When you write all ones to the base address register and read back the value, the enumeration software establishes the size of memory the enumeration software must allocate. For example, if the software writes 0xFFFFFFFF to a base address register but reads back 0xFFFF000, then the device is requesting a space of 4 kB. The enumeration software allocates all the memory for the devices “requested” by the enumeration process and writes to all the device base address registers. The lower byte of the base address register has some special meaning; it indicates whether the base address is to allocate memory or I/O space, although the vast majority of devices now limit the registers to memory-mapped only. It also includes an prefetchability attribute—it indicates if the memory space for the device is prefetchable. This is an important classification for I/O devices. Registers on a device must not be prefetchable of a speculative read by the processor; this has a side effect on the hardware. Consider a processor speculative read of a hardware FIFO. In this case the value is read, but it may not be used by the software: the data are lost. This bit has no special significance for Intel hardware since the Intel CPU does not do speculative prefetch to MMIO space, which is normally mapped into the uncacheable region.

When the base address register is written, all memory transactions generated to that bus address range are claimed by the device. The addresses are assigned to be in noncacheable memory-mapped I/O space by the bus enumeration software at startup. The registers allocated via the bar address registers are specific to the device and not standardized in any way by the PCI-SIG.

The addresses used on the bus are known as bus addresses. On Intel platforms there is a one-to-one correspondence between the host physical address and the address used on the bus. There is no translation of the outbound address in the system (unless virtualization is being used in the system).

In Linux the lspci command details the devices for all PCI devices in the system. It shows the device types, the memory and interrupts allocated, and the device driver attached to the device.

>lspci –v (sample of results)

00:03.0 Multimedia video controller:

 Intel Corporation Device 8182 (rev 01)

 Subsystem: Intel Corporation Device 8186

 Flags:bus master, fast devsel, latency 0, IRQ 11

Memory at d0300000

  (32-bit, non-prefetchable) [size=512K]

  I/O ports at f000 [size=8]

Memory at b0000000

  (32-bit, non-prefetchable) [size=256M]

Memory at d0380000

   (32-bit, non-prefetchable) [size=256K]

02:0a.2 Serial controller:

 Intel Corporation Device 8812

 (prog-if 02 [16550])

 Flags:bus master, fast devsel, latency 0, IRQ 19

 I/O ports at e040 [size=8]

Memory at d0149000

 (32-bit, non-prefetchable) [size=16]

Kernel driver in use: serial

02:00.1 Ethernet controller:

 Intel Corporation Device 8802

 Flags:bus master, fast devsel, latency 0, IRQ 25

Memory at d0158000

 (32-bit, non-prefetchable) [size=512]

Kernel driver in use: ioh_gbe

The interrupts vectors are also assigned during the enumeration process. Each PCIe device provides configuration registers to support a feature known as MSI/MSI-X. There are two key register types: the first is an address register and the second is a data register. The address is a special address in the system, and it is the targeted interrupt controller for which the interrupt is being sent to. Each processor hardware thread has an individual target address, so MSI/MSI-X interrupts can be steered to a specific hardware processor thread (mechanism for any processor to handle the thread are also defined). The data register is the vector for the interrupt that is assigned to the device. The device can request multiple interrupt vectors, and the enumeration process attempts to satisfy all device requests with individual interrupt vectors. In cases where there is oversubscription of interrupt vectors versus device requirements, (i.e. the system cannot allocate all the vectors requested by the device), some vectors must be shared among different functions within a device. Having many separate vectors for a device can improve the performance of an interrupt handling routing, as it does not have to read device status registers to find out the cause of the interrupt.

Not all operating systems support MSI-X; fallback legacy interrupt support mechanisms provide emulated wired interrupts.

Programming Interface

The programming interface for USB host controllers has been standardized. These standards define the register maps for the controller and the descriptor formats for the data when they are transmitted and received on the bus. Three standards are in existence:

Most devices support both 1.1 and 2.0 devices by instantiating both a UHCI and EHCI controller. This is often done for expedience; the two controllers can coexist and a multiplexing function can be placed between the devices and each controller.

Depending on the source of the IP in the embedded SOC device, the register map and descriptor format may not follow these standards.

Figure 4.19 shows the components of a software stack on top of the EHCI controller.

FIGURE 4.19 Software Stack on ECHI Controller.

The EHCI host controller manages the transmission and reception of frames on the bus. The Enhanced USB host controller contains two sets of software accessible hardware registers, memory-mapped registers, and optional PCI configuration registers. The PCI configuration registers are required if the host controller is implemented as a PCI device. The PCI registers contain the PCI header and some additional configuration registers required to allocate the appropriate system resources during enumeration. The PCI registers are not used by the USB driver after enumeration.

The memory-mapped registers are divided into two sections:

Figure 4.20 shows the register structure for a PCI ECHI controller.

FIGURE 4.20 EHCI Register Classification.

Source: http://www.intel.com/technology/usb/download/ehci-r10.pdf

The EHCI provides support for two categories of transfer types: asynchronous and periodic. Periodic transfer types include both isochronous and interrupt. Asynchronous transfer types include control and bulk. Figure 4.20 illustrates that the EHCI schedule interface provides separate schedules for each category of transfer type. The periodic schedule is based on a time-oriented frame list that represents a sliding window of time of host controller work items. All isochronous and interrupt transfers are serviced via the periodic schedule. The asynchronous schedule is a simple circular list of schedule work items that provides a round-robin service opportunity for all asynchronous transfers.

The ECHI controller generates interrupts to the processor based on a number of events. One such interrupt is generated at a point in the processing of the asynchronous lists. This is configured when the list is generated by the driver to provide enough advanced notice for the driver to add more work to the list. Another interrupt is generated when the period frame list rolls over; this again is to ensure that the driver supplies data for subsequent frames.

As we mentioned, there are two key lists managed by the driver and consumed by the host controller: the periodic frame list (for isochronous and interrupt traffic) and the asynchronous list (control and bulk transfers). We’ll discuss the asynchronous list first. The list is only processed when the host controller reaches the end of the periodic list, the periodic list is disabled, or the periodic list is empty. That is, it has the lowest priority of all traffic and will only be sent on the bus when there is no other work to do. The asynchronous list is pointed to by a control register: AsyncListAddress. The list is a circular list of queue heads. The controller cycles through each element in the list (in a round-robin fashion), processing each queue head as it goes. One queue head is used to manage the data stream for one endpoint. The queue head consists of a queue element transfer descriptor. The queue head structure contains static endpoint characteristics and capabilities. It also contains a working area from where individual bus transactions for an endpoint are executed. Each queue element transfer descriptor represents one or more bus transactions, which is defined in the context of this specification as a transfer. A descriptor has an array of buffer pointers, which is used to reference the data buffer for a transfer. Figure 4.21 shows how the elements described above are linked together.

FIGURE 4.21 Async List Address, Head Queues, and Payload Description.

Source: EHCI Intel Spec.

The USB UHCI device driver provides services to the individual class drivers, which make use of the bus drive to transmit and receive data.

Linux Driver

That describes the basic mechanism of sending data on the bus, but it is agnostic as to the payload being sent or received. The USB class driver for the device actually formats the payload that sent on the endpoint. For example, a USB pen drive uses the USB mass storage class device driver. Reference source code for the USB mass storage driver can be found at Linux/drivers/usb/storage/.

Inter-Integrated Circuit Bus

One of the most prevalent of these buses is known as the Inter-Integrated Circuit bus, or I²C bus. It was invented by Philips (now NXP) in the 1980s. The specification can be found at http://www.nxp.com/documents/user_manual/UM10204.pdf.

The bus standard allows for multiple masters on the bus (however, in many use cases it runs as a single master with multiple slaves attached). It is a simple two-wire bus consisting of a serial clock line (SCL) and a serial data line (SDA). Figure 4.22 shows the interconnection between devices on an I²C bus.

FIGURE 4.22 Single Master I²C Bus.

Each wire (SDA and SCL) is bidirectional. They are driven by open collector gates on each of the devices. Open collector gates allow any device to bring a pin to zero. You may have noticed the pull-up resistors in the diagram; these are typical when open collector outputs are used, and they bring the default bus value to Vdd—a logic one. The protocol is quite simple and is often driven by software directly controlling two general-purpose I/O pins. Each device has a 7-bit address so that transactions can be directed to a particular slave device from the master. The addresses are hard-coded by pull-up/pull-down pins on the device such as A[0-2] in Figure 4.22. Although the bus supports up to 112 devices, most devices export a low number of address bits such as 3 bits. The 3 bits that are selected with the board straps form the lower-order address bits of the device. The higher-order address bits (for example, the remaining 4) are assigned to the device type and built in to the device. The result is that you can have up to eight devices of the same type on a bus, as other devices will contain different high-order address bits.

The bus is controlled by the master device. The master device generates the serial clock, controls bus access, and controls the stop and start conditions. The clock speeds are relatively low, from 10 kHz to 100 kHz and 400 kHz to 2 MHz. The bus follows the following state transitions:

The format of the data after the address transfer (first byte after a start bus transfer) is dictated by the actual device you connect, for example, a serial EEPROM (http://ww1.microchip.com/downloads/en/devicedoc/21189f.pdf). To perform a byte write to the device, the two bytes following in the device address specify an address to write within the device, and the following byte is the byte we wish to write to the address within the device. Read in the device can take two forms; the first is a current address read capability. The device has an address counter that starts at zero. Each read of the device provides a byte back to the master and the counter is incremented. This is the easiest way to read out the EEPROM contents. There is also an address specific read, but this is accessed by setting the counter using a device write sequence, then reading back the current address value. This is just an example; the actual interactions with the device are defined by the vendor.

System Management Bus (SMBus)

The System Management Bus is a two-wire bus used for host-to-device and device-to-device communications (http://smbus.org/specs/). It was originally invented by Intel, but its principles are similar to that defined by the I²C bus. It is ubiquitous on modern PC motherboards and is used to control the power supply on/off, temperature sensors, fan control, read the configuration from the memory DIMMs, and the like. Intel devices such as the Intel Atom Processor E6xx Series integrate the SMBus host controller, which acts as a master and communicates to slave devices on the motherboard. SMBus specification 2.0 permits a bus speed for an SMBus of between 10 Khz and 100 KHz. The SMBus specification defines a number of commands for use with devices:

The commands described above are all quite similar to the semantics used in an I²C bus, but SMBus has also defined a mechanism for a slave to send a notification to the host (not unlike an I²C slave device becoming the master for a particular transaction). The SMB notification is often used by devices to alert the host processor of a particular condition. For example, an SMBus motherboard temperature sensor could be programmed to generate an alert if the temperature were to go above a critical threshold. In this case, the system software would program the device to send the alert. The system software would not be required to poll the device to check the temperature. However, if the temperature crossed the threshold, the system would be notified. Many devices have a separate alert pin that is asserted to raise a non-maskable or system management interrupt. The system software can generate a broadcast call to read all slave devices that have current alerts active (the address used is the “alert response address”). There are many manufacturers of SMBus devices, such as the Nation Semiconductor LM75. The Linux lm-sensors project provides software that can be used to manage the hardware sensors on an Intel-based motherboard. A comparison between SMBus and I²C can be found in Application note 476, www.maxim-ic.com (direct link does not work).

Serial Peripheral Interface (SPI)

Serial Peripheral Interface (SPI) is a four-wire bus. It consists of a serial clock, master output/slave input, master input/slave output, and a device select pin. The speed of the bus range is much higher than that found in I²C or SMBus; speeds up to 80 MHz are not uncommon. There are variants that provide multiple bits for the transfer (up to 4). These additional data bits dramatically increase the performance. There is no standard specification defined for SPI—it is a de facto standard. The SPI bus is used to connect to serial flash parts that provide the initial boot code for Intel platforms, as shown in Figure 4.23.

FIGURE 4.23 SPI Interface to Flash Parts.

The effective throughput of a 80-MHz 4-pin serial peripheral interface to a NOR flash device is approximately 40 megabytes per second. This is faster than many parallel interfaces to older NOR flash devices. Intel SOC and chipset integrate SPI host controller, which offloads the processor from driving the SPI protocol on SPI bus.

Audio Buses

Audio buses differ from the low-pin-count buses we have described so far. They typically run continuously, providing audio samples between devices. The most common use case is to connect a codec (analog device with d/a and a/d converters) to a digital SOC where the samples are processed or generated. The Intel-based SOC devices typically use a High Def Audio bus (http://www.intel.com/design/chipsets/hdaudio.htm).

A typical configuration can carry 16 channels per stream, 32-bit audio samples at a sample rate of 192 kHz. The HD audio controller provides DMA engines that manage the transmission and reception of audio samples across the bus with low processor overhead.

Inter IC Sound (I²S)

The I²S bus is another bus defined by Philips (http://www.nxp.com/acrobat_download2/various/I2SBUS.pdf). The bus was designed to transfer audio samples between integrated circuits. The bus is a three-wire bus: a continuously running clock, a data line, and a word select line to allow for the selection of two channels (left/right for stereo), which are time-multiplexed on the data pins.

Universal Asynchronous Receiver/Transmitter

A universal asynchronous receiver/transmitter (UART) is a device that transmits and receives data between a peer UART across a serial line. There are a number of EIA standards, RS-232, RS-422, and RS-485, that define the data format, signals, and electrical voltages on the wires and connector format. The COM port (if it still has one) on PC computer platforms is an RS-232 port. The simplest form of serial communication requires just three wires: a transmit wire, a receive wire, and an electrical ground wire (by which the signals are referenced). To connect two systems together via the serial port, you need to cross over the Tx and Rx wires so the Tx of one port is connected to the Rx of the other port and vice versa. This is known as a null modem cable. There are other wires that can be defined on the serial port connector. There are hardware flow control signals and indications associated with analog modems that are no longer that prevalent. The most standard form is the simple three-wire Tx/Rx and Ground.

A serial port is one of the most basic items you can find on an embedded system. It is quite simple to program and can provide a simple command console and boot indication on when to bring up the system. If the device SOC has a UART, you should definitely make it accessible on your system. In many cases the UART signals are not electrically compatible with the RS-232 standard, and you must use a level shifter to be compatible with an actual RS-232 standard. A Maxim MAX232 is a common level shifter part used to convert the logic levels coming from the UART port to the RS-232 levels.

The asynchronous nature means that there is no separate clock signal to indicate the bit transitions on the Tx and Rx wires. The line encoding used is sufficient for the bits being transmitted to be detected. The transmission consists of a start bit, 5 to 8 data bits, an optional parity bit, and then 1, 1.5, or 2 stop bits. The most ubiquitously used format is No-Parity, 8 data bits, and 1 stop bit. This is usually written as N81.

There are many different speeds supported on UARTS: 300, 600, 1200, 1800, 2400, 4800, 7200, 9600, 14,400, 19,200, 38,400, 57,600, and 115,200 baud. The most common speed used by default on systems is 9600. If the UART is used for heavy data transfer such as downloading images to a platform, a faster baud rate such as 115,200 or higher is used.

When transferring data across the serial port, some form of flow control is often needed. Flow control allows the receiver of the data to indicate to the transmitter than it cannot process additional data sent to it. There are two forms of flow control: hardware and software. The hardware flow control uses additional signal wires (Request to Send and Clear to Send for five-wire RS-232) between the transmitter and receiver to delay the transmission of data to the receiver. More frequently used is software flow control, where the receiver sends a special data value to the transmitter to request that the transmitter pause transmission, and another code to resume the transmission. The characters used are XON/XOFF; XOFF corresponds to the Ctrl-S character and XON corresponds to the Ctrl-Q character. These key sequences can still be used on Linux terminals to pause and resume the terminal.

In some cases, the serial port is used to transfer binary data. In these cases the binary data must be altered and sent in a special format, as it cannot be transmitted directly (imagine XON/XOFF was one of the binary values to be transmitted). A common binary to serial (escaping) format is that provided by a protocol known as kermit (http://www.columbia.edu/Kermit/). Kermit is a terminal emulation program that provides a binary file transfer mechanism. However, the protocol is used more widely than the program itself, especially in embedded systems.

The UART device is a relatively simple device. It provides control registers to set for format (such as N81), clock dividers to set the baud rate, simple transmit and receive FIFOs, and interrupt triggers based on the levels of occupancy within these FIFOs. The model used (register set, behavior, and so on) by the vast majority of UART devices in systems was based on a device known as the 16550A UART, which was originally made by National Semiconductor. There are some limited variations used; one common variation is the size/depth of the FIFO. When the part was originally developed, baud rates supported were relatively low and the size of the corresponding FIFO was quite small; in later revisions or instantiations the FIFO grew to a nominal size of 16 bytes.

The Linux serial driver can be used to start a login shell on a serial port. The serial driver is located in kernel/drivers/serial/8250.c. It supports the 8250 (the 16550A predecessor) and 16550A UART devices. The driver does its best to probe the hardware to identify which variant of UART is there. The serial devices are presented to the system via the /dev/ttyS handle, for example, /dev/ttyS0 for serial port 0 (usually COM port 0 on PCs), /dev/ttyS1 for serial port one, and so on. The Linux boot arguments can specify that a login console be brought up on a specific serial port as follows.

Kernel /vmlinux-2.6.34 ro root=LABEL=/ console=ttyS0,38400

The kernel arguments are specified by the bootloader configuration files. Bootloaders such as Grub, readboot, and uboot all support passing arguments to the kernel.

As the baud rates have increased, there can be some limited performance concerns due to the interaction model with the de facto standard 16550A UART model. In this model the FIFOs must be read by and written to by software byte by byte. In order to reduce the software overheads in handling UARTS, some UART controllers provide a DMA mechanism to transfer the serial characters received from the FIFO to contiguous memory buffers provided by the device driver (similar structure for Transmit). In these cases the interrupt indication is usually based on filling the supplied buffer or a timeout after the last character has been received. This significantly reduces the software overheads associated with transferring data over the serial port. It should be noted that the speeds are still very low in comparison to the relative performance of the processor, and large FIFOs are more common than DMA capable UARTS.