ABSTRACT
DESIGN REVIEW
TEAM MEMBERS
PROJECT CLIENT
PROJECT ADVISOR
SENIOR DESIGN HOMEPAGE
SSOL HOMEPAGE
OTHER SSOL PROJECTS

 Design Review

OUTLINE:

Background

Design Objectives

Proposed Technical Solution

•Memory Analysis

•Controller Analysis

•Circuit Block Diagram

•Daughter Card Design

•Software Design and Flowchart

Future Work

•Board Construction

•Software

•Testing / Debugging

Proposed Budget

Proposed Schedule

Background

The High Altitude Balloon Experiments in Technology (HABET) program is coordinated by Dr. John P. Basart and is funded by the Iowa Space Grant Consortium (ISGC). The ISGC is a group of Iowa universities that receive research funding from the National Aeronautics and Space Administration (NASA).

In accordance with NASA’s efforts to provide funding for innovative projects with a relevance to NASA’s mission and in conjunction with their creedo of " faster, cheaper, better...", HABET’s goal is to continually perform various experiments at altitudes approaching 100,000 feet. Since each HABET flight is unique in it’s goals and implementation, a highly adaptive systems design has been implemented for gathering data and command-and-control of the spacecraft. One of the objectives is to be able to capture in-flight video. To accomplish this, HABET has decided to implement a device to capture large amounts of data so that video (or any other types of data) can be stored on board the spacecraft. They currently have no such capability.

The Expandable Memory System (EMS) team has been tasked with designing a high-capacity, expandable memory system that can be versatile enough to capture any kind of serial data that HABET would wish to store on-board their spacecraft.

 

 

Design Objectives

HABET has specified the following guidelines pertaining to the design of this memory system. First, the new memory board must match the design of their current system for their Heavy Spacecraft Bus (HSB-1). This means that the circuit board design must adhere to a physical size of 4 inches by 6 inches to fit into their passive backplane design for the rest of their circuitry. It will also have to have a 50-pin connector to mate with the system bus. Second, the memory must be expandable to meet varying demands of different flight requirements. This means that some flights may use more memory than others. Since weight is an issue for any HABET mission, the minimum amount of hardware is always flown. Third, the circuitry and memory system must be able to withstand the extreme cold temperature at 100,000 feet of altitude and be sturdy enough to handle all of the jarring and buffeting of the spacecraft during a normal flight.

 

 

Proposed Technical Solution

The EMS circuitry will consist of two main components: the memory cells and the control unit with it’s own chip decode logic. Each of these components have been thoroughly investigated by the EMS team. There are many options available for use, all of which have their good and bad points. Analysis of the memory components and controller components are listed in the following paragraphs of this section. 

Memory Analysis

A number of solutions for mass data storage are available for general purpose use. Many of these items were considered and evaluated for use by this project. Some of these are evaluated below.

Standard IDE Hard Drive:

Pros &emdash; Can handle a large amount of data (depending on size of drive) and is non-volatile.

Cons &emdash; Heavy, mechanical integrity of the heads cannot be assured during flight because of jarring, significant power requirement.

Standard Single Inline Memory Modules (SIMM):

Pros &emdash; Can configure a circuit board to have a number of different SIMM slots for expandability, lightweight, low power.

Cons &emdash; Though locked in place, SIMM’s could jar lose in flight, volatile with power loss.

Flash Memory:

Pros &emdash; Can configure a circuit board to have an expandable number of Flash Memory chips, lightweight, low power, non-volatile even with power loss, allows circuit board removal with no data loss.

Cons &emdash; Largest size only capable of 2 Megabytes of storage.

PCMCIA Memory Cards:

Pros &emdash; Large number of available memory sizes by using different cards,

easily plugs into a laptop computer for downloading of data.

Cons &emdash; Individual cards are expensive, card drive hardware is heavy.

After reviewing these, the Flash Memory IC’s were viewed as the best available resource for HABET’s use. They are lightweight and require the smallest amount of power of all the options considered. They also have the advantage of being completely non-volatile, even with the circuit board removed from the HSB’s backplane. This will give the advantage of being able to remove the circuit card to download the data from it onto a PC. The disadvantage of the available amount of storage space can be overcome by adding more memory chips to the circuit board by the use of an additional daughter card that can be added to the circuit board. This will be described in detail later in this report.

The Flash Memory IC that was chosen for this project was AMD’s AM29F016B Flash Memory chip. It has a storage capacity of 16 Megabits (2,048K by 8 bit). It is the largest Flash Memory IC that is readily available for the EMS team to use.

