ECE 477 Digital Systems Senior Design Project Spring 2005
Homework 10: Software Design Considerations, Narrative, and Documentation
Due: Thursday, April 7, at Classtime
Team Code Name: ______PicPockets______Group No. __4__
Team Member Completing This Homework: ____Bill Dwyer______
Report Outline:
§ Introduction (brief description of design project, with a focus on software design considerations)
§ Software design considerations (memory models, memory sections/mappings, startup code, organization of embedded application code)
§ Software design narrative (detailed description of what each code module does)
§ Software documentation
o Flowcharts/algorithms
o Listing (with comments)
o References (sources for published code adapted for use in your project)
Evaluation:
Component/Criterion / Score / Multiplier / PointsIntroduction & Software 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
Software Documentation / 0 1 2 3 4 5 6 7 8 9 10 / X 3
Technical Writing Style / 0 1 2 3 4 5 6 7 8 9 10 / X 1
TOTAL
1.0 Introduction
The PicPocket is a handheld storage device that allows the user to transfer data from an SD flash memory card into an internal small form-factor ATA hard drive. The device receives user input via pushbuttons and displays feedback through a character LCD mounted on the device. The user experience is expected to be friendly and intuitive. The team plans to make this happen by maintaining responsive feedback to user interaction and system events. The PicPocket is also intended to transfer files to and from the SD card and ATA drive as quickly as possible.
2.0 Software design considerations
The ATMEL AT91RM9200 is a very robust chip. It has a powerful ARM 9 core processor and can run up to 200 MIPS. It has 16 KB data cache, 16 KB instruction cache, 16 KB SRAM, and 128 KB flash programmable ROM. For memory mappings, please refer to the diagram below:
The PicPocket will be controlled by this microprocessor running on bare code. In other words, no embedded operating system will be used to manage the swapping of processes, et cetera. Therefore, the software must be clever, compact, and complete. For example, if the device is shipped with all the code in ROM, then in order to execute properly, it must be copied to SRAM so that the statically allocated variables can be manipulated. Furthermore, C uses a stack-based function-calling system, so it is crucial that the memory layout consider the stack growth and its effects on the code. If the code is small enough, the memory layout for the PicPocket might look something like the following:
Since it is the team’s intention to have the code take up much of SRAM (instead of using a demand paging system to bring things to and from ROM), it is important that all the C code allocate everything statically. For our purposes, the code should assume that “malloc()” does not exist. A separate section labeled “Static Data Structures” might be used to cache sections of the file allocation tables to speed up the file transfer process. A “File Transfer Buffer” will be used as a cache for the data that is in transit between the SD card and the ATA drive. The 1 KB buffer can store two drive blocks, which are the minimal granularity for writing to the drive.
The boot sequence and code will be housed on the ROM until the boot sequence commences after reset. The code in the boot sequence executes its base-level initialization and then copies the Code Store to the beginning of SRAM. The data in the ROM might look something like this:
We have been fortunate to uncover some pieces of code written for the very applications the PicPocket will perform. Particularly vital pieces include the ATA controller with FAT32 support, the SD controller, and the LCD interface.
3.0 Software design narrative
Boot Code
The boot code in ROM is very straight forward. It must perform two tasks. First, initialize the system far enough that it can be debugged (i.e. initialize the serial interface for communication with a PC). Secondly, it must copy the Code Store from ROM memory into writeable SRAM memory. The second step is not required while debugging since the code will be copied through the xmodem protocol.
Initialization Code
After the boot sequence has performed its most basic functions, it will jump into the main function. This is the main entry point of our whole system. The job of the initialization is to bring up the peripherals necessary to become functional. The sequence of initialization steps might look like the following:
Set all event flags to defaults
Initialize ports to talk to LCD
Bring up LCD device, display startup message
Initialize ports to talk to ATA drive
Bring up ATA drive
Attempt to read from drive
Initialize ports to talk to SD card
Throughout the initialization process, debug messages will be sent through the serial connection to the PC.
Event loop
It has often been said in computer engineering classes that 90% of the time is spent in 10% of the code. Well, this is that code. The event loop will call the functions that poll the buttons and, depending on the flags set by those buttons or other interrupts, will call the appropriate event handlers in good time.
To remain responsive to the user, it is important that the event loop service events in a fair manner. Therefore, the code may use a circular buffer to keep track of the order in which the events were received. A data structure containing several bit masks and state variables may serve to take a snapshot of the state when the event was queued. A detailed diagram of the event loop is included later in this document.
Note, it is a good idea to update the LCD after each event handler (and during, for that matter).
Navigation code
Navigation of the file system on the SD card and the ATA drive make up two out of five success criteria for this project. It is vitally crucial to the grades of the team members that this portion is functioning correctly.
The code in this section will interact with the FAT 32 driver mentioned below to read the root level file system and place the listing in the LCD character buffer. When a UP_BUTTON_EVENT or DOWN_BUTTON_EVENT flag is set, the navigation event handler will select the previous or next file or folder respectively. When a RIGHT_BUTTON_EVENT flag is triggered, the navigation code will seek into the currently selected folder (a selected file will have no effect).
All changes to the state as a result of user input will result in a re-write to the LCD character buffer and the LCD_REFRESH flag will be set.
Transfer code
The transfer code is the most challenging piece of code in our system. It must copy information to and from the SD device and the ATA drive. It will be based heavily on the implementation of the FAT 32 driver mentioned below.
The code is responsible for reading one or two block (512 or 1024 bytes) from one of the devices and writing it to the other. It is also the responsibly of the transfer code to create new files and directories as necessary before the transfer.
FAT 32 ATA driver code
A writer at http://www.circuitcellar.com created an ATA drive controller that used the FAT 32 file system. Fortunately, the code was written for an Atmel product, the ATMega 128. Although the ATMega has a different core processor, the code can be adapted to control the PicPocket’s ATA drive. In fact, we modeled the ATA section of the schematic after the working examples laid out at circuit cellar.
The adaptation of the code to our device will be a crucial and delicate transformation. The end goal of the driver is to allow the rest of the code to perform high-level operations such as fopen() or fclose(). Since there is no operating system, there is no file security or write-synchronization. It is up to the transfer code to manage this.
SD driver code
Atmel supplies example code to demonstrate how the AT91’s MCI peripheral can communicate with an SD card. The SD driver will be based on this code, which is written specifically for our chip, and the FAT 32 code adapted from the circuit cellar article.
LCD controller code
A buffer of the characters in the LCD display will be maintained in SRAM. High level functions for printing into this buffer (such as LCDprintf()) will be included in the code. After the buffer has been altered, it is up the event handler to set the LCD_REFRESH flag, or call the LCD refresher manually (which is often preferred).
The refresher will read the characters through the programmable IO pins to set the characters on the LCD. If a latching/synchronism mechanism is available, it will be used accordingly to minimize the appearance of “drawing” the characters.
4.0 Software documentation
4.1 Flowcharts
Event Loop
Data Transfer Path
4.2 Listing
Boot Code
Event loop
Transfer code
ATMEL SD code
FAT 32 code
The following are the prototypes for the FAT 32 and ATA controller code. The whole code is around 2000 lines. It is the team’s intention to slim down the code as much as possible while fitting it to the AT91.
SD code
The following are the prototypes for the SD controller code. The code, since it is designed specifically for the AT91 by Atmel will be nominally utilized as an API.
LCD controller code
KwikByte Debug I/O code
4.3 Code References
FAT 32 ATA
[1] Eady, Fred. “Construct an ATA Hard Drive Controller”. Circuit Cellar Magazine Online. Issue 150. January 2003. http://www.circuitcellar.com/library/print/0103/Eady150/index.htm
Boot assembly, Debug I/O
[2] KwikByte Code for development board KB9201. http://www.kwikbyte.com/kb9201_downloads.htm
SD
[3] Atmel AT91RM9200-BasicMCIDevice-ARM1_2-2_0.zip http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3193
LCD Controller
[4]Robert Ault, EET CrystalFontz LCD code
The PicPockets Page 1