ECE791/792 Final Report

Project Title: Apollo Guidance Computer

Project Team: Shane Whalen

ECE Faculty Advisor: Andrzej Rucinski

Current Date: December 17, 2010

Project Completion Date: December 12, 2010

1

Table of Contents 1 Introduction .......................................................................................................................................... 3

1.1 Background ................................................................................................................................... 3

1.1.1 AGC ........................................................................................................................................ 3

1.1.2 PSoC ...................................................................................................................................... 3

1.2 Problem Definition ........................................................................................................................ 3

1.3 Objectives...................................................................................................................................... 3

2 Design ................................................................................................................................................... 4

3 Implementation .................................................................................................................................... 5

3.1 PSoC .............................................................................................................................................. 6

3.1.1 Communication ..................................................................................................................... 7

3.1.2 DSKY Update ....................................................................................................................... 10

3.1.3 Change Orbit ....................................................................................................................... 11

3.1.4 Memory ............................................................................................................................... 12

3.1.5 System Time ........................................................................................................................ 12

3.2 MATLAB ....................................................................................................................................... 12

3.2.1 Seven Segment Displays...................................................................................................... 13

3.2.2 Keypad panel ....................................................................................................................... 13

3.2.3 Indicator Panel .................................................................................................................... 14

3.2.4 Flash Timer .......................................................................................................................... 14

3.2.5 Communication ................................................................................................................... 14

3.2.6 Transmitter ......................................................................................................................... 14

3.2.7 Logger .................................................................................................................................. 15

3.3 General Communication ............................................................................................................. 15

3.3.1 Formatted Strings ............................................................................................................... 15

4 Testing ................................................................................................................................................ 17

4.1 Testing for Independence ........................................................................................................... 17

4.2 Testing the Communication System ........................................................................................... 17

4.2.1 Testing the Initial Serial Communication Link ..................................................................... 17

4.3 Testing the DSKY ......................................................................................................................... 18

4.3.1 Testing the Seven segment displays ................................................................................... 18

4.3.2 Testing the Keypad Panel .................................................................................................... 18

4.3.3 Parser .................................................................................................................................. 18

4.3.4 Indicators ............................................................................................................................ 18

4.4 Memory ....................................................................................................................................... 18

4.5 Time ............................................................................................................................................ 19

4.6 Error Checking ............................................................................................................................. 19

5 Evaluation ........................................................................................................................................... 20

5.1 Timeline ....................................................................................................................................... 20

5.2 Objectives Met ............................................................................................................................ 21

2

5.3 Possible Additions ....................................................................................................................... 21

6 Appendices ......................................................................................................................................... 22

6.1 Data Strings ................................................................................................................................. 22

6.1.1 Memory Data Strings .......................................................................................................... 22

6.1.2 Set time Data Strings ........................................................................................................... 22

6.1.3 Memory and OPR ERR Test sequence ................................................................................. 23

6.1.4 Orbit Change Sequence....................................................................................................... 23

6.2 My VERB NOUN List .................................................................................................................... 24

6.3 Log Capture ................................................................................................................................. 25

Table of Figures

Figure 3-1: The Original Apollo Guidance Computer .................................................................................... 5

Figure 3-2: Screenshot of my AGC DSKY ....................................................................................................... 5

Figure 3-3: Physical Connection of my AGC .................................................................................................. 6

Figure 3-4: PSoC Block Diagram .................................................................................................................... 6

Figure 3-5:PSoC Command Receiver Flow Chart .......................................................................................... 7

Figure 3-6: Code snippet of param structure................................................................................................ 8

Figure 3-7: Code snippet of AGC_Status struct............................................................................................. 8

Figure 3-8: PSoC Transmitter Flow Chart ...................................................................................................... 9

Figure 3-9: DSKY Update Counter ............................................................................................................... 11

Figure 3-10: Orbit Change Countdown Timer ............................................................................................. 11

Figure 3-11: MATLAB Block Diagram .......................................................................................................... 13

Figure 5-1: Senior Project Timeline ............................................................................................................. 20

Figure 6-1:VERB and NOUN Commands Table ........................................................................................... 24

3

1 Introduction

1.1 Background

1.1.1 AGC

The Apollo Guidance computer was originally designed by M.I.T. In 1964 it was the world’s first

microchip computer. The design consisted state of the art components: approximately 5000 integrated

circuits (3-input NOR gates), a 1.024 MHz clock, 1k read/write memory and 12k read only memory. This

was a giant leap in the technology of the time because only three years prior Fairchild Semiconductor

Corporation released commercially the first integrated circuits.

1.1.2 PSoC

PSoC or programmable embedded system-on-chip is a robust but easy to use devices first

created by Cypress Semiconductor Corporation in 2002. These devices contain configurable analog and

digital components, memory and a microcontroller unit one a single chip.

1.2 Problem Definition The Apollo Guidance Computer was made using a very complicated system of integrated

circuits’ and peripherals. The design was very costly and had other fallbacks such as size, weight, ability

to duplicate, and extend. Technology has advanced greatly since the creation of the Apollo Guidance

