Third year dissertation project

Developing an LCD interface for an embedded system

Author: Alex Dignam Supervisor: Kirill Bogdanov

Module: COM3600 This report is submitted in partial fullment of the requirement for the degree of Bachelor of Science with Honours in Computer Science by Alexander Thomas Dignam

May 2, 2012

Signed Declaration
All sentences or passages quoted in this report from other peoples work have been specically acknowledged by clear cross-referencing to author, work and page(s). Any illustrations which are not the work of the author of this report have been used with the explicit permission of the originator and are specically acknowledged. I understand that failure to do this amounts to plagiarism and will be considered grounds for failure in this project and the degree examination as a whole. Name: Alex Dignam Signature:

Date: 02/05/2012

Abstract Tribsonics Ltd is a small UK based company that specialises in the use of ultrasonic technologies. Markets range from Forumla1 racing and medical technology companies to railway transport systems and Large engine manufacturers. They are currently the only company world wide using these technologies to design and manufacture their own electronics. This document details the development of an LCD user interface on an embedded system. The project is ultimately for the benet of Tribsonics Ltd and is bound by their end user requirements. The overarching purpose of this project is to create a piece of software capable of receiving data from a sensor and converting it into something comprehensible to the end user, as well as giving the option to manipulate this output.

Contents
1 Introduction 1.1 The Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 LCD Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Literature Survey 2.1 Overview . . . . . . . . . . . . . . . . . 2.2 Hardware . . . . . . . . . . . . . . . . 2.3 Programming Languages . . . . . . . . 2.3.1 Assembly . . . . . . . . . . . . 2.3.2 Embedded C . . . . . . . . . . 2.3.3 Conclusion . . . . . . . . . . . . 2.4 Integrated Development Environments 2.4.1 mikroC PRO for PIC32 . . . . 2.4.2 MPLAB 8.80 . . . . . . . . . . 2.4.3 MPLAB X . . . . . . . . . . . . 2.4.4 Conclusion . . . . . . . . . . . . 2.5 Programming the Hardware . . . . . . 2.5.1 MPLAB C32 Compiler . . . . . 2.5.2 Microchip graphic libraries . . . 2.5.3 Interrupts . . . . . . . . . . . . 2.5.4 Conguration Bits . . . . . . . 2.5.5 Dynamic Memory Management 2.5.6 Testing . . . . . . . . . . . . . . 3 Requirements and Analysis 3.1 Mandatory . . . . . . . . . . 3.2 Desirable . . . . . . . . . . . 3.3 Analysis . . . . . . . . . . . 3.3.1 Graph . . . . . . . . 3.3.2 Manipulation control 3.3.3 Cosmetics . . . . . . 3.3.4 Integration . . . . . 3.4 Testing . . . . . . . . . . . . 1 1 1 2 2 2 4 4 5 5 6 6 6 6 6 6 7 7 11 14 15 15 17 17 19 19 19 20 20 20 20

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . ii

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3.4.1 3.4.2 3.4.3

Unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Render testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20 21 21 22 22 22 23 24 24 25 25 26 29 29 29 29 30 31 31 32 32 33 33 34 34 35 35 35 36 37 37 38 38 38

4 Design and Implementation 4.1 Hardware . . . . . . . . . . . 4.1.1 Touchscreen . . . . . . 4.2 UI structure . . . . . . . . . . 4.2.1 Options hidden . . . . 4.2.2 Options shown . . . . 4.3 GOL (Graphic Object Layer) 4.3.1 Widgets . . . . . . . . 4.3.2 Custom Widgets . . . 5 Testing 5.1 Unit testing . . . . . . . 5.2 Render testing . . . . . . 5.3 User testing . . . . . . . 5.3.1 Starting/stopping 5.4 Graph features . . . . . 5.4.1 Graph scrolling . 5.4.2 Full screen mode 5.5 Options . . . . . . . . . 5.5.1 Gain . . . . . . . 5.5.2 Pulse width . . . 5.5.3 Range . . . . . . 5.5.4 Delay . . . . . . 6 Results 6.1 Requirements testing 6.1.1 Completed . . 6.1.2 Incomplete . . 6.2 Issues . . . . . . . . 6.3 Future work . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . the . . . . . . . . . . . . . . . .

. . . . . . . . . . . . ascan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7 Conclusion 7.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii

Chapter 1 Introduction
1.1 The Task

Tribsonics Ltd is in need of a way to visualise the data output from their ultrasonic sensors. The client already has a desktop solution in place at the company premises, but is need of something more compact. This project has been assigned to three students and a general project layout has been provisionally agreed.

1.1.1

LCD Interface

The client has designed and manufactured an embedded systems board with an on-board LCD screen. The plan is to eventually link this board with the sensors in order to output the data as a waveform on the screen and give the user options to manipulate it. It has been agreed that everyone assigned to the project will attempt this task individually so that client will receive a consistent functional product that he can then deploy in his workplace. Below is a diagram showing the layout and ow of data through the described system:

Chapter 2 Literature Survey

2.1 Overview

The overarching topic of this project is embedded systems development, embedded systems can be described as the following: A combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a dedicated function. In some cases, embedded systems are part of a larger system or product, as in the case of an antilock braking system in a car. [3] Embedded systems are everywhere in real life; all programmable house hold electrical devices contain embedded systems that are responsible for monitoring and controlling the devices functions. For example; when you program your dish washer to execute a rinse cycle you are essentially telling an embedded system to execute a pre-programmed routine that controls the respective hardware in a way that constitutes a rinse cycle. One of the dening features of an embedded system is that it is dedicated to a specic set of tasks in a specic context, whereas a desktop PC ts a general set of tasks that can be used in several dierent contexts. As such embedded systems often run in a both limited and compact environment; i.e. if it carries out a single task then only so much processing power/memory are required relative to the task. As a result of having a single purpose, most embedded systems lack an operating system and are therefore coded at a low level of programming, such as Assembly. This project however, is a little dierent to a dishwasher controller, yet the principle remains the same; the task is specic and the resources are limited.