Controller Analysis

There are many microcontroller/microprocessors available for use as the control unit. The main limiting factor is the number of input/output (I/O) lines available for addressing and control of individual memory chips. To be able to address a large amount of memory, as many as twenty eight address lines might be needed. This would give an addressing capability of approximately 250 Megabytes. The microcontroller would also need to have some individual control lines for reading and writing control to the memory chips and possibly some others that may be needed by the particular Flash Memory IC’s that are being used. The microcontroller would also need to have a serial port available to receive data and then eight additional lines for data transmission to the memory cells. The total number of pins that will be needed will be nearly 40.

The micrcontroller that was chosen was Microchip’s PIC17C756. It has 50 I/O lines that can be configured for any type of use by the EMS team. One of the main reasons this controller was chosen over many others is because HABET already uses PIC microcontrollers in much of their other work, and they have all of the programming hardware and software available to use this IC.

Circuit Block Diagram

The EMS Circuit Block diagram is shown in Figure 1. The 50-pin main bus connector is shown on the left side of the diagram. This connector will allow the EMS board to connect to HABET’s HSB through its passive backplane. The board will be supplied with the necessary power through this connection. It will also be used for the serial transmission of data from any of the other components onboard the HSB. The PIC 17C756 and it’s chip select logic is shown next. The microcontroller is described in the previous section. The chip select logic allows the EMS team to expand the number of Flash Memory cells available for data storage. The chip selector will be a Programmable Electrically Erasable Logic (PEEL) device. Since each Flash Memory chip needs to have one of its inputs pulled high for "chip select" before it can store a byte of data, the EMS team decided to use a PEEL for decoding which cell was selected. The last five (most significant) bits of the address are used as the chip select logic. This gives the EMS board a total capacity of 32 Flash Memory cells for data storage. The center portion of Figure 1 shows the Flash Memory cells. There is enough space for eight on the main circuit board. The other Flash Memory cells will be installed on a daughter card that connects to the EMS board via the 50 pin connector on the right side of the diagram.

Figure 1. EMS Block Diagram showing microcontroller circuitry, chip select logic,

Flash Memory cells, Bus connector, and expansion card connector.

 

Daughter Card Design

The Daughter Card for the EMS memory board will be designed to mate directly on top of the EMS board. It will connect through the Memory Expansion Card Connector interface on the right side of the EMS block diagram. The daughter card will consist of a smaller circuit card that only has the Flash Memory IC’s and a PEEL for the Chip Select Decoding. It will have the capacity for as many as 24 Flash Memory IC’s. This will allow the EMS Board to have as much as 64 Megabytes of Flash Memory.

 

Software Design and Flowchart

There are two main areas of software design for the EMS project. First, the software that must developed for the microcontroller to allow it to reliably store data into the Flash Memory cells. This programming will be done in C with mixed Assembly language and is currently under development by the team. Second, the software that will allow HABET to interface the EMS board directly with a PC computer to download the data that has been stored for a given mission. This will consist of a Graphical User Interface (GUI) of some sort that will guide the user through the process of downloading data from the EMS board.

The decision flowchart for the microcontroller software is shown in figure 2. It steps through a typical decision making sequence that the microcontroller must perform each time it receives a byte of data through its serial port connection.

 

Figure 2. Decision-making flowchart for PIC 17C756 microcontroller software

A brief description of each of the decision-making flowchart blocks is as follows:

Power Up

This stage is the starting point of the whole system. The voltage source is given from one of the channel on the HABET backplane bus.

 

Reset

The Power-on Reset circuit, one of the additional circuit built on-chip, holds the device in reset until VDD (voltage supply) is above the trip point (in the range of 1.4V - 2.3V). The devices produce an internal reset for both rising and falling VDD.

 

Initialization

Once the Program Counter is incremented from the Reset state, the first instruction of the program is fetched and then executed. The first instruction in the program will lead to a procedure to initialize all the associated registers and address allocation.

 

Read data from USART1 Asynchronous Receive pin

The system input uses serial asynchronous communication between the input device and the microcontroller. The serial receiver is assigned to be RX1, which is the USART1 (SCI) Asynchronous Receive.

 

Store 1 bit in USART1 Receive buffer

The data from the input channel is then stored in the receive buffer RCREG1 where the system can get the input data from. Since it is a serial communication, the data rate stored in the receive register is 1 bit every clock tick. The baud rate is depending on the USART Baud Rate Generator (BRG).