Computer and thus should allow us to eliminate all of the problems mentioned.

In my model, I did not try and create the exact computer that M.I.T. created because it would

not take advantage of new technology. For example, to create the same memory system that the AGC

had, I just pre-allocated memory in code instead of buying or making a separate module for memory.

Also, I will not need to implement the op-code, timing, and DSKY systems in nearly the same way

because of these reasons. Furthermore, I did not implement every feature of original Apollo Guidance

Computer, to do so (as a few people have done) would have taken multiple years to complete by myself

as a four credit hour class.

1.3 Objectives 1. Be able to replicate parts of a practical computer using an embedded system.

2. Create a replica DSKY that imitates that of the AGC using a widely used programming

language.

3. Create a custom easy to use communication link between two computers.

4. Learn how to code and use an embedded system more effectively.

5. Display the power of PSoC technology as a holistic solution to many modern computing

problems.

4

2 Design

There are many choices when it comes to how people choose to replicate the Apollo Guidance

Computer. There is a hardware implementation which recreates the computer using the same block

diagrams, but use more modern (already built) components to make the design more efficient and less

cumbersome. This design is great but does not complete my objectives because does not take

advantage of the most modern technology and it is hard to duplicate if something breaks, or if there is a

need for multiple systems. There is also the software version which will recreate the AGC based on

simulation. This solution lacks the underlying engineering and ability to easily add actual functionality

such as sensor input. My solution takes advantage of both the hardware and software implementation

by using an embedded system-on-chip. What this allows me to do is write code as if I was simulating the

AGC for some components while being able to have a physical setup for other systems, all together in

one easy to maintain file.

I chose to create my model AGC using a PSoC powered by USB attached to a computer running a

version R2010a or later of MATLAB. PSoC allows for the placement and routing of digital and analog

components as well as writing a high level code for programming the 8051 microcontroller that is built-

in. To complement the PSoC I use MATLAB for the AGC DSKY (Display and Keypad). MATLAB has a great

graphical library that allows me to create the interface (see Figure 3-2Error! Reference source not

found.) easily. Along with its extensive graphical library, MATLAB also allowed me to serially

communicate with the PSoC without difficulty.

5

3 Implementation

The Apollo Guidance Computer was a very complicated system of hardware which was a

tremendous undertaking to create.

Figure 3-1: The Original Apollo Guidance Computer

This depiction of the AGC is the finished product after almost a decade of hard work, and is the model

that I used for my Apollo Guidance Computer.

Figure 3-2: Screenshot of my AGC DSKY

6

Figure 3-2 shows the AGC interface that I created that mimics the use of the original AGC. This was

obviously not done in hardware but is a MATLAB program.

The original AGC was had its display directly connect to its core logic. With mine I decided to treat them

completely separately so to connect them I used a USB device. The very simple hardware connection is

shown below.

Figure 3-3: Physical Connection of my AGC

The USB device allowed there to be bidirectional communication between the two modules and once

connected allowed for them to act as one machine.

3.1 PSoC The PSoC side of this implementation does all of the computations and functionality of the AGC

besides the DSKY. I wanted to the display to do as little work as possible to prove how powerful the

PSoC really is. The PSoC is where the memory is stored, commands parsed and executed, and data held

to be send to the DSKY about what it should be displaying at all times. It is also the master of the

communication system.

Figure 3-4: PSoC Block Diagram

7

Figure 3-4 shows a block diagram of the functionality of the PSoC and each of the main blocks are

described below.

3.1.1 Communication

The communication system is one of the most fundamental building blocks in my

implementation of the AGC. I wanted to use some modern technology for communication between the

PSoC and another computer while keeping the code and hardware simple. I was fortunate enough to

discover that Cypress had already created a component perfect for my needs. This is the USBUART or

USB-Universal Asynchronous Receiver/Transmitter. In other words the component allows me to

communicate over a USB cable using a standard serial connection on both the MATLAB side and the

PSoC side of communication. This also the physical setup because much more simple because the PSoC

is powered through a USB cable.

3.1.1.1 Receiver

In order for my system to work the PSoC needs to be able to take in information from the DSKY in order

to execute commands. The built-in functions of the USBUART where used in order get this data, and

once the data is received it has to be parsed before attempting to execute executed. The receiver can

only hold 255 characters on a single input, but the GUI's input is always much less that the limit. The

flow chart of how the receiver works is shown below

Figure 3-5:PSoC Command Receiver Flow Chart

8

3.1.1.1.1 Parser

The parser is designed to take the string that was received by the USBUART device and be able

to separate the tokens (described in Formatted Strings) in that string. It then figures out if each token is

a value or an AGC keyword. If the token is a keyword then it stores it into a “param struct”

typedef struct param {

char type[7];

uint16 vals[6];

uint16 numVals;

} param;

Figure 3-6: Code snippet of param structure

This structure is later used to update the AGC status. The parser also has to handle weather in

input is in in octal or in decimal. The end result of all commands are in decimal so input is converted

when the user specifies that he or she wants to input in octal.