2.2

Hardware

Here is a list of the hardware that will be included in the project, and an overview of their relevant technical specications: PIC32MX795F512L USB 2 Starter Kit Development Board [1] 2

A board containing a PIC32 chip that will be used to develop the project. The following features are notable from the context of this project: MCU Core 80MHz, 1.56 D/MHz, 32-bit MIPS M4K Core A 32 bit chip whose primary oscillator has a maximum clock-speed of 80mhz. Due to the fact that graphical rendering is concerned, in combination with other processes, it is foreseeable that the chip will be running at this clock-speed in order to maximise performance. This however, will have implications on the amount of power the chip will consume along with its operational lifespan. This needs to be investigated further. MCU System Features 512K Flash (plus 12K boot Flash) The total amount of ash memory available on the chip. This is where the program will be stored along with other resources, such as graphics. It is imperative that this limited amount of memory is used as eciently as possible. This will impact on the size of the code and the quality of any graphics included. 128K RAM (can execute from RAM) The total amount of Random Access Memory available, allows for storage and high speed access of high importance data and also allows for dynamic memory allocation within a program assigned heap. [6] Chapter 5.5 HEAP USAGE Power Management Modes RUN, IDLE, and SLEEP modes - multiple switchable clock modes for each power mode, enables optimum power settings Multiple power modes allow for power eciency, program specic implementation of these modes needs to be taken into account during the course of this project. Debug Features iFlow Trace: Non-intrusive Hardware Instruction Trace port (5 Wires) 8 hardware breakpoints (6 Instruction and 2 Data)

 2 wire programming and debugging interface On board debugging features will be essential to producing a high quality solution, hardware implementations of both tracing and breakpoints will aid this endeavour greatly. Combined programming and debugging features mean that the program can easily be tested independently of the provided debugger, meaning that program behaviour can be observed properly if necessary. Other MCU Features Serial Communication Modules allow exible UART/SPI/I2C conguration Various methods of serial communication are available, meaning that communication with the clients peripheral hardware should be relatively simple. Multimedia Expansion Board [2] An extension to the primary chip that features an on-board LCD touch screen amongst other things: 1. 3.2 inch (8.1 cm) QVGA touch screen display with backlight 2. Five user-controlled LEDs 3. Four-way joystick. 4. Fire button. 5. Solomon Systech Graphics Controller. Not all media board features have been listed, as they are currently of no use to the project.

2.3

Programming Languages

There are currently two popular languages with which to program an embedded system; Assembly and Embedded C. It has been agreed that this project will almost exclusively feature embedded C with the possibility of implementing some sections in assembly if necessary. However, evaluation of each option has taken place:

2.3.1

Assembly

Assembly language is the lowest form of programming above pure machine code. It can be dened as the following: A human-writable form of a processors native instruction set. In its typical form, each line of assembly code represents a single CPU instruction. The humanreadable representation of each opcode is called a mnemonic. [4] 4

At this level of programming there are no ambiguities; each instruction written in assembly maps to a respective CPU instruction with instructions being unique to certain CPUs and CPU architectures. This is a very popular way of programming a relatively small scale embedded system, as the programmer can take full advantage of the architecture of the device he/she is working with, and create code that is highly optimized for the specic task/hardware. There are unfortunately downsides to this type of programming; assembly code is in no way compact and when implemented directly on a relatively large scale; the code base increases exponentially, resulting in tens of thousands of lines of code that are very likely to be unintelligible, even to the programmer who wrote it the day before. Also with a larger code base comes a larger chance that errors will be made during coding and subsequently made harder to solve during the process of debugging. These problems however can be oset somewhat by using what is called a macro assembler, where sets of assembly instructions are referred to by single instructions called macros. The assembler that is available to use in this project, is in fact a macro assembler, however, even though the problems mentioned earlier are lessened, they are still present, and constitute the main factors inuencing the choice not to use pure Assembly in this project.

2.3.2

Embedded C

The C programming language, or ANSI C is a step up from Assembly language in terms of abstraction; it allows sucient low level control coupled with the ability to write ecient and compact code. Embedded C is simply a set of extensions for regular ANSI C with some limitations thrown in. Examples of extensions being low level chip control as well as interrupt management. In the case of an embedded system; space is limited and therefore the programmer may not be able to use all of the libraries he/she may like. There are often specialised/optimized standard libraries set out for such systems, but this is not always the case, and consequently the programmer has to end up rewriting standard libraries. However, in the case of the PIC32 a set of standard libraries and extensions like the ones mentioned previously have been included under the MPLAB C32 compiler, as well as more chip specic functions and data types, implemented under a library called plib or peripheral libraries [5] Currently this language is the language of choice for this project, as it is both heavily supported, well documented and has a good balance between high level abstraction and low level control. It also helps that all of the example code is in C.

2.3.3

Conclusion

To conclude the correct language to use in this instance, given the evidence; would be embedded C, due to its large amount of support, documentation and robustness.

2.4

Integrated Development Environments

The embedded world oers few options as far as IDEs are concerned. There are three options that have presented themselves so far:

2.4.1

mikroC PRO for PIC32

An IDE by a company named MikroElektronika: It sports many convenience tools, such as; a library manager, a conguration bit manager, in circuit debugging, full syntax highlighting, checking and auto-completion. Automatic code generation for interrupts and much more. It also comes bundled with its own C compiler and all in all looks to be an extremely good IDE. The only drawbacks being that it is not conrmed to be compatible with the microchip libraries and that it costs around $300 to purchase. [8]

