design project - college of engineering - purdue … · web viewthe du features an advanced text...

Homework 10: Software Design ConsiderationsDue: Friday, March 31, at NOON

Team Code Name: iReader_____________________________________ Group No. 3_____

Team Member Completing This Homework: Daniel Wilhelm_________________________

E-mail Address of Report Author: dwilhelm_______________________ @ purdue.edu

Evaluation:

Component/Criterion Score Multiplier Points

Introduction & Summary 0 1 2 3 4 5 6 7 8 9 10 X 1

Software Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 3

Software Design Narrative 0 1 2 3 4 5 6 7 8 9 10 X 3

List of References 0 1 2 3 4 5 6 7 8 9 10 X 1

Appendices 0 1 2 3 4 5 6 7 8 9 10 X 1

Technical Writing Style 0 1 2 3 4 5 6 7 8 9 10 X 1

TOTAL

Comments:

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

NOTE: This is the last in a series of four “design component” homework assignments, each of which is to be completed by one team member. The completed homework will count for 10% of the team member’s individual grade.

ECE 477 Digital Systems Senior Design Project Spring 2006

1.0 Introduction

The iReader, a paperback-book sized design project, uses software to format text files from a

USB thumbdrive for display on a graphical LCD. The device’s modular design, featuring the

External Interfacing Unit (EIU) and the Display Unit (DU), each housing separate

microcontrollers, permits the iReader to be display-independent; only the DU must be redesigned

to support new display technologies. The DU features an advanced text rendering subsystem

which supports writing multiple variable-width raster fonts to the LCD controller. The EIU

parses text files from FAT-formatted USB thumbdrives, composing each page of text for optimal

display. Peripheral units used for I/O include an LCD controller, battery gauge, pushbuttons,

magnetic switch, and USB drive. The iReader also supports an AC-rechargeable battery. Each

microcontroller and its associated peripherals imposes limits for code storage, temporary storage,

and processing time, and these constraints guide software design.

2.0 Software Design Considerations

2.1 The Display Unit (DU)

The DU utilizes a Freescale 9S08GT32 microcontroller to perform text and menu rendering,

communication with the EIU, and communication with the LCD controller (see Appendix A).

The 9S08GT32 constrains software to 32K of on-chip Flash and temporary storage (stack and

heap) to 2K of on-chip SRAM. Text rasterization and communication software is estimated to

require no more than 16K due to the choice of relatively simplistic algorithms. The remaining

16K will be used for static font storage, capable of storing nine monochrome raster fonts: three

font sizes (40x40, 15x15, and 8x8) with three faces per size (normal, bold, and italic). The 2K

SRAM provides 800B for one 30x40 screen of characters and 800B for one 320x20 line of

rendered text, leaving a sufficient 448B for a stack.

The DU communicates with the EIU through SPI and the S1D13700 (S1D) LCD controller [3]

through general port pins. An external 8 MHz crystal is used as a clock (XTAL and EXTAL

pins). Four SPI pins are used, SPSCK, MOSI, MISO, and SS_L, to transfer a serial message

stream to the EIU, defined in section 3.0. The DU SPI operates as a slave, with preselect scalar

bits set to 8 (equivalent to the external osciallator), yielding a 1 MHz communication rate. CPOL

= 0 (polarity – no inverter) and CPHA = 0 (clock phase – out of phase) to initialize the clock

-1-


format. Port B (pins 0-7) are general-purpose (GP) output pins used to transfer one LCD data

byte (D0-D7), port A (pins 0-3) GP output pins are used to transfer S1D control signals (CS_L,

WR_L, and RD_L, respectively), and port D (pin 3) is also used as a GP output pin to transmit

bit 0 of the address bus, used to control operating mode. Port A (pin 4) is used as a GP input pin

with an internal pullup resistor enabled to read Hi-Z values as active high on the WAIT_L line.

The microcontroller communicates with the S1D in 8080 operating mode (preset by hardware),

requiring busy waiting on the WAIT_L signal to ensure feedback from the S1D.

The DU is interrupt-driven, its interrupts being a signal from the SPI indicating a new incoming

message from the EIU and the timer. An interrupt-driven design was chosen because the display

must only be updated upon a user request or EIU determination (e.g. battery status). Hence, the

interrupt enable register must be set. The update speed is not critical since a user can likely

tolerate only three updates per second since he is reading text. Since interrupts are also easy to

program and allow the processor to consume less power than polling, an interrupt-driven design

is appropriate. A 6-pin header near the microcontroller facilitates debugging and in-circuit

programming by allowing connection of a BDM Multilink cable. Self-test of the S1D is