3.1.1.1.2 Multiple inputs

Sometimes it is required for the user to input a sequence of commands (a command which

enter will be passed multiple times). When this is needed, such as a memory command (See My VERB

NOUN List) the “need_more_input” field in the AGC status struct is flagged.

typedef struct AGC_Status { uint8 receiver_ready;

uint8 need_more_input; uint8 monitor; uint16 target_disp_r; uint16 VERB,NOUN,PROG,NONE; uint16 R1,R2,R3;

uint16 E[8][256]; char UPLINK[6],AUTO[6],HOLD[6],FREE[6],NO_ATT[6],STBY[6]; char TEMP[6],GIMBAL[6],PROG_IND[6],RESTART[6],KEY_REL[6];

char TRACKER[6],BLANK[6],OPR_ERR[6],VERB_TEXT[6],NOUN_TEXT[6]; char PROG_TEXT[6],ACTY_TEXT[6],COMP_TEXT[6];

} AGC_Status;

Figure 3-7: Code snippet of AGC_Status struct

This will cause the VERB indicator (see Indicators) to flash in the Seven Segment Panel to let the

user know that more input is needed. When the command has all the input it needs the flag is unset and

the VERB indicator will stop flashing.

3.1.1.1.3 Handling user input errors

Many times the user may change their mind or make mistakes while communicating with the

PSoC. When this happens the “OPR ERR” indicator on the Indicator Panel will flash. Errors that I catch

are: not enough input errors, and memory out of bounds errors (See Section 3.1.3 valid memory input).

The errors are not stored anywhere and the AGC core continues to run fine. The next command that it is

entered in should reset the error indicator.

9

3.1.1.1.4 AGC update

Once the input is parsed and stored, the AGC needs to update its status based on the user’s

request. The PSoC will process the param struct (Figure 3-6) that was created and updates the

AGC_Status struct (Figure 3-7) which is used for executing commands and building the update DSKY

string. When a command is entered that causes the AGC core to go through a long processes the AGC_

Status “receiver_ready” field will be flagged, and the PSoC will not accept any input from the keypad or

file input until it receives a transmitter enable signal. Only a couple of AGC_Status fields will be changed

based on direct user input, usually only the VERB, NOUN, and none fields, however any one of the other

fields can be changed when the PSoC actually executes the command that it received. For example then

the user enter <VERB><1><NOUN><2><ENTER> the AGC verb and noun get changed appropriately upon

being parsed, however this command will cause a number of other changes (see My VERB NOUN List).

First the “need_more_input” flag is thrown because it needs a memory address to go along with the

command. Then the next input will be stored into Register 3 (R3). Then the contents of that memory

location will be set into Register 1 (R1).

3.1.1.2 Transmitter

After the PSoC receives a command from the DSKY it goes through corresponding processes. The

process is best shown visually and is displayed below.

Figure 3-8: PSoC Transmitter Flow Chart

10

After that processes is completed, it is necessary to transmit information back to the DSKY in order for it

to update properly. The process of sending information back to the DSKY is to put the status of the AGC

into a string (see Strings from the PSoC) and then send the sting 60 characters at a time using the

USBUART. The functional blocks of this process are described below.

3.1.1.2.1 DSKY Update/AGC String Builder

Periodically we will want to update the DSKY (about every half second). In order to do this a formatted

string needs to be sent through the USB cable to the PC. The string will consist of the appropriate values

of the AGC_Status struct (Figure 3-7). This string is only built when the DSKY needs to be update. The

string that is built follows the guidelines of the communication system in Section 3.3.1 and should not

exceed 512 bytes in length (512 ASCII characters). This is a soft cut off and was created to save room

erasable memory and can be increased by a simple parameter change.

3.1.1.2.2 Sending 60 bits at a time

Once a data string has been built it needs to be transmitted to the GUI. A limitation of USBUART

device is that it can only transmit 64 bytes at a time. This caused me to create a work around described

in Section 4.2 which involved breaking down the string into 60 character lengths and sending them

separately.

3.1.2 DSKY Update

In order to be able to successfully transmit relevant data from the PSoC in an orderly fashion I

created a DSKY Update system. This system is designed to tell when the DSKY needs to be updated and

what information is actually sent. The functional blocks are described below.

3.1.2.1 Command Execution

After a command has been received and parsed, the command is always executed. This is the engine of

the AGC. It will change any or all of the statuses in the AGC_Status struct (Figure 3-7) with the

appropriate values. An example of the process the “engine” goes through when executing a command is

as follows: First the “engine” will check the current program for execution (PROG), then check the NOUN

field and see the type of command it is supposed to do, and then the VERB field will tell the AGC what

action to for the command type. Once these are deciphered a specialized simulated series of events

takes place based on which command is being executed. If a display memory command is being

executed, the AGC asks for input to R3, and flags its “need_more_input” field so the engine will know

how to respond to the following commands.

3.1.2.2 DSKY Update Interrupt

The string to update the DSKY is sent upon two conditions: if there is a counter overflow in the

