Hardware Interface Design Patterns Ahmet Selman Bozkır – Hacettepe Univ.

Subjects Serial Port Design Pattern High Speed Serial Port Design Pattern Hardware Device Design Pattern Synchronizer Design Pattern

Serial Port Design Pattern Embedded software has to interact with hardware devices of various types. In this article we will consider a design pattern for handling hardware interfaces for a serial port. HDLC, RS-232, RS-422

Serial Port Design Pattern Intent The Serial Port design pattern defines a generic interface with a serial port device. The main intention here is to completely encapsulate the interface with the serial port hardware device. All classes interfacing with the serial port will not be impacted by change in the hardware device.

Serial Port Design Pattern What we’ll get? To minimize dependency on hardware. Because; changing the interface due to: Cost End-of-life functionality Improvements

Serial Port Design Pattern Serial port design pattern encapsulates the register and interrupt handling specific to a device. Change in the device will just result in changes to just the classes involved in implementing this design pattern.

Serial Port Design Pattern Applicability This pattern is applicable to all serial devices that involve direct byte transfers to and from the device using program instructions. In such devices, serial transmission is implemented by the device interrupting the processor for data bytes. When data is received on the serial link, the device interrupts the processor to transfer data.

Serial Port Design Pattern Serial Port Manager: Manages all the Serial Ports on the board. Interrupt Service Routine: Implemented as a static method in Serial Port Manager. Serial Port: Handles the interface with a single serial port device. Transmit Queue: This queue contains messages awaiting transmission on the serial port. Receive Queue: Messages received on the serial link are stored in this queue. S erial Port is implemented with the SerialPort and SerialPortManager classes. The SerialPortManager maintains an array of SerialPort objects. Each SerialPort object manages the transmit and receive buffers. The SerialPortManager class also implements the interrupt service routine.

Serial Port Design Pattern Known Uses This pattern can be used to implement serial interfaces where data handling is handled in interrupt service routines. It is not suitable for direct memory access (DMA) based serial devices.

DMA based High Speed Serial Port Design Pattern

High Speed Serial Port Design Pattern Embedded processors now-a-days are connected with each other via high speed serial links. There links can range from 1 Mbps to 1000 Mbps. At these high link speeds, the byte by byte transfers described in the serial port design pattern prove inadequate. High speed transfers require devices that can directly transfer data to and from memory without interrupting the processor.

High Speed Serial Port Design Pattern This design pattern covers interfacing techniques with high speed serial communication devices. The main objective is to encapsulate the interface with the device and provide a hardware independent interface to the high speed serial port. High speed serial port design pattern encapsulates DMA configuration, register interfacing and interrupt handling specific to a device. Change in the device will just result in changes to just the classes involved in implementing this design pattern.

High Speed Serial Port Design Pattern Applicability This pattern is applicable to all serial devices that involve DMA (direct memory access) transfers to and from the device. In such devices serial transmission and reception are completely handled by the serial device. The device operates as a bus master and transfers data to and from the memory without main processor intervention.

High Speed Serial Port Design Pattern Structure Serial Port is implemented with the SerialPort and SerialPortManager classes. The SerialPortManager maintains an array of SerialPort objects. Each SerialPort object manages the transmit and receive buffers. The SerialPortManager class also implements the interrupt service routine. As mentioned earlier, the serial port is intelligent. The device needs to be programmed with the addresses of the transmit and receive message queues. Once these addresses have been programmed, the device automatically reads the buffer header to determine the current state of the buffer. For example, when the device finishes transmission of a buffer, it reads the buffer header for the next buffer to determine there is a new message ready for transmission. If a new message is found, the device initiates transmission immediately, without involving the processor.

High Speed Serial Port Design Pattern

So what? This pattern is used to design serial port interfaces with intelligent devices which are capable of performing DMA operations to manage buffers in the memory. These devices only interrupt the processor when complete messages have been received/transmitted.

Hardware Device Design Pattern

We have already looked at classes that provide a high level interface to the underlying hardware (e.g. Serial Port).Serial Port Here we will look at the design of classes corresponding to the individual devices. The main objective is to keep all register programming information at one place.

Hardware Device Design Pattern Aim: Very often the lowest level of code that interfaces with the hardware is difficult to understand and maintain. One of the main reasons for this is the idiosyncrasies of register level programming model of hardware devices. Very often devices require registers to be accessed in a certain sequence. Defining a class to represent the device can go a long way in simplifying the code by decoupling the low level code and register manipulation. Another motivation for this design pattern is skill sets. Often details about intricacies of register programming in devices are understood only by the persons familiar with the hardware design. Many times other low level code might be written by software engineers with just basic understanding of hardware. Also note that separating the device programming and logic simplifies porting of the code to a different hardware platform.

Hardware Device Design Pattern Structure: The structure of class in this design pattern largely depends upon the register programming model of the device being programmed. In most cases, this design pattern would be implemented as a single class representing the device. In case of complex devices, the device might be modeled as a main device class and other subclasses modeling different parts of the device.

Hardware Device Design Pattern Sample Implementation: Status Register (STAT): This read only register contains the following status bits: Bit 0: Transmit Buffer Has Empty Space Bit 1: Receive Buffer Has Data Bit 2: Transmit under run Bit 3: Receive overrun Action Register (ACT): Bits in this write only register correspond to the bits in the status register. A condition in the status register can be cleared by writing the corresponding bit as 1. Note that bit 0 automatically gets cleared when writes are performed to the transmit buffer. Bit 1 is cleared automatically when reads are performed from the receive buffer. Bit 2 and 3 however need to be cleared explicitly. Transmit Buffer (TXBUF): Write only buffer in which bytes meant for transmission should be written. Receive Buffer (RXBUF): Read only buffer in which received bytes are stored.

Hardware Device Design Pattern class Serial_Device { enum Register_Offsets { STAT_REG_OFFSET = 0, ACT_REG_OFFSET = 0, TXBUF_OFFSET = 1, RXBUF_OFFSET = 2 }; enum Status_Register_Bits { TX_EMPTY, RX_DATA, TX_UNDERRUN, RX_OVERRUN }; const long m_status_Register; const long m_action_Register; const long m_transmit_Register; const long m_receive_Register; public: Serial_Device(long baseAddress) : m_status_Register(baseAddress + STAT_REG_OFFSET), m_action_Register(baseAddress + ACT_REG_OFFSET), m_transmit_Register(baseAddress + TXBUF_OFFSET), m_receive_Register(baseAddress + RXBUF_OFFSET) { }

Hardware Device Design Pattern bool Transmitter_Has_Space() const { return ((io_read(m_status_Register) & TX_EMPTY) == TX_EMPTY); } // This method returns true if a receive interrupt is pending bool Receiver_Has_Data() const { return ((io_read(m_status_Register) & RX_DATA) == RX_DATA); } // Returns true if transmit error interrupt is active bool Transmitter_Has_Error() const { return ((io_read(m_status_Register) & TX_UNDERRUN) == TX_UNDERRUN); } // Returns true if receive error interrupt is active bool Receiver_Has_Error() const { return ((io_read(m_status_Register) & RX_OVERRUN) == RX_OVERRUN); } // Clear all the error conditions void Clear_Errors() const { io_write(m_action_Register, TX_UNDERRUN | TX_OVERRUN); }

Synchronizer Design Pattern

Aim: Many systems used in digital communication send data in synchronous back-to-back frames. When a receiver tunes to such a data stream, it has no knowledge of the frame boundaries. The Synchronizer Design Pattern is used to look at the raw incoming bit or byte stream and detect and align to the frame structure. The frame structure is detected by searching for a sync pattern in the frame. Once the synchronization is achieved, the Synchronizer confirms the presence of the sync pattern in every frame. If the sync pattern in missed a certain number of times, loss of sync is declared.

Synchronizer Design Pattern On many occasions there is need to maintain synchronization between two entities connected at opposite ends of a link. This design pattern provides mechanisms for: Achieving initial synchronization (sync) Once sync is achieved, confirming the presence of the sync framing Initiating loss of sync procedures Synchronizer state machine class is the key participant in this pattern. The state machine uses state classes to keep track of state.

Synchronizer Design Pattern It is clear from the figure below that the state machine is organized into two high-level states, synchronized and unsynchronized. These states act as the base class for the following sub-states:

Synchronizer Design Pattern The implementation is explained in terms of the following scenarios: Attaining Synchronization Loosing Synchronization

Synchronizer Design Pattern Attaining Synchronization 1.System starts up in "Searching For Sync" state. In this state, the incoming data stream is being analyzed bit by bit, looking for the occurrence of the sync pattern. 2.As a soon as a first sync pattern is detected, the system transitions to the "Confirming Sync Pattern" state. 3.Now the system checks if the sync pattern is repeating as expected. This check is made according to the specified periodicity. 4.If the sync pattern is repeating, the system transitions to the "In Sync" state. (If the sync pattern was not found, the system would have transitioned back to the "Searching For Sync" state) 5.At this point, the system is considered to be synchronized.

Loosing Synchronization 1.When the system is synchronized, it is in the "In Sync" state. In this state, the system is constantly monitoring the periodic occurrence of the sync pattern. 2.If an expected sync pattern is found to be missing, the system transitions to the "Confirming Sync Loss". The system is still in a synchronized state. The main purpose of the "Confirming Sync Loss" state is to check if the loss of sync was an isolated event or it represents complete loss of sync. 3.In the "Confirming Sync Loss" state, the system looks for the sync pattern at the expected time interval. If the sync pattern is seen again, the system transitions back to the "In Sync" state. 4.In this case, the sync pattern is not detected for a preconfigured number of times. 5.The system is now in sync loss state. The system is transitioned to the "Searching For Sync" state.

Synchronizer Design Pattern

So what? Use of this pattern has the following benefits: Provides a common framework for implementing synchronization logic Use of hierarchical state machine reduces the amount of code by reducing code duplication in various states. Use of a state machine forces the developer to handle all possible cases of synchronization events.

Resources Visio 2003 Thanks for listening me!