facilitated through the WAIT_L signal mentioned above; using SPI, the DU could also respond

to the EIU indicating it is on-line. (This feature is still being considered.)

2.2 The External Interface Unit (EIU)

The EIU microcontroller is a Cypress CY7C67300 (CY7), an “EZ-Host Programmable

Embedded USB Host/Peripheral Controller”. The EIU reads from the USB port, interprets the

FAT filesystem, reads user input (i.e. buttons, magnetic switch), and communicates with the DU

(see Appendix A). The CY7 contains 16K on-chip SRAM and 8K on-chip EEPROM. However,

these modules are not available for non-native program code; hence, 32K SRAM [4] and 64K

EEPROM were added externally for local program code. Local compilation testing indicates that

the Cypress standard framework incorporating USB reading and FAT decoding requires 47K

EEPROM (10K for unnecessary test routines and 9K for libgcc – only 32-bit conversion routines

required). The local programming code is estimated to require no more than 16K since few

functions are performed. Further, static data representing static images (e.g. a startup screen) will

likely be stored in the TXT section here as well, requiring 9.6K per screen (before RLE

-2-


compression, if necessary).

A large 32K SRAM was chosen to hold large USB chunks in memory while also storing a parsed

version to be sent to the DU. Each USB chunk and parsed chunk is 4K, and a local page cache of

5 parsed chunks will be stored locally, for a total SRAM requirement of 28K. These additional

memories are directly supported by the CY7, and special pins (A0-A14, RD_L, WR_L,

XRAMSEL_L) are dedicated to this purpose. An external 12 MHz oscillator is also used as a

clock.

The CY7 communicates with several external peripherals, including user input (i.e. buttons,

magnetic switch), the DU through SPI, the battery gauge [5], and the USB port. User input is

received through general-purpose IO pins GPIO_12-GPIO_15 which must be configured as input

pins. The battery gauge is similarly inputted through GPIO_0-GPIO_2. The CY7 natively

supports a USB host, so specific pins, DP1A and DM1A, are available to read directly from the

USB D Plus and USB D Minus pins. The CY7 has twelve USB host registers which must be set

to configure the host address, general USB control parameters, frames to read, and status modes.

Three SPI pins are used, SCK, MOSI, MISO, to transfer a serial message stream to the DU. The

EIU SPI operates as a master, so the master select bit must be set in the SPI configuration

register. The interrupt enable register is enabled, and the SPI communications is set via the SPI

control register to operate in full duplex. The EIU is interrupt-driven, responding to interrupts

from user input and the battery gauge. This design was chosen to simplify code and to avoid

wasting unnecessary power when the CY7 is waiting for an event. The two debug pins were

inadvertently not connected, so a new board is being sent with these pins directed toward a

debug header. Several power-on tests have been incorporated, for instance messaging the DU

and testing the battery gauge.

3.0 Software Design Narrative

The iReader uses custom microcontroller software and third-party libraries, for instance it uses

Cypress-supplied libraries for communicating with the USB port and decoding the FAT

-3-


filesystem. The EIU receives user input from buttons and a magnetic switch then translates these

into messages through three possible paths, beginning with the view page interrupt handler, the

menu interrupt handler, or the EIU initialization (see Appendix B). The DU acts as a slave to the

EIU, only executing code in response to EIU messages; hence, it can be thought as an extension

to the EIU hierarchies. The interrupt handlers then branch into state machines which decode the

interrupt and provide an appropriate response, either reading from the USB drive or sending a

message to the DU. The DU then either renders something, initializes, or stores new parameters,

ultimately affecting the LCD controller.

Each module is important for successful overall functioning of the iReader. ‘EIU Init’ and ‘DU

Init’ initialize general IO pins, initialize peripherals such as USB, SPI, and the LCD controller,

and set initial variables. These routines also perform initial menu rendering functions and put the

microprocessor into an interrupt-driven state. These functions haven been written, but only

currently initialize peripherals which have been tested.

Three interrupt handlers drive the iReader. The EIU contains a ‘view page handler’ and a ‘view

menu handler’ which is called upon battery gauge readings, left/right button presses, select/menu

button presses, and the closure of the magnetic switch. Triggered by an interrupt, these simply

branch into state machines which perform more advanced functionality (the view page and menu

state machines, respectively). The ‘view menu handler’ is called when the user is in a menu, and

the ‘view page handler’ is called when the user is browsing through text. These interrupt

handlers are not yet written, and are pending until each peripheral is sufficiently tested.

The ‘view page state machine’, upon a left/right button press, loads a new page into cache and

