apollo guidance computerunh.edu/ece/department/senior projects/ece792_2011... · 2018. 8. 31. ·...
TRANSCRIPT
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>