DSKY Update Interrupt and either the last transmitted string was successful received by the DSKY or a

command was received. The counter is an 8 bit counter so it over flows every 256 clock cycles. The bus

clock is divided down and put into the count pin of the counter at a rate of 256 cycles/second thus

creating an over flow every second. The setup for this counter is shown in Figure 3-9.

11

Figure 3-9: DSKY Update Counter

3.1.2.3 Post Interrupt Processing

When the interrupt occurs, the string to update the DSKY will not automatically be transmitted.

Instead a flag will be thrown to indicate that the interrupt has happened. The reason for doing this is to

make sure that only one string will be sent to the DSKY at a time (see General Communication). So when

the GUI tells the AGC that it has received the last command the transmitter will send the string if the

counter has over flowed. The amount of strings sent is stored in the memory of the AGC and can be

displayed or even changed using the memory commands (see My VERB NOUN List).

3.1.3 Change Orbit

The orbit change is command happens when a user changes the current program to program 40.

This will prompt the AGC to calculate the change in velocity that is desired on each axis. When the user

confirms the change in direction, then a countdown timer is displayed until the burn is completed. The

countdown time is displayed in R1, the desired delta in R2, and the actual delta in R3. The countdown

time is handled much like the Update DSKY Counter. The period for overflow is set for one second and

each second it counts down from a constant starting point of 150 seconds. At T=0 the ISR is shut off.

Figure 3-10: Orbit Change Countdown Timer

12

The AGC will first slowly move towards the desired delta until the tanks are settled and the user

inputs a “Go Ahead” command (Figure 6-1). At that point the thrusters will turn on and the AGC will

really start to approach the desired delta. At T = 0, difference in the desired delta and the actual delta is

displayed in R1 and program 40 is exited and it places you in program 34.

3.1.4 Memory

The memory system mimics that of the original AGC. It is setup into 8 banks of 8 bit memory

addresses creating a total addressable memory size of 2048 (0-2047). This was the erasable memory and

not the “core ropes” that the AGC had for its nonvolatile memory. I did not see the need to have the

“core ropes” because of the implementation path that I took. PSoC's have their execution code written

into their nonvolatile memory already so I did not have to implement that part of the AGC.

The memory was stored as part of the AGC_Status struct and was pre-allocated to be the

appropriate size. For the ease of coding and conception I chose a type of unsigned sixteen bit integer.

The input memory address is the same as if the user is entering a 12 bit address. The PSoC breaks down

the address into a bank (0-7) and a bank offset (0-255). See the commands in My VERB NOUN List and

examples in Section Data Strings for details about modifying the memory. The memory system thus was

implemented in octal (0-377) size banks but could be used as decimal addresses based on user input

(see Section 3.2.2 for user input information).

3.1.5 System Time

One key operation of the AGC is the system time. The system time is set to be default value of 0

hours, 0 minutes, 0 hundredths of a second at start up. Although the time of the AGC can have a

granularity of hundredths of a second my implementation of the PSoC will only update the DSKY about

every second. Since there was no real need to implement a solution that would hog processing time in

hundredths of a second, I chose to use PSoC's RTC (Real-Time Clock) which works by a 32.768 kHz, 1

pulse per second interrupt.

This implementation also makes it extremely easy to update the appropriate registers when the

time needs to be displayed because it already breaks down the hours, minutes, and seconds. When the

time does need to be displayed, R1 will contain the hours, R2 will hold the minutes and R3 the

hundredths of a second. The time can be set as well for a more practical application than time since

start up. See commands in Data Strings.

3.2 MATLAB The main functionality of MATLAB is to serve as a slave to the PSoC. It was designed to do no

computations and for the PSoC and so that the PSoC can run independent of the DSKY. When the DSKY

is running then its function is to show the user what the PSoC is doing and to send commands. The look

of the DSKY is supposed to replicate that of the original AGC and the look and feel are very similar

(Figure 3-2). In order to function properly the DSKY was broken down into the structure shown below.

13

Figure 3-11: MATLAB Block Diagram

3.2.1 Seven Segment Displays

One of the most challenging features of the DSKY was the 7-segment display functionality.

MATLAB has no font or built-in functions that would give a look anywhere close to a 7-segment display. I

had to create each 7-segment element separately using lines that can be scaled to any size based on the

axis you’re trying to create and have their color be based on the value that is passed into it. I use the

same A-G on-off system that a hardware 7-segment display would use. Stringing any number of

segments together can create groups of 7-segment displays. Once these were created they were put in

the same order as the original AGC’s. There is labeled sections for the current program, verb, and noun,

and the three unmarked section are the three registers: R1, R2, and R3, which are central registers for

computations.

3.2.2 Keypad panel

The display of the keypad panel was done using regular MATLAB buttons and a single callback

function on every button. The button pressed function has the responsibility of keeping track of the

ongoing input string and also a “focus string” that is used to update the correct 7-segment display

group. It also is responsible for sending the input string to the PSoC once the Enter key is pressed on the

DSKY.

There are some buttons that have not obvious functions. First is the PRO key. This button is the