sends the new central page to the DU for rendering. This involves requesting a new chunk of text

file from the USB port, using the ‘read FAT’ and ‘read USB’ modules provided by Cypress.

These modules have been compiled and reduced in size, but they have not been tested yet. This

state machine also formats each line of text to the display by adding the width of each character

to the total x position until the text runs off the screen, at which point the entire word is wrapped

to the next line. Once a page is determined and we have parsed the desired amount into the file,

this new page is cached in a circular buffer of pages, the head of which is sent through SPI to the

-4-


DU. Other handled actions include the magnetic switch which powers down the device, and the

menu button which switches the microprocessor to using the ‘menu interrupt state machine’,

which sends RENDER MENU commands to the DU based on user input. Neither state machine

is written yet.

The send message and receive message modules communicate between the EIU and DU using

SPI. The iReader uses a message passing system where the EIU sends a message and the DU

responds. It is being considered to have the DU reply with a confirmation which would be useful

for startup testing. The DU runs on a constant interrupt waiting for SPI messages, and when one

arrives then it typically updates the data to the LCD controller. The four main messages sent are

OPTION CHANGE, RENDER MENU, STARTUP, and NEW PAGE. With the exception of

STARTUP, these messages are variable byte with accompanying data, for instance 800B to

describe the new page of text. These send and receive modules as well as the interrupt handler

are currently being tested and prototyped.

The ‘text renderer’ and ‘menu renderer’ modules format page data for display on the LCD which

is sent to the DU through SPI. The menu renderer contains functions to render a set of primitives

(e.g. line, menu option, shaded option). To render a complete menu, the EIU sends a

combination of NEW PAGE and RENDER MENU messages in order to position text and

graphics correctly. The text renderer receives data from the 800B text page cache and renders it

line by line, each character taking from the Flash the appropriate bitmap. After a character, it

increments the x position by the character width. If it overflows the screen, then the word is

rendered on the next line instead. The text renderer has been fully completed in C with an LCD

emulator, and the menu renderer has not yet been written.

The final module, ‘send to LCD controller’, sends the output from the menu and text renderers to

the LCD controller, effecting a change on the display. This module communicates with the LCD

controller using general-purpose IO pins, and it has been completely written and tested.

-5-


4.0 SummaryThe iReader’s functionality completely depends on software since its purpose is software-based

– to render a text file to the screen. It is divided into two main modules – the Display Unit (DU)

and the External Interface Unit (EIU). The Freescale 9S08GT32 drives the DU while the Cypress

CY7C67300 drives the EIU. Many internal and peripheral peripherals are communicated with –

the USB, user interface buttons, the SPI, the battery gauge, and the LCD controller (Appendix

A). Each microcontroller is interrupt-driven, only responding to events such as user input and

battery gauge readings. The code’s hierarchical design allows for efficient code flow and reuse

from the interrupt handlers of the EIU to the final LCD controller output of the DU slave

(Appendix B). Much of the high-level code has already been written and tested, but the low-level

device routines and interrupt handlers dependent on the specifics of each microcontroller are not

yet implemented.

-6-


List of References

[1] Freescale Semiconductor, Inc.; Freescale MC9S08GT32 Datasheet; [INTERNET]

http://shay.ecn.purdue.edu/~477grp3/hw10_code/MC9S08GT32.pdf

[2] Cypress Semiconductor Corporation; Cypress CY7C67300 Datasheet; [INTERNET]

http://shay.ecn.purdue.edu/~477grp3/hw10_code/cy7c67300_5.pdf

[3] Seiko Epson Corporation; S1D13700 Datasheet; [INTERNET]

http://shay.ecn.purdue.edu/~477grp3/hw10_code/s1d13700.pdf

[4] Microchip Technology, Inc.; 24AA256 Datasheet; [INTERNET]

http://shay.ecn.purdue.edu/~477grp3/hw10_code/21203n.pdf

[5] Linear Technology Corp.; LTC1980 Datasheet; [INTERNET]

http://shay.ecn.purdue.edu/~477grp3/hw10_code/1980f.pdf

-7-

IMPORTANT: Use standard IEEE format for references, and CITE ALL REFERENCES listed in the body of your report. Any URLs cited should be “hot” links.





http://shay.ecn.purdue.edu/~477grp3/hw10_code/MC9S08GT32.pdf


Appendix A: Flowchart/Pseudo-code for Main Program

-8-


Appendix B: Hierarchical Block Diagram of Code Organization

NOTE: Hot links only on top diagram, indicated by gray boxes.

-9-

design project - college of engineering - purdue … · web viewthe du features an advanced text...

Documents