2.4.2

MPLAB 8.80

A free IDE from Microchip themselves: It also contains convenience tools similar to the mikroC PRO IDE, however, it has fewer of them and is certainly lacking in terms of syntax checking and auto-completion. Not as impressive as mikroC PRO, but its free, all of the example code compiles and runs correctly and subsequently has shown to be 100% compatible with microchip libraries. [9]

2.4.3

MPLAB X

An updated version of MPLAB based on netbeans, it is however, in the beta testing stage and therefore cannot be completely trusted to work correctly. However, on paper it is an improvement on MPLAB 8.80 with a larger number of convenience tools, along with proper syntax highlighting and auto-completion. [10]

2.4.4

Conclusion

To conclude, the best option for the moment is MPLAB 8.80 as it is an old but tried and tested IDE with sucient features to complete the project.

2.5

Programming the Hardware

Earlier in this chapter, it was concluded that the appropriate programming language and IDE to use would be Embedded C and MPLAB 8.80 respectively. Programming the hardware is achieved through the use of standard C libraries and certain conguration tools in the IDE itself. Ultimately everything is tied into the standards marked out by the MPLAB C32 compiler. as it is responsible for compiling the code down to PIC32 specic assembly code.

2.5.1

MPLAB C32 Compiler

The MPLAB C32 Compiler contains a C99 standard ANSI C compiler based on the one contained in the popular gcc package (GNU Compiler Collection). The compiler itself is bundled with a set of pre-compiled standard C libraries with similar functionality to that of desktop C libraries, with the exception being that they have been optimized for the target platform: The available libraries have been optimized for: speed, size, integer arithmetic only and MIPS16 mode. [7] Chapter 2.1 Standard C Libraries with Math Functions - Introduction

2.5.2

Microchip graphic libraries

The Microchip graphic libraries will be the basis for the project, as they are free, supported by microchip and provide a high level interface for the display device. The library is split into three major parts that form three layers of abstraction between the programmers application and the hardware:

Display Driver Primitive Layer This section is the lowest level of the graphics API and details functions that cover generic display properties, such as brightness, clipping settings and functions to check whether or not the device is busy. The main feature being the most basic of rendering functions; PutPixel - that places a pixel of the current colour type at the given x and y coordinates. [11] 10.1 Display Device Driver Level Primitives Graphic Primitive Layer This layer is simply a level above the previous and uses PutPixel to provide a set of useful primitive functions, such as drawing lines and basic 2D geometric shapes, i.e. circles and rectangles. More advanced features include shapes with colour gradients (a shape lled with two colours with a transition between the two, using a pre-set pattern) text drawing functions and the ability to include bitmaps stored in external or on-board ash memory. [11] 9 Graphics Primitive Layer Graphic Object Layer (GOL) This layer provides the highest level of abstraction and details widgets that make up the screen space. Created using primitive layer functions, widgets in this context are essentially interactive ui elements that can be programmed to execute functions upon a specic event. Starting from the top, widgets are managed by the drawing system GOL. GOL keeps a global linked list of widgets that it uses to draw and redraw each component in order. At the same time it checks to see if any widget has been aected by internal/user driven input, these changes manifest themselves in the form of GOL messages: typedef struct { BYTE type; BYTE uiEvent; SHORT param1; SHORT param2; } GOL\_MSG; [11] 8.5.3 GOL MSG Structure These are generic messages that can come from multiple sources i.e. touch screen, hardware buttons, internal timers etc. They simply contain the type of message (this tells you where it came from, e.g. a touch screen message), the hardware/software event that triggered it; e.g. triggered via the touch screen being pressed, and any parameters that naturally come with the message, such as x and y coordinates for touch screen presses. For every widget each message is processed via the widgets TranslateMsg function, this 8