only button that does not require an “Enter press” in order to be transmitted. This key will tell the AGC

to increment its current memory address. Another key worth noting is the CLR key. This key will clear

14

the input string on the DSKY but does not have an effect on the AGC. Lastly the RSET button will put the

AGC back into its original startup state.

3.2.3 Indicator Panel

The indicator panel’s main job is to notify the user of what is going on inside the AGC visually. It

does so by using a three state system, which is selected during parsing: on, off, and flash. The indicators

accept their state by setting their “UserData” field during parsing and will display that status during the

next Flash Timer function call. There was not a need to use all of these indicators and only “UPLINK

ACTY”, “OPR ERR”, “RESTART”, and “VERB” is used even though the rest do work.

3.2.4 Flash Timer

The flash timer basically acts as an interrupt in MATLAB and is executed once every half second.

This will go through all the indicators and change their background colors based upon their status.

3.2.5 Communication

Since the USBUART is installed as a serial connection to the PC MATLAB's built-in serial function

can and is used. When the user asks requests a connection to the PSoC MATLAB will open the given Com

port. Once this Com port is open data can easily be transmitted bi-directionally between the PSoC and

the AGC.

3.2.5.1 Receiver

The DSKY’s receiver will read any incoming data on the serial object and try to update each of its

components. The functional blocks to do this are described below.

3.2.5.2 Read timer

The read serial timer is implemented in the same way the Flash Timer was. I specified a time of

.3 seconds between each interrupt, but this can be any number with the communication system

described in General Communication. When the interrupt happens the code will check to see if there is

any information available in the buffer and if there is it will parse the data that it received.

3.2.5.3 Parser

Once data is received in the timer it will be parsed. The parsing has two huge effects on the

system. It sets up flags for the DSKY to appropriate properly and it also does a real time update of each

of the GUI components. There is a special flag for the “focus” of the AGC. This flag will tell the DSKY

which element the AGC wants the value to be entered into. In effect the function of the focus string is to

clear a 7-segment group before input and update that group as information is put in. For example, if the

focus is on R3 then the bottom line of the Seven Segment Panel will set to be blank. The parser also

handles keypad input sequence to overwrite the AGC data to keep the displays updated with the proper

information.

3.2.6 Transmitter

Just as MATLAB receives all commands serially it also transmits them through the same medium

serially. MATLAB makes this communication very easy because of all its built-in functions. The “fprintf”

15

function will send a string through any serial connection. And since the commands coming from the

DSKY are always short there is no special precaution that needs to be taken to ensure the PSoC can

handle the amount of data the DSKY transmits.

3.2.6.1 Keypad Input

The standard way for the DSKY to communicating is through the keypad panel. All of the buttons

that the user presses will be stored into a string that will send upon “Enter” being pressed. This string is

sent using the already open connected serial object.

3.2.6.2 Send file of commands

If there is a sequence of commands that the user needs to do regularly and does not want to

take the time to press the buttons for a long sequence there is an easy way to do so using the send file

off commands feature. The user can create a file that follows the communication rules in Formatted

Strings and save it as a .AGC and send that file through the system. This is especially useful in debugging.

Some debugging command sequences are listed in Data Strings.

The way that I chose to do this is unique in some respects. Because I do not have a version of

MATLAB that supports threading easily, I decided to make yet another timer. This timer will run a

function that checks to make sure that the GUI is not in the middle of processing received data and that

the PSoC is ready to receiving data. If all this is true then the script will run and send a line of the .AGC

file to the PSoC. This process will repeat every .5 seconds.

3.2.7 Logger

It became very important to me as I was making the system more complex to know what

commands were entered and what the PSoC was returning to me. Thus the logger was created. The

logger simply takes all input and outputs and puts them into a .log file based on the date and time the

DSKY was started. An example of a log file can be seen in Log Capture.

3.3 General Communication A large portion of this project deals with how the two computers communicate. Because of this I

had to define a good communication schema for the system to operate properly. My scheme is very

simple to use and understand and its result is a synchronous communication system between the DSKY

and PSoC.

3.3.1 Formatted Strings

First I define the format for the strings themselves to be sent as starting with a “<” and ending

with a “>”. These two delimiters are the foundation of how each receiver parses the data. Second I

decided to deal with all capital letters so not to even have to worry about ignoring a case in code. I also

decided that the PSoC could never send more than one command to the DSKY without getting

confirmation that the first message was received. You can send more than one command from the GUI if

you would like but the PSoC will only handle one at a time. I created two types of strings: data and

other. Data strings will always consist of a set of keyword value combinations followed by a terminating

token, which I will discuss a little later.

16

A keyword is a word that a parser is programmed to look for. Keywords are defined as being a

string of characters of a size no larger than 6. A value is zero to six tokes that contain data about the

keyword. An example a data string is <VERB><25><NOUN><36><ENTER>. This contains two keywords

each with one value and is terminated by “ENTER”. To see more data strings and explanations please see

Data Strings.

There are also several non-data strings that can be sent. These are tokes like “RSET”,