Note: The BRG is initialized at the Initialization state.

 

USART1 Receive buffer is full?

This conditional state checks whether or not the receive buffer RCREG1 already has 9-bit data from the input receive. If the data inside the receive buffer RCREG1 is less than 9 bits, the system will loop back to read more data from the input receive. Otherwise, the system will continue to the next state.

 

Any error occurred during reception?

This conditional state checks whether or not there is any error appeared during the 9-bit reception. If there is some error, the system will turn its path to the Discard data state. Otherwise, it will continue to the subsequent state.

 

Discard data

In this state, the system will simply reset the associated flags and registers to receive the next consecutive 9-bit data.

 

Read data from USART1 Receive buffer

The data is copied into CPU RAM with precondition that the data is ready and error-free. Then, the system will prepare the data frame to make it ready to be stored in the main memory module.

 

Time to get new data?

This conditional state monitors the timer every time it is invoked before writing to the memory module. If the timer reach the threshold to read new data, the system will execute the Store current data and Memory module address in On-chip data RAM state.

 

Store current data and Memory module address in On-chip data RAM

When this state is invoked, that means four things are happening:

there has been a failure on the memory module

the current data has not been stored in the memory module

the time is up to read the next incoming input data

the current data along with the corresponding memory module address is stored in the On-chip data RAM.

 

Memory module ready?

The system checks whether or not the memory module is ready. If it is not ready, the system will check the timer by invoking the Time to get new data? state.

 

Is there data in On-chip data RAM?

The system checks whether or not there is data in On-chip data RAM. If there is, the data will be moved and stored in the memory module. Otherwise, the system stores the current data in memory module.

 

Move and store data from On-chip data RAM to Memory Module

This module just copies the pointed to data in data RAM to the memory module. After being copied, the pointer is incremented.

 

Store current data in Memory Module

 

This module copies data from the CPU RAM to the memory module.

 

PIC Pseudocode

Initialize all registers

while(1) {

while(USART1 Receive buffer is not full);

if (any error occurred) {

discard data

} else {

Read data and Clear data in USART1 Recieve Buffer

flag = 0;

while (!(time to get new data) && !flag) {

if (memory module is ready) {

if (any data in on-chip RAM)

move data from on-chip RAM to memory module

else {

store current data in memory module

flag = 1;

}

} else

store current data in on-chip RAM

}

}

}

  

Future Work

Though a good start has been made on this project in the form of research of basic components, the real construction of the EMS board will take place next semester. The goal of the EMS team is to have a functioning EMS main circuit board by the end of April 1999. Some of the work to be completed is detailed in the following paragraphs. 

Board Construction

Layout and design of the EMS circuit board will begin in January. Preliminary layout of the components has been completed. Circuit traces for the individual bus lines will be added. Then the circuit board will be etched by the EMS team in HABET’s workshop. The actual circuit will be laid out by MicroGraphix Designer software. After etching, the individual components will be mounted and soldered onto the circuit board. This will be Mr. Cook’s primary responsibility for Spring ’99.

 

Software

The software development will begin at the same time as the circuit board manufacture. A Microchip PIC-specific C compiler will be used for coding the microcontroller. The microcontroller will have basic read, write, erase, verify, and test functions available through the PIC’s serial interface. Borland C/C++ will be used for coding the PC interface of the EMS board. The PC will have a GUI interface to download, upload, test, and erase the contents of the EMS memory cells. The PIC code will be the primary responsibility of Mr. Hermanto and the GUI will be the responsibility of Mr. Porter.

 

Testing/Debugging

The testing and debugging will involve several steps. The first step will be to test the basic functioning of the EMS board. The board will be visually and then electrically inspected. The second step will be to create low-level code to test basic functioning of the memory, addressing, and data bus. The third step will be the testing of each individual function in the software. Fourth, the entire system will be tested in the lab. Finally, the EMS board will be flown on a HABET mission to capture telemetry data that will also be sent back to the ground via HABET’s radio telemetry receiver station. After recovery of the spacecraft, the two sets of data will be compared for any errors.

 

Proposed Budgets

 

An attached budget of human effort and material costs is attached. These budgets are current through 8 December 1998. HABET is providing the additional funding for the hardware purchases of this design project.

 

Proposed Schedule

 

An attached Gantt chart shows the proposed schedule of work throughout the life of this project. Included are all design and implementation phases, along with classwork. The chart has been updated to include completion of all work through 8 December 1998.