Universal Display Extension

1) INTRODUCTION

Gathering information about the internal states of a micro controller is essential for debugging during the development and may at least be quite nice to have in a finished project. But the available resources (e.g. controller pins, CPU load, memory consumption) may not be "wasted" for user IO or are simply too expensive to enhance, especially when thinking of a multi controller system with several ICs. Displaying the needed data shall also be done in a way to directly see what's going on inside the controllers, and everything shall be done in the easiest way possible. So the first things coming to mind are: LEDs + simple - can only show boolean information UART + HW UART available directly in HW on most controllers + low resource consumption - may need a PC - controller UART may be needed for something else in the project LCD + nice display + clear information - depending on display many pins needed - logic needed inside target controller to display data (ROM, RAM, CPU load) - expensive (at least in a multi controller project)

2)MODULARITY
The idea of the UDE is to outsource the needed periphery to an external board which can be connected with different communication interfaces and which can use different display units to show data. Furthermore the extension of the UDE with new interfaces and with new display blocks shall not be too difficult, especially to be able to port the system to a different controller. The UDE is therefore build of mainly 4 blocks: 1) HW dependent Communication interface 2) Command evaluation 3) Display rule 4) HW dependent display unit The picture “UDE architecture” shows the connection of these four blocks. The different communication interfaces use a standardized channel to provide the data to the command evaluation. The decoded command leads to the activation of a display rule which finally displays the data.

2.1)COMMUNICATION INTERFACE
All available HW or SW interfaces can be used. To do this the interface must be registered at the communication handler and will receive a handle. With this handle the received data can be provided to the communication handler. Doing so enables the system to use different interfaces at the same time in parallel, so the UDE supports also a multi controller project.

2.2) DATA OUTPUT
To output the received data different display units like LCD, LED, graphics LCD etc. can be utilized. The interface to the display are used by the display rule functions and are therefore independent of the actual kernel.

2.3) KERNEL
The kernel consists of two parts: the communication handler and the display element handler.The communication handler receives data from the communication interfaces with the respective handle. For this time the communication is locked to the communication interface.

2.4) DISPLAY ELEMENT
A display element is a rule to display data, this can be a simple LED or a bar graph on a graphics LCD. The display elements can be implemented completely free, so one could use a set of LEDs, a text LCD and a graphics LCD with one UDE system (provided that the used controller has enough pins). In object oriented speach a display element is the child of a generic element that implements the virtual display rule of the generic element. The generic element provides the class members like value, min, max, etc. The number of display elements used at once are of course limited by the RAM of the controller, but also by the size of the display. Additionally, the layout shall also be readable. Therefore a page mechanism is introduced so that several sets of display elements can be allocated to a page. The pages can be switched by using a UDE command.

2.5) TEXT BUFFER
The UDE of course supports text for outputs. But although the straighaway approach would be to send a complete text string and simply display has some restrictions that I wanted to overcome. Therefore the UDE contains a buffer for shorter text parts. These parts can be connected to a bigger text string, but can also be reused e.g. as a label. The display elements therefore get the index of such a text part as reference so they can either be used as a simple label, a longer string, a unit, etc.

2.6) UDE ARCHITECTURE
The attachment "UDE architecture" shall roughly shows the architecture of the UDE.

Data Flow: COMM -> UDE KERNEL (comm handler) -> UDE KERNEL (element handler) -> display

3) USING UDE

Using the UDE requires a few set of commands that need to be send by the master: 1) a description of the elements to use (i.e. the actual layout), only once 2) the text parts (if needed), only once 3) an initialization finished command, only once 4) the values to be displayed, event driven or cyclically As one can see the layout is stored on the master and not on the UDE controller, so the UDE can be disconnected from a running system and connected to another. The new master simply has to send its layout and the values to display.

3.1) ADD COMMUNICATION INTERFACE
Adding a communcation interface requires two things for UDE: a handle for the data transfer from the communication interface to the command handler and an function to transmit data from the comm handler via the communication interface. During the initialization of the communication interface the handle is dynamically calculated by the UDE kernel and the interface send function is added in a function pointer table. In this way the UDE kernel can answer to the requests from one of the communication interfaces as the handle is a unique identifier. To provide received data from the communication interface to the UDE kernel the communication must first be locked to the communication interface, the data must afterwards be provided to the UDE kernel along with the handle. The lock is automatically released if the command is completely received and evaluated.

3.2) ADD DISPLAY ELEMENT
The parameters of a display element are fixed: - position: x,y - control: id, type, dirty flag, flags - value: new, current, old, min, min - pointer to text vector, index of text part For each type a function has to be created, this is the actual description of how a value is displayed and is unique for each display element. There are two possibilities for these functions: asynchronous or synchronous. The async functions are called whenever the CPU has time, the sync. functions are called in a timer interrupt routine and shall therefore be as short as possible. To add a display element at least one function must be provided and added in a function pointer table, additionally the display element must be added in an enumeration that contains all elements. With this enumeration the display element functions are referenced.

4) UDE PORT
The following chapter describes the actual port with which the UDE was developed.

4.1) HARDWARE
The currently available port was created for a self build test board with

ATmega32 (internal osc. with 8 MHz)
access to TWI, SPI and UART
1 graphics LCD (KS0108 or compatible), data pins are distributed on two ports!
4 LEDs
4 buttons
1 BC547 as OC
1 user button (for HW specific settings, not accessable from outside)

The mainly used parts are the GLCD and the LEDs. The four buttons shall be used to extend the UDE not only as a display extension but also to have some buttons which can be read out by a master using the UDE interface. The BC547 shall be used to trigger an event on the master if a button state changes, but this is not yet included. The additional user button is used to modify and store settings for the communication interfaces (e.g. baudrate for UART and TWI address) in the EEPROM. This are not actually part of the UDE kernel but is associated to the port on which the UDE is running. If a new communication interface is added or if further settings shall be added the user interface part needs to be adapted.

4.2) PROJECT CONFIGURATION
The available UDE port was developed using AVR Studio 6, the folder structure is: - generic: the UDE kernel - elements: contains the display elements - cfg: the UDE configuration - hal: the processor specific HW drivers (TWI, SPI, GLCD, ...) - support: supporting functions (debounce, parameter handling, ...)

5) UDE COMMANDS
The attachment UDE command reference shows the currently supported commands.

6) TODO
The open points I can currently think of are:

add queues for communication interfaces to speed up the communication and prevent loss of data in case of multiple connected master controllers
add send functions for TWI and SPI
increase testing to read out data (e.g. buttons)