“RECEIVED”, “CLOSE”, and “READY”. All of these happen to be only sent from the DSKY and not from the

PSoC itself. As I will discuss here, there are some major differences between how MATLAB will send

information and how the PSoC will transmit.

3.3.1.1 Strings from the DSKY

Transmitting from the DSKY has much more stringent rules than the general ones outlined

above. The reason for this is the complexity of parsing in C code compared to the MATLAB. To make

things as simple as possible I used the following extra criteria. Every value token is not to have a value of

greater than one digit long. In the example above I showed a value token of 25 and 36, this would not be

acceptable for the DSKY to send, but instead it would have to send “<VERB><2><5>...”. When the DSKY

transmits a data string it also must be terminated with the “ENTER” string. The other major difference is

that the DSKY must respond to everything that the PSoC has sent with a “<RECEIVED>” string or another

command to execute. If it fails to send confirmation or the program closes the PSoC will continue to with

whatever process it is doing without updating the DSKY.

3.3.1.2 Strings from the PSoC

The PSoC can send data strings that look like “<VERB_TEXT><FLASH><NOTREADY>”. This seems

to break many rules of the DSKY string design but is a perfectly legal string. I added additional

informative terminators to the strings that MATLAB can receive. For example the “NOTREADY” and

“READY” strings. These strings, in addition to telling the DSKY that the command is done processing, also

tell MATLAB whether or not the AGC will accept any user input. When the DSKY receives a NOTREADY

command it will not send any information to AGC and block file sending commands as well as the

keypad panel. Lastly the PSoC data string is much larger than the DSKY data string because the PSoC

data string will tell MATLAB the status of every one of the dynamic components on the interface. The

“VERB_TEXT” token in the example above is the text right above the verb 7-segment display group.

17

4 Testing

4.1 Testing for Independence The PSoC needs to work independently of the DSKY running on a PC. In order to test its

functionality the DSKY was closed while the AGC was in monitor mode. More specifically the AGC was

monitoring a changing memory element (see My VERB NOUN List). If the PSoC was running

independently from the PC (other than power) then when the DSKY is closed down in this situation and

then opened again up later, the value for the memory element should be continuously changing once

the connection is established again.

4.2 Testing the Communication System The communication system was the most important piece that needed to be fully operational

before I could proceed with the other features of the AGC. It was a multistage process, which took the

largest amount of time to complete.

4.2.1 Testing the Initial Serial Communication Link

I have never taken a formal class on C coding before so naturally testing how my code parsed a

data string described in Formatted Strings, took me quite some time. I did not want to try and create the

parser from scratch on the PSoC’s microcontroller itself because that would require many other details

to be worked out before I could test for success. My testing began with printing out each keyword that I

found and its corresponding values. Then I created a struct (Figure 3-6) that would hold the values. I

found that I had no clue about how to use structs properly nor did I know how to allocate the memory

for strings to be stored. After much research I was able to create a struct from a data string and could

easily add or remove keywords from parser.

Once I had this working successfully on a PC I tried to port it over to the PSoC itself. The biggest

obstacle that I faced was that on the embedded system there was no “malloc” function, which

dynamically allocates memory for the struct that I created. I was forced to figure out how to pre-allocate

the memory properly and then tested.

To test it on the PSoC was a little more challenging because I need to send data strings from a

serial terminal and be able to receive them as well. I now would have to read the data in successfully

from the USBUART and pass it into the parser, reconstruct the string from struct that the parser created

and then send it back using the USBUART. This caused one major issue that forced me to learn more C

code. The issue was the fact that at most the USBUART could receive 255 characters and only send 63 at

a time. I missed this detail in my initial testing for serial communication because I was sending short

strings. I fixed the problem by breaking down the strings being sent from the PSoC into sectors of no

larger than 60 characters. Because of my lack of knowledge at the time of the whole communication

system later testing had to be done in the DSKY testing.

18

4.3 Testing the DSKY The DSKY was fun and easy to test because of my familiarity with MATLAB and the instant

gratification that comes from being able to visualize the results.

4.3.1 Testing the Seven segment displays

The seven segment displays were very easy to test because of how I implemented them (see

Seven Segment Displays). I created blank figures and placed multiple 7-segment display groups on them

of various sizes. I changed their value to both a string or an integer and both work fine. There were no

major issues during testing.

4.3.2 Testing the Keypad Panel

The keypad panel is based around the values that are being displayed in each button. The

display value will also serve as an identifier and the eventual sending string when the DSKY is connected

to the PSoC. What I did to test this initially was to create a callback function for the button press action.

Based around the button pressed I would build a string. Once I hit ENTER I would display the string in

MATLAB. I would then go into a terminal and paste the string and send it serially to the PSoC and make

sure that all of my “keywords” on the keypad match up perfectly with the keywords the PSoC was

expecting.

4.3.3 Parser

The parser was created to accept input from the PSoC and be able to update the DSKY based on

what the PSoC told it to (see Parser). There is one big problem with the parser though, updating all the

fields every time it receives a status string. This is a problem because, for example, what if the DSKY