tells GOL whether or not the widget is aected by the message. If the message aects the widget, the widgets default message handler is called (MsgDefault), this takes the translated message and applies it to the widget making changes respective of the message received. It is also worth noting that the programmers own handlers are also called and are featured in the GOLMsgCallback function. This function acts in the same way as the default message handler - applying the message to the widget and making respective changes. The nature of this system lends itself to an object orientated approach as every widget confers to a common structure, this abstraction has been carried out already and is known as the object header (OBJ HEADER): typedef struct { WORD ID; void * pNxtObj; GOL_OBJ\_TYPE type; WORD state; SHORT left; SHORT top; SHORT right; SHORT bottom; GOL_SCHEME * pGolScheme; DRAW_FUNC DrawObj; FREE_FUNC FreeObj; MSG_FUNC MsgObj; MSG_DEFAULT_FUNC MsgDefaultObj; } OBJ_HEADER; [11] - 8.2.2 OBJ HEADER Structure ID - the ID of the current object, used to retrieve a reference to the object. pNextObj - the pointer to the next object in the linked list of objects. type - type of the widget, an easy way to identify what type of widget the object is. state - current state of the object represented by bit patterns inside of an unsigned 16 bit integer (WORD) left, right, top, bottom - widget dimensions. pGolScheme - a pointer to a scheme, these contain colour and font settings. DrawObj - a pointer to a function that draws the widget. FreeObj - a pointer to a function that frees the widget. MsgObj - a pointer to a function that translates object messages. 9

 MsgDefaultObj - a pointer to a function that acts as the default handler for translated messages. This is where inheritance like behaviour comes into C; every widget has its own unique struct, however, they all share a common member; OBJ HEADER, this allows every widget to be interpreted as an OBJ HEADER struct through the use of Cs casting system. This essentially yields the same result as interpreting a child class as its parent in an object orientated language like Java. As of the date printed on this document there are a total of 18 widgets that come as standard with the microchip graphic libraries, all of which are covered in more depth in the Graphics Library Help document. [12] But to give an example; like most interface libraries there is a button widget that reacts graphically to being pressed and also executes a press handler written by the programmer. typedef struct { OBJ_HEADER hdr; SHORT radius; SHORT textWidth; SHORT textHeight; XCHAR * pText; void * pBitmap; } BUTTON; [11] 8.2.8.10 BUTTON Structure It is worth noting that widgets are enabled in a modular fashion i.e. you dont have to compile/include the widgets you wont be using. This is primarily to save memory and reduce compile times. Custom Widgets Custom widgets can be created and used in the same way as any other widget. The full details are covered in the document How to Create Widgets in Microchip Graphics Library [12] but to summarize, a widget is composed of the following: A struct that contains the object header and any other relevant data. A create function that instantiates a new copy of your widget and passes it all of data required to satisfy the object header and any other additional elds A draw function that GOL uses to draw the widget. A free function that GOL uses to remove your widget from memory (this is optional and only applies if you have assigned memory outside of your struct, as GOL frees the struct for you). 10

 A translate message function that GOL uses to nd out whether or not an event eects your widget. A default message handler function that GOL uses to apply the translated message from the above function (this is optional). Any additional functions that are relevant to the operation of your widget. Once this is done, the widget is then added to GOLs list of accepted widgets and is ready to be used. Aesthetics the aesthetic properties of widgets are managed through the use of GOL schemes. typedef struct { GFX_COLOR EmbossDkColor; GFX_COLOR EmbossLtColor; GFX_COLOR TextColor0; GFX_COLOR TextColor1; GFX_COLOR TextColorDisabled; GFX_COLOR Color0; GFX_COLOR Color1; GFX_COLOR ColorDisabled; GFX_COLOR CommonBkColor; void * pFont; BYTE AlphaValue; GFX_GRADIENT_STYLE gradientScheme; } GOL_SCHEME; [11] - 8.6.5 GOL SCHEME Structure every widget can contain a reference to a GOL scheme, therefore having a consistent set of colours across also widgets is a simple task. Conclusion To conclude the microchip graphics library contains all of the functions required to create the interface requested by the client, and therefore it will be one of the main focuses of this project.

2.5.3

Interrupts

Interrupts are a key feature of embedded systems and can be described as the hardware equivalent of software exceptions, for example; a chip receives some data from an external 11

source via some serial communication, an interrupt is agged in the central processing unit, execution is halted and the current program/hardware state is saved in memory. From this point on the CPU will execute a function(s) marked as the appropriate interrupt handler(s) with respects to the interrupt(s) agged. When these function(s) have concluded (Possibly resulting in a change of state in the program), program execution resumes from the point at which the interrupt occurred. This feature exists mainly due to the nature of embedded systems and the fact that they are commonly deployed as listening devices i.e. they listen for input from an external or internal source. A simple example being an electronic thermometer; the embedded system on-board the thermometer listens to the sensor and reports back any deviations from the currently displayed temperature, i.e. a change in temperature triggers an interrupt in the system that causes the displayed value to be changed via calls to the relevant function(s). Putting this information into context, the PIC32 chip used in this project has two interrupt modes; single vector mode and multiple vector mode. The dierence between the two being that multiple vector mode allows for multiple interrupts to be registered at any one time. This does however, subsequently mean that interrupts need to be prioritised accordingly in order to get consistent program behaviour. PIC32MX devices support multiple interrupts, from both internal and external sources. The devices allow high-priority interrupts to override any lower priority interrupts that may be in progress. [6] Chapter 3.1 Interrupts - Introduction Another thing to note is that the PIC32 chips contain what is called a shadow register, the shadow register is used by an interrupt handler to store register values pertaining to the current state of the program and the hardware surrounding it. As mentioned earlier, this is a method of saving the program state. The benets of using this shadow register instead of the on-board RAM is simply that the access times for registers are much lower than that of RAM, and consequently tasks are completed more eciently. Handler functions specied as priority level 7 (highest priority) will use a shadow register set to preserve the General Purpose Registers, enabling lower latency entry into the application code of the handler function. [6] Chapter 3.3.1 Interrupts - Handler Function Context Saving In terms of coding; interrupts are handled in a relatively intuitive fashion by the MPLAB C32 compiler, functions within the program code can be marked as interrupt handlers by using one of two possible methods: Interrupt Attribute 12

An attribute that is tagged onto the signature of a function, it denotes the fact that the given function is an interrupt handler, and that it carries the given priority (IPLn, where n is the priority level) along with a method of storing the current state (SRSSOFTAUTO): attribute ((interrupt([IPLn[SRSSOFTAUTO]]))) Where n is in the range of 0..7, inclusive. [6] The compiler will generate interrupt prologue and epilogue code utilizing shadow register context saving for IPLnSRS. It will use software context saving for IPLnSOFT. The compiler also supports an IPLnAUTO IPL specier that uses the runtime value in SRSCTL to determine whether it should use software or SRS context-saving code. The compiler defaults to using IPLnAUTO when the IPL specier is omitted from the interrupt() attribute. Chapter 3.3.2.1 Interrupts - INTERRUPT ATTRIBUTE Interrupt Pragma This follows the same layout as the interrupt attribute, but instead of tagging attributes onto function signatures, the information is instead stated at the start of the le as a preprocessed pragma: # pragma interrupt function-name IPLn[AUTOSOFTSRS] [6] Chapter 3.3.2.2 Interrupts - INTERRUPT PRAGMA Finally, once a function has been marked as an interrupt handler, it needs to be associated with the appropriate interrupt vector(s). There are 64 in total, numbering 0 to 63: [6] Chapter 3.4 ASSOCIATING A HANDLER FUNCTION WITH AN EXCEPTION VECTOR Vector Attribute In addition to the interrupt attribute, a vector attribute is used to denote the vector(s) that the programmer wishes to associate their handler with. In this case the function foo has been marked as an interrupt handler of priority level 4 using automatic context saving, with respects to interrupt vector 54: void attribute ((interrupt(ipl4))) attribute ((at vector(54))) foo (void) [6] 13

