Peripheral component testing
with the
Microsoft .NET Microframework
Introduction
It is common ground that embedded systems are of little value without the various peripheral components that accompany them. Such peripherals can be sensors, add-in cards, external mass storage devices and many more. These peripheral devices are built around common interfaces and busses such as SPI, I2C and USART. In order for the developer to test such peripherals a device driver is required. Writing device drivers just for testing peripherals can be time consuming with uncertain results. In the following paragraphs you will be presented with a testing platform that is easy to use yet very powerful when testing new peripherals.
Main application
The solution is based around Microsoft’s .NET Microframework platform for small embedded devices. This platform is unique in the sense that allows development and manipulation of hardware components through a managed environment using higher level languages such as the C#. In this example four different components can be connected on every Microsoft .NET Microframework capable device. The buses/interfaces supported are SPI, I2C, GPIO and USART.
Picture 1: The main application running inside the emulator
The interface is control with stylus or finger touches. The user can press any of the available buttons to perform the indicated action. More specifically he/she is presented with a numeric keypad with the same layout as most common cellular phones. This keypad is used to enter the desired command in the Tx text box directly above. To buttons are provided for handling the peripheral communication. These are located on the top right corner and are indicated as Tx for “Send” command and Rx for “Receive” command. The resulting output of any command is stored in the Rx list box directly below the Tx and Rx buttons. The user can scroll with his/her finger or stylus through the list box to view past results. The clear button below the Rx list box is used when the user wishes to clear the contents of the list box. An option button is located on the left of the clear button and is used to configure the bus and peripherals for each selected case (SPI, I2C, GPIO and USART). Finally, the four buttons on the top left corner select (and hence make active) the desired bus where the peripheral resides on.
Picture 2: The application running on Device Solution's Tahoe II board
SPI
Using the SPI testing program the developer can configure and send/receive buffers to and from the connected device. Through the options menu one can select the proper configuration options such as the clock rate, the chip select port and the delays between reading and writing to the device.
Picture 3: The SPI “Options” panel
The communication is implemented by the Rx and Tx buttons on the main user interface. The user can write a command (e.g. initialization command) for the given SPI device in the Tx text box and press the Tx button. The command must be in HEX format. In case the user wishes to read some values from the SPI device he/she can press the Rx button. However since the SPI communication is Write/Read it is required that the appropriate command is written in the Tx text box before the Rx button is pressed. The peripheral’s answer will be printed inside the Rx list box.
I2C
The I2C communication is similar to the one described above for the SPI. The user can press the “Options” button to configure the I2C bus and start sending and receiving buffers.
Picture 4: The I2C “Options” panel
The configuration includes setting the I2C slave address on the bus, the clock rate and the number of bytes the Master will transmit or receive. The timeout is used in case the Slave does not respond which indicates an error either on the slave’s address or the Slave device.
GPIO
Every available GPIO pin on the device can be configured and used as Input, Output, Tristate or Interrupt pins. When in input mode the user can read (Rx button) the state of the GPIO pin (High or Low). Accordingly, when in Output mode the user can set the pin High by writing 1 on the Tx text box and pressing Tx or set the pin Low by writing 0 and pressing the Tx button. In Tristate mode the user can control whether the pin will act as input or output. To switch between input and output modes the user can write a white space (“ “) on the Tx text box and press the Tx button. Finally, in interrupt mode the user can read the state of the pin with the Rx button and when a level change is detected the user is informed by an entry in the Rx list box.
Picture 5: The GPIO "Options" panel
Through the “Options” menu the user can also enable the “Glitch filter” which will reduce any noise or sudden change in the levels of the GPIO pins, and set the initial state of the pin (Green: High, White: Low). Finally, the user can control whether the pin is connected on a pull-up or pull-down resistor and the edge that will trigger an interrupt in the interrupt mode.
USART
The USART port can be configured according to the RS232 standard. The user can select the port number, the parity, stop and data bits as shown in the following picture.
Picture 6: The serial interface "Options" panel
The communication is immediately available and the device connected to the USART port can start sending and receiving data. The reception is handled automatically and the incoming buffer is printed in the list box. The transmission is handled through the Tx button. The user should fill the Tx text box with the command he/she wishes to send (either AT commands or any ASCII character) and press the Tx button. (Note: The communication is implemented in ASCII mode). Since the communication is asynchronous and the incoming buffer is immediately printed in the Rx list box the Rx button has no effect.
Note
All the settings are automatically stored when the options window closes and are recovered when the device starts up.