receives an update data string from the PSoC and the user is actively entering data that will be

transmitted (Transmit only happens on an ENTER press). The user-entered data will not be displayed on

the screen because it has been written over by the parser. This is where the parser functionality also

proposes a great solution to its own problem. The parser is setup in such a way where it can take not

only in the input from the AGC but also input from the keypad. So if we just parse the keypad results

after we parse the received data the display updates fine. This was also used to test the naming of the

components compared to what the PSoC’s stored value for the names was. If something was not named

correctly the PSoC data string would not match anything and no update would occur.

4.3.4 Indicators

The indicators were also very easy to test. They work based off of a timer that will go and

update their background periodically with what the status of the AGC is. They have three states they can

be in: on, off, or flashing. I changed all of their statuses and observed them change states. I also got to

test this using the PSoC update data string by forcing the PSoC to send flash commands to some of the

indicators.

4.4 Memory Memory was very easy to test as well for two reasons. First is, at the time of testing, the DSKY

system and communication systems were working so I could easily display the memory contents to is if

19

the memory was storing values properly. The other reason is because of the built-in debugging software

of PSoC Creator. This system was tested using some scripts in Data Strings and also by stepping through

code to ensure that the PSoC was using the correct bank of memory. The test scripts also tests the

memory using octal input (which is converted into decimal) and also worked properly.

4.5 Time Time was the easiest system to test and debug and actually help expose a bug I found in the

PSoC C libraries. I did two main tests on this system. First was to turn on the system, record the time on

paper, and come back a day or more later to make sure all was operating correctly. Second I entered in a

new time and then would watch how the system responded. The latter exposed a problem with the

math library on the PSoC because it would compute the function pow(10,2) to be 99 instead of 100. This

was found while converting an array of numbers into their decimal equivalent. So I created my own

“pow10” and “pow8” functions that enabled me to correctly take octal and decimal input.

4.6 Error Checking Error checking was mainly used for bad user input so it could was also tested with a script in

Data Strings. When an error occurred the PSoC would set it’s operator error status string to flashing thus

communicating with the DSKY to flash the OPP ERR indicator. This was just visually verified and

debugged when running the scripts

20

5 Evaluation

The overall project was complete as described by the proposal. Its final design was of size that is

less than one pound, a significant improve when compared to the seventy plus pounds of the original

AGC. My AGC’s cost is less than $100, which is more than two orders of magnitude less expensive than

the original.

5.1 Timeline

Figure 5-1: Senior Project Timeline

This project took me too semesters of work and was finished within the expected time period. If I were

to do this project again I would have tried to get more work done during the first semester because it

became very difficult to balance my other classes because I was spending all of my time building my

project. If I were to do it again I would have laid out more carefully the block diagrams that I was going

to build and do them earlier. Because I was not used to the technology that I used in this project (PSoC),

it made planning difficult because I did not know how to use it properly. I would have spent more time

creating miscellaneous projects that had some comparable features to the blocks of my AGC.

21

5.2 Objectives Met This project was very successful because I was able to meet my objectives. Whether or not I

was able to display the power of a PSoC as a holistic solution to many problems is not objective and is up

to the individual to decide, however I do believe this project shows off some robust and powerful

features of the technology and demonstrates the drastic differences in the technology of the two eras.

5.3 Possible Additions As I stated in the Introduction I was not able to implement all the features of the AGC, making it

very easy to find things to add onto my AGC. It would be possible for students to in the future to

continue this project as their senior project and eventually it may be completed. The main thing that I

see that could be added is the existence of onboard sensors. Sensors are one of the specialties of

Cypress and they made it very easy to attach, configure, and communicate with them. The sensors could

be used to mimic approaching the moon or even velocity.

22

6 Appendices

6.1 Data Strings

6.1.1 Memory Data Strings

Command to enter a value into erasable memory send the data string <VERB><2><1><NOUN><2><ENTER>

Then specify the address <NONE> means the input is in decimal. This will be displayed in R3 <NONE><5><2><ENTER>

Specify the value. This will be displayed in R1 <NONE><8><8><8><ENTER>

<VERB><2><1><NOUN><2><ENTER>

Specifying the address in octal by replacing <NONE> with <+> <+><1><3><7><7><ENTER>

The value can also be sent as a octal <+><7><7><7><7><ENTER>

VERB 1 is memory display command; since the previous command had NOUN 2 there is no need to enter that again <VERB><1><ENTER>

The memory address to view in decimal <NONE><5><2><ENTER>

<VERB><1><ENTER>

View what is in octal address 1377. The decimal equivalent address will be displayed in R3 and the value in memory will be displayed in R1 <+><1><3><7><7><ENTER>

VERB 11 will monitor the value of a memory address <VERB><1><1><ENTER>

This is the last address (2047) that can be specified. It holds the number of DSKY updates <+><3><7><7><7><ENTER>

6.1.2 Set time Data Strings

VERB 25 is set mode, NON 36 or 65 is a system time command <VERB><2><5><NOUN><3><6><ENTER>