Chapter 3.4.3 Interrupts - Vector Attribute Interrupt Pragma For the pragma version, the vector(s) are tagged on the end like so: #pragma interrupt bar ipl5 vector 23 [6] Chapter 3,4.1 Interrupts - Interrupt Pragma Clause

2.5.4

Conguration Bits

Conguration bits are settings referring to low level hardware functionality. Not all settings are currently understood and therefore require further research, however, they can be easily changed from within MPLAB (Congure - Conguration Bits) as shown below:

Conguration bits can also be set in the programmers code, using a specic pragma: pragma-cong-directive: # pragma cong setting-list setting-list: setting setting-list, setting setting: 14

setting-name = value-name [6] Chapter 4.8 Low-Level Processor Control - CONFIGURATION BIT ACCESS

2.5.5

Dynamic Memory Management

In order to use dynamic memory management operations such as malloc, calloc and realloc, a heap must to be assigned to the program in question. This is easily done in the MPLAB project conguration window:

2.5.6

Testing

To close out this section of the review, testing needs a short mention; as of the date printed on this report, no standard unit testing facility has been found for specic use on embedded systems. Usage of unit testing suite like CUnit that has a desktop in mind could cause incompatibilities and unpredicted behaviours if compiled for the chip. For example, it is dened in the MPLAB C32 standard libraries that standard system out statements do not output to a console, but instead send the data to a serial communication port called UART2. The default implementation of mon putc writes a character to UART2. It is assumed that the application has performed any necessary initialization of the UART [6] Chapter 2.3 Library Environment - STANDARD I/O 15

This on its own makes using a standard unit testing suite dicult, and subsequently presents the opportunity to expand the project by creating a small scale unit testing suite specically for the PIC32 Development boards, as properly tested code is essential for producing a high quality solution.

16

Chapter 3 Requirements and Analysis

The client has specied a set of requirements for the LCD interface, they are broken down into two sections - mandatory and desired. A graph of sin(x) and variations of sin(x) will be used to better explain some of the following requirements:

Requirements speaking of waveform manipulations refer to the data that is currently being rendered on the screen. Manipulation in this instance refers to changing the parameters of the clients FPGA and retrieving a new set of altered data:

3.1

Mandatory

The LCD interface must show a graph of time against amplitude with the amplitude being between -2047 and 2048 decibels (dB), in increments of 1 dB and time being between 0 and 2048 in increments of 10 nano seconds, (ns).

17

 The user must be able to manipulate the pulse width of the given waveform between 1 and 100 Mhz. i.e. the greater the frequency the more squashed the wave becomes.

Here is a graph of sin(2x), as you can see, the number of oscillations shown has doubled in compression with sin(x), you may think of it as if twice as much data has been crammed into the same space set out for sin(x), making the waveform appear squashed. Equally functions such as sin(1/2x) would have the opposite eect; only half as much data will appear in the allotted space, making the waveform look wider. The user must be able to manipulate the gain of the waveform; multiplying the waveform by between 0.01 and 5 i.e. multiply the amplitude of the wave by a factor of 0.01 to 5.

18

Here is a graph of 2sin(x), as you can see, the amplitude of the wave has doubled in accordance with the scaling factor of 2, by changing the gain to the value x, we are merely multiplying the wave by a scalar, altering its amplitude at all points by a factor of x. The user must be able to manipulate the range of the waveform between 8 and 2048. i.e. change the length of the axis to a number between 8 and 2048. The user must be able to manipulate the delay of the waveform between 0 and 2048 i.e. start the graph at a particular point in the data. The results of the above manipulations must be shown in real time, i.e. the graph must be visible and update according to user input.

3.2

Desirable

The client would like the UI to be able to receive data from a preprogrammed FPGA that interfaces with the sensor. The client would like to the interface to contain the company logo. The client would like the interface to use the company colours of green and grey. The client would like the graph to ll the screen on double tap. The client would like there to be a button that starts/stops rendering of the graph.

3.3
3.3.1

Analysis
Graph

To start o - screen space is very limited and therefore, in order to give the client the best view of the graph; the UI needs to be as minimal as possible. i.e. the graph needs to take up as much space as possible whilst accommodating other functionality, such as the manipulation options. The graph in itself will be a task, as the microchip graphics library does not include a pre-written graph widget and therefore, ideally a generic graph widget should be written that plots a given set of points across a given set of axes. Further analysing the screen space issue reveals that the dimensions of the graph exceed that of the screen, therefore the points need to be scaled to t the graph. This would make points appear at the sub-pixel level - possibly causing an overly squashed and therefore unreadable graph to be rendered. If this proves to be a problem, then scroll and zoom functions need to be implemented to counteract the issue (scroll across and zoom in/out of the waveform). 19

3.3.2

Manipulation control

It is foreseeable that the manipulation options system could easily consist of a slider and two buttons. A slider to change the value of the manipulation and a couple of buttons to cycle through dierent manipulations. In keeping with the minimalistic UI, this system could also be hidden/shown at the touch of a button, resizing the graph to allow the presence of the control panel and changing it back when it is no longer needed.

3.3.3

Cosmetics

All of the cosmetic requirements can be carried out using the functions from within the microchip graphic library, for example the colour scheme is easily handled by GOL schemes.

3.3.4

Integration

The integration with the FPGA is essentially the next step in the project, and as of the date written on this document - this is not strictly required. It is probable that functions will be stubbed out that will aid this step in the future.

3.4

Testing

With the goal of this project being a functioning interface, testing is going to be a mandatory task. For the moment there are three methods of testing that would be suitable for this project:

3.4.1

Unit testing

This sort of testing is simple, it consists of numerous programmatic tests that either yield true or false, pertaining to the return value of a specic function. This will allow testing of the codes integrity as it continues to change. However, as mentioned in the literature survey - unit testing represents a challenge on embedded systems, due to the fact that the standard libraries have been altered to work with their target hardware. This has the obvious implication that software written using desktop standard C libraries wont necessarily exhibit consistent/correct behaviour when compiled under the MPLAB C32 compiler. If this is the case then it may be necessary to either devise a simple unit testing suite tailored to the device, or attempt to test the code in a desktop environment. The latter of the two options should be possible for any function that does not use anything outside of the standard libraries. The former however, allows the project to be extended to involve the creation of a simple unit testing suite.

20

3.4.2

Render testing

Unfortunately the nature of this project means that the majority of the code will be pertaining to the rendering of the actual UI. This means that a lot of the code will be dicult to unit test in the usual sense, as rendering functions on this system do not have any meaningful return values. i.e. the return value may indicate that drawing has completed - but that does not mean that drawing was carried out successfully or that the end result is 100% correct. To counteract this drawback, theoretically a system that compares a set of pixel values against the desired set of pixel values can be implemented. This would provide a reasonably valid testing basis for testing rendering functions.

3.4.3

User testing

This sort of testing essentially tests the system against the users requirements and details whether or not each action can be carried out successfully from each possible starting point within the system. This testing provides a method of thoroughly testing each feature of the system and makes it really easy to pick up obvious bugs.

21

Chapter 4 Design and Implementation

The UI has been designed in a top down manner, in the sense that the solution has been broken down on a requirement-wise basis with each requirement forming a corresponding ui feature. This seemed to be the most logical design principle as the solution needed to be mapped out within the limitations of the hardware and related software. i.e. the design of the UI is constrained by a number of hardware/software factors, for example - the screen is of a limited size and the standard features of the graphics library are also somewhat limited.

4.1

Hardware

The hardware is the most limiting factor surrounding the application and therefore must be analysed, before any design can be done.

4.1.1

Touchscreen

This project will use a 3.2 inch resistive touchscreen to display the UI and provide a means of input. [2] Screen space design implications A 3.2 inch touchscreen is not particularly large and therefore, a minimalistic approach to the UI needs to be taken. .i.e. the task needs to be completed using as few UI object as possible as in terms of screen space - priority needs to be given to the graph, with it being the primary goal of this project. Therefore it is foreseeable that parts of the UI could be hidden when not required, freeing up more space that the graph could use. Input design implications With the only way to interface with the device being through touch; every function of the application needs to be accessible either through some kind of touchable object and or through a touch gesture, for example, a touchable button that gives access to a menu. This 22

essentially means that screen space will be even more limited as functions cannot be bound to hardware buttons/keys. Implementing touch control Logically the rst piece of functionality that needs to be implemented is that of touch monitoring. The touchscreen driver function - TouchDetectPosition() needs to be called periodically in order to detect the position of a touch and store the coordinates for later use. The best way to do this is to dene an interrupt that calls this function. Unfortunately there are no interrupt vectors directly relating to the touchscreen itself (i.e. an interrupt cannot be made on the basis of the screen being touched). The solution to this problem is simple; create a timer based interrupt in which a timer with a small tick period interrupts on every tick, essentially checking the touchscreen every x number of milliseconds: // 1 milisecond tick period #define TICK_PERIOD GetPeripheralClock() / 8000 //Timer interrupt #define __T4_ISR

__ISR(_TIMER_4_VECTOR, ipl1)

void TimerInit(void) { // Initialize Timer4 OpenTimer4(T4_ON | T4_PS_1_8, TICK_PERIOD); ConfigIntTimer4(T4_INT_ON | T4_INT_PRIOR_1); } void __T4_ISR _T4Interrupt(void) { TouchDetectPosition(); tick++; TMR4 = 0; // Clear flag mT4ClearIntFlag(); } With touch control implemented, the actual design of the interface can begin.

4.2

UI structure

Working from what was said previously the UI will be structured like so, using a grand total of 7 widgets:

23

4.2.1

Options hidden

The starting state of the application, the options are hidden and the graph takes up most of the screen

4.2.2

Options shown

The state reached by pressing the options button; the graph is scaled down and the options appear where the graph once was. With the UI now physically mapped out, it is time to implement it using a series of GOL widgets. 24

4.3

GOL (Graphic Object Layer)

As previously described, GOL provides a high level API for designing interfaces on embedded systems. This library will form the basis of the UIs implementation.

4.3.1

Widgets

The following standard widgets will be used to construct the UI: Window - A GOL window serves as a backdrop for applications and features the ability to place an icon and some text in the top left corner, as well as provide a coloured background through the use of a GOL scheme. [11] - 8.2.24 Window. The purpose of this widget is purely cosmetic, but helps to encapsulate other elements of the UI.

Button - A GOL button is a standard button with optional text. This widget will be used for the stop/start, options and option cycling buttons [11] - 8.2.8 Button

25

Slider - A GOL slider is a sliding widget that has a range and a position, the value of the sliders position is dependent on the magnitude of the range, and can never exceed the range. This widget will be used to provide values for the options panel. [11] 8.2.21 Slider/Scroll Bar

4.3.2

Custom Widgets

Graph widget Due to the fact that there are no standard graph widgets included in the microchip graphics library, one will have to be created that satises the projects requirements: The LCD interface must show a graph of time against amplitude with the amplitude being between -2047 and 2048 decibels (dB), in increments of 1 dB and time being between 0 and 2048 in increments of 10 nano seconds, (ns). There is however, a problem with rendering a graph of that scale on a screen this small. There are simply not enough pixels to produce a readable graph i.e. many of the graph points will fall between pixels. One solution to this, is to create a scrollable graph, and in keeping with the minimalistic approach the graph widget can be programmed to scroll as you move your nger across it. A right to left nger movement will scroll the graph forwards, a left to right nger movement will scroll the graph backwards. Additionally: The client would like the graph to ll screen on double tap. Implementing the graph widget Following the instructions detailed in the How to Create Widgets in Microchip Graphics Library document [12] the following widget has been created: 26

typedef struct { OBJ_HEADER hdr; SHORT maxXValue; SHORT maxYValue; SHORT minXValue; SHORT minYValue; SHORT * pointBuffer; SHORT * previousPlotting; volatile SHORT graphOffset; SHORT touchPosX; } GRAPH_PANEL; The idea behind this implementation was to create a generic graph widget, that could be used outside of the bounds of this project. scroll functionality has also been implemented, as well as double tap full screen functionality. Layout Box This is not strictly a widget, as it does not contain the object header. This is just a little bit of abstraction in terms of widget placement: typedef struct { SHORT left; SHORT top; SHORT right; SHORT bottom; SHORT paddingLeft; SHORT paddingTop; SHORT paddingRight; SHORT paddingBottom; SHORT gap; WORD ordering; void *lastObject; void *firstObject; } LAYOUT_BOX; The layout box automatically lays out widgets that have a reference to it. Standard widgets such as the button and the slider have been altered to incorporate a layout box (a pointer to a layout box has been added as an option). The drawing system GOL has also been modied to apply these layouts in an overriding fashion. So that widget dimensions are overridden by those of their layout box typedef enum { LAYOUT_LEFT_TO_RIGHT = 0, 27

LAYOUT_RIGHT_TO_LEFT, LAYOUT_TOP_TO_BOTTOM, LAYOUT_BOTTOM_TO_TOP, } ORDERING; Above are the 4 layout settings: LEFT TO RIGHT lays out the widgets in a left to right ordering, with the widgets inheriting the height of the layout box (top and bottom values). RIGHT TO LEFT lays out the widgets in a right to left ordering, with the widgets inheriting the height of the layout box (top and bottom values). TOP TO BOTTOM lays out the widgets in a top to bottom ordering, with the widgets inheriting the width of the layout box (left and right values). BOTTOM TO TOP lays out the widgets in a bottom to top ordering, with the widgets inheriting the width of the layout box (left and right values).

28

Chapter 5 Testing
5.1 Unit testing

Unfortunately unit testing has not been employed in the project because of three reasons; rstly, CUnit compiled but failed to actually run on the chip, this is an example of desktop software not being compatible with embedded systems. Secondly, the actual value of unit testing in this situation is severely diminished as the majority of the code cannot be unit tested in the normal way, as drawing functions have no meaningful return values. Thirdly, time constraints on the project meant that devoting time to creating a specialised unit testing suite was not possible.

5.2

Render testing

Render testing as described in the requirements and analysis section is another testing method that had not been employed. This is simply because, although the theory was sound, it fell down in execution. The testing method suers from two fatal aws. The rst being that the screen drawing process is broken down into stages with no real way of telling if the system has nished drawing. That and the fact that the screen is continuously rendering a randomized graph means that it is conceivable that screen snapshots would not be robust enough to prove that drawing has been successful as they could be erroneously compared to an incomplete drawing stage or a slightly dierent yet correct rendering of the screen (Due to the ever changing graph). The second being the fact that storing and comparing snapshots is resource intensive both in terms of memory and processing power and could ultimately eect the performance of the application, further reducing the validity of the tests.

5.3

User testing

The section will demonstrate the functionality of the application and explain how it can be operated. Unfortunately there was no simple way to screen shot the display of the device 29

and therefore images had to be taken with a poor quality camera.

5.3.1

Starting/stopping the ascan

This is the rst screen that the user will be greeted with, in order to start displaying the ascan, simply press the start button.

From now on a graph will be rendered on the screen updating at a rate of 10hz (10 times per second), the start button will now become the stop button.

30

Pressing this button will result in graph updates stopping and the current set of data being held on the screen. The stop button will change back to the start button and can be pressed again to resume graph updates.

5.4
5.4.1

Graph features
Graph scrolling

Due to the limited amount of screen space, not all of the graph is rendered on the screen at the same time. To this eect the graph has a scroll function that scrolls the graph right

31

when the nger is drawn across the screen in a leftward motion and the graph is scrolled left when the nger is drawn across in a rightward motion.

5.4.2

Full screen mode

The graph also features a full screen mode that is toggled by double tapping the graph, note that you can still scroll whilst in this mode.

5.5

Options

Pressing the options button will display the options section as shown above, from here the displayed waveform can be manipulated by using the arrow buttons to select a mode and using the slider to change the modes parameter There is a currently a bug with the system that means the parameters value is not shown until the slider is used. 32

5.5.1

Gain

By altering the gain you are essentially multiplying the waveform by a scalar. At the moment, the graph does not allow values above or below the stated min/max Y value, this causes this mess to occur as the gain produces values above the specied boundaries.

5.5.2

Pulse width

Altering the pulse width is not possible given a single array of data, therefore for the moment this function simply shifts the phase of the waveform by 90 degrees, simply for testing purposes.

33

5.5.3

Range

Altering the range, limits the size of the x axis, in this case values outside the range are defaulted to 0.

5.5.4

Delay

Altering the delay changes the starting point of the graph, in this case values truncated by the delay are defaulted to 0.

34

Chapter 6 Results
This section will evaluate the resulting application against its requirements and explain how it meets them. Problems encountered and future work will also be covered.

6.1
6.1.1

Requirements testing
Completed
The LCD interface must show a graph of time against amplitude with the amplitude being between -2047 and 2048 decibels (dB), in increments of 1 dB and time being between 0 and 2048 in increments of 10 nano seconds, (ns). This requirement has been met through the creation and usage of a generic graph widget. The user must be able to manipulate the pulse width of the given waveform between 1 and 100 Mhz. i.e. the greater the frequency the more squashed the wave becomes. This requirement has been met by having a pulse width mode and a related place holder function that shifts the waveform by 90 degrees, for demonstration purposes. The user must be able to manipulate the range of the waveform between 8 and 2048. i.e. change the length of the axis to a number between 8 and 2048. This requirement has been met by having a range mode and a related place holder function that defaults values outside of the range to zero, for demonstration purposes. The user must be able to manipulate the delay of the waveform between 0 and 2048 i.e. start the graph at a particular point in the data.

35

This requirement has been met by having a delay mode and a related place holder function that defaults values truncated by the delay to 0, for demonstration purposes. The results of the above manipulations must be shown in real time, i.e. the graph must be visible and update according to user input. This requirement has been met by designing the UI so that the options appear on the same screen as the graph. The client would like to the interface to contain the company logo. This requirement has been met by converting a bitmap of the Tribsonics logo to pure hex and including it in the project, assigning it to the window widget. The client would like the interface to use the company colours of green and grey. This requirement has been met by creating a GOL scheme with said colours and applying it to all widgets in the UI. The client would like the graph to ll the screen on double tap. This requirement has been met. The client would like there to be a button that starts/stops rendering of the graph. This requirement has been met by adding a start/stop button next to the options button.

6.1.2

Incomplete

The user must be able to manipulate the gain of the waveform; multiplying the waveform by between 0.01 and 5 i.e. multiply the amplitude of the wave by a factor of 0.01 to 5. This requirement has been met to some extent, there is a gain mode and a related place holder function. However, due to a lack of time and a bug in the program, the oating point range of 0.01 to 5 was not included. There is also an issue with the gain function, in that it can produce graph points that exceed the maximum y value. This problem being more of a requirement mishap, as this requirement conicts with one detailing the graph parameters. The client would like the UI to be able to receive data from a preprogrammed FPGA that interfaces with the sensor 36

This requirement has been met to a very small degree. It is however, out of the projects scope.

6.2

Issues

Surprisingly, the only major issue that cropped up during the project, was testing. Therefore testing has been very lax due to the reasons stated in the testing section.

6.3

Future work

Future work will consist of: Finding a better to display a waveform that has gone outside of the max y boundary Finding a way to reliably code on embedded systems, i.e. the creation of a specialised unit testing suite/UI testing suite Integrating this system with the clients FPGA i.e. sending requests to the FPGA and receiving data from it.

37

Chapter 7 Conclusion
7.1 Achievements

In the end, the program may have a few bugs, but it works and it fulls the majority of the clients requirements. It displays a graph of an ascan correctly and has lead to a lot of programming feats being achieved along the way. GOL has been altered to implement the layout system and a brand new widget has been created to render graphs.

7.2

Improvements

One of the biggest issues with this project has been time management. It has been dicult to break up the work into manageable chunks, as well as the fact that the clients requirements were continuously changing. A denite improvement would be a larger amount of contact with the client, to make sure that the project stays consistent.

38

Bibliography
[1] - PIC32MX795F512L product page http://www.microchip.com/wwwproducts/ Devices.aspx?dDocName=en545660 Last accessed on 01/12/2011 [2] - Multimedia Expansion Board product page http://www.microchip.com/stellent/ idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en548037 Last accessed on 01/12/2011 [3] - Denition of embedded system Embedded systems glossary - E. http://www. netrino.com/Embedded-Systems/Glossary-E Last accessed on 01/12/2011 [4] - Denition of assembly language Embedded systems glossary - A. http://www. netrino.com/Embedded-Systems/Glossary-A Last accessed on 01/12/2011 [5] - Documentation detailing the Microchip 32 bit Peripheral Libraries or plib http://ww1. microchip.com/downloads/en/DeviceDoc/32bitPeripheralLibraryGuide.pdf Last accessed on 01/12/2011 [6] - Documentation detailing the Microchip MPLAB C32 compiler. http://ww1. microchip.com/downloads/en/DeviceDoc/51686B.pdf Last accessed on 01/12/2011 [7] - Documentation detailing the MPLAB C32 compiler libraries. Last accessed on 04/12/2011 http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB%20C32% 20Libraries.pdf [8] - mikroC PRO for PIC32 product page http://www.mikroe.com/eng/products/view/ 623/mikroc-pro-for-pic32/ Last accessed on 01/12/2011 [9] - MPLAB 8.80 details page http://www.microchip.com/stellent/idcplg? IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 Last accessed on 01/12/2011 [10] - MPLABX details page http://www.microchip.com/en_us/family/mplabx/index. html Last accessed on 01/12/2011

39

[11] - Graphics library help document included with Microchip Application Libraries (MAL) http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_ PAGE&nodeId=2680&dDocName=en547784 Last accessed on 29/04/2012 [12] - How to Create Widgets in Microchip Graphics Library http://ww1.microchip.com/ downloads/en/AppNotes/01246b.pdf Last accessed on 01/05/2012

40