Specify the hours first, this is in decimal usually. It is stored in R1 <NONE><6><9><ENTER>

Specify the minutes, they will go into R2 <NONE><5><9><ENTER>

Specify hundredths of a second, this will be stored in R3 <NONE><4><6><0><0><ENTER>

VERB 15 will put the AGC into monitor mode and thus the time will continuously update. VERB 5 would display the time at the instant that the command was received

23

<VERB><1><5><ENTER>

6.1.3 Memory and OPR ERR Test sequence

<VERB><2><1><NOUN><2><ENTER>

Specifying the address for entering a value in octal <+><1><3><7><7><ENTER>

Should flash OPR ERR due to not enough inputs because now we are viewing the system time <VERB><1><5><NOUN><3><6><ENTER>

VERB 11 will monitor the value of a memory address <VERB><1><1><NOUN><2><ENTER>

This is the last address (2047) that can be specified. It holds the number of DSKY updates <+><3><7><7><7><ENTER>

Increment the memory address. This should flash OPR ERR because it will be outside of the addressable memory <PRO><ENTER>

6.1.4 Orbit Change Sequence

Do a change program request <VERB><3><7><ENTER>

Change the program to 40 (orbit change program) <NONE><4><0><ENTER>

The display will show delta v for x, y, and z on R1, R2, and R3 Respectively, confirm them <VERB><3><3><ENTER>

Timer will start, when prompted for input confirm thruster tanks are settled and start them <VERB><3><3><ENTER>

24

6.2 My VERB NOUN List

VERB Description NOUN Description

1 Display memory contents in R1 1 Ask For Input

5 Display mode 2 Memory Command

11 Monitor memory contents in R1 36 Time Command

15 Monitor mode 65 Time Command

21 Set memory contents and display in R1 25 Set Mode 33 Confirm/Go Ahead 35 Lamp Test 37 Set Program 50 Ask For Input Figure 6-1:VERB and NOUN Commands Table

25

6.3 Log Capture 19:27:19-

>RECEIVED:<PROG><0><VERB><0><NOUN><0><R1><0><R2><0><R3><0><UPLINK_ACTY

><off><TEMP><off><AUTO><off><GIMBAL><off><HOLD><off><PROG_IND><off><FR

EE><off><RESTART><off><NO_ATT><off><TRACKER><off><STBY_IND><off><KEY_R

EL><off><OPR_ERR><off><VERBTEXT><off><NOUNTEXT><off><PROGTEXT><off><CO

MPTEXT><off><ACTYTEXT><off><READY>

19:27:19->KEYPAD:<VERB><1><1><NOUN><0><2><ENTER>

19:27:20-

>RECEIVED:<PROG><0><VERB><11><NOUN><2><R1><0><R2><0><R3><0><UPLINK_ACT

Y><off><TEMP><off><AUTO><off><GIMBAL><off><HOLD><off><PROG_IND><off><F

REE><off><RESTART><off><NO_ATT><off><TRACKER><off><STBY_IND><off><KEY_

REL><off><OPR_ERR><off><VERBTEXT><off><NOUNTEXT><off><PROGTEXT><off><C

OMPTEXT><off><ACTYTEXT><off><FOCUS><_R3><READY>

19:27:22->KEYPAD:<NONE><2><0><4><7><ENTER>

19:27:22-

>RECEIVED:<PROG><0><VERB><11><NOUN><2><R1><7><R2><0><R3><2047><UPLINK_

ACTY><off><TEMP><off><AUTO><off><GIMBAL><off><HOLD><off><PROG_IND><off

><FREE><off><RESTART><off><NO_ATT><off><TRACKER><off><STBY_IND><off><K

EY_REL><off><OPR_ERR><off><VERBTEXT><off><NOUNTEXT><off><PROGTEXT><off

><COMPTEXT><off><ACTYTEXT><off><READY>

19:27:23->SENT:<RECIEVED>

19:27:23-

>RECEIVED:<PROG><0><VERB><11><NOUN><2><R1><8><R2><0><R3><2047><UPLINK_

ACTY><off><TEMP><off><AUTO><off><GIMBAL><off><HOLD><off><PROG_IND><off

><FREE><off><RESTART><off><NO_ATT><off><TRACKER><off><STBY_IND><off><K

EY_REL><off><OPR_ERR><off><VERBTEXT><off><NOUNTEXT><off><PROGTEXT><off

><COMPTEXT><off><ACTYTEXT><off><READY>

19:27:24->SENT:<RECIEVED>

19:27:24-

>RECEIVED:<PROG><0><VERB><11><NOUN><2><R1><9><R2><0><R3><2047><UPLINK_

ACTY><off><TEMP><off><AUTO><off><GIMBAL><off><HOLD><off><PROG_IND><off

><FREE><off><RESTART><off><NO_ATT><off><TRACKER><off><STBY_IND><off><K

EY_REL><off><OPR_ERR><off><VERBTEXT><off><NOUNTEXT><off><PROGTEXT><off

><COMPTEXT><off><ACTYTEXT><off><READY>