Embedded Systems Projects With An TI Cortex M Arm Based Microcontroller Board, online course from University of
Texas at Austin and EdX
Link to embedded systems class files
Each lab completed first in simulation and then on
the real "Launch" board, using the Keil tools.
Topics (More Details Follow Topic List) of Labs to Review
Embedded Systems while not working, the area I had worked
in for 18 years.
- Ultimate Goal of course was to have an small systems
approach to game design, to design and test a
retro-hand-held-vide-game, integrating all labs from the
class into this final thing, which was optional, and in
the process, learn about microcontrollers. I opted to do
all the labs, but have not yet put them all together
into this form. I have an example of what it would be
like if I did.
- ADC (Analog to Digital Conversion) and Data
Acquisition: We developed a system that inputs an analog
signal with an analog to digital converter within the
microcontroller.
- We developed a simple autonomous robot that used two
DC motors and two distance sensors.
- We designed and tested a position measurement system,
with analog to digital conversion and calibrated
output.
- DAC (Digital to Analog Conversion) and Sound: We
developed a system that outputs an analog signal with an
R-2R digital to analog converter.
- We design and tested a digital piano, with 4 inputs,
digital to analog conversion, and sound.
- Interrupts: We developed a system that outputs a
square wave using interrupts, followed by developing a
system that inputs from a switch using interrupts.
- We developed a system that outputs to a DC motor using
pulse width modulation.
- We designed and test a guitar tuner, producing a 440
Hz tone.
- UART (Universal Asynchronous Receiver Transmitter) -
The Serial Interface and I/O Synchronization: We
developed a communication network using the serial
port. We Wrote C code to output decimal and fixed-point
numbers to the serial port.
- Finite State Machines: We developed a simple vending
machine using a finite state machine.
- We developed a stepper motor robot using a finite
state machine. We interfaced 3 switches and 6 LEDs and
created a traffic light finite state machine.
- Arrays and Functional Debugging. We developed a
system that debugs by dumping data into an array. We
Wrote C functions using array data structures that
collected data to debug our system.
ADC (Analog to Digital Conversion) and Data
Acquisition Project Labs
- a system that inputs an analog signal with an analog
to digital converter
- an autonomous robot that uses two DC motors and two
distance sensors
- a test and position measurement lab, with analog to
digital conversion and calibrated output
ADC Software Trigger Example:This class example
demonstrated the 4 steps of analog to digital
conversion:
ADC Software Trigger 4 Steps (Analog to
Digital):
Link
to embedded systems class files for the Software Trigger 4
step lab for Analog to Digital Conversion
- initiate conversion (software trigger)
- wait for the ADC to finish
- read the digital result
- clear the completion flag.
Successive Approximation - Microcontroller's
best method for designing ADC
- The most pervasive method for designing the ADC in
this microcontroller is successive approximation.
- A 12-bit successive approximation ADC is clocked 12
times.
- At each clock another bit is determined
starting with the most significant bit.
- For each clock, the successive approximation hardware issues a
guess on Vdac by sitting the bit under test to 1.
- If Vdac is then higher than the input bit Vin, then the
bit under test is cleared.
- If Vdac is less than Vin then the bit under test
remains 1.
Wall follower ADC class example:
Link
to embedded systems Robot Wall Follower Example Lab Files
- used SysTick interrupts to implement a software PWM
(pulse width modulator) to drive two DC motors at
variable duty cycles.
- Two analog IR (InfrRed) distance sensors: used to
allow the robot to follow a wall. The two IR sensors
are mounted looking forward to the left and forward
to the right. The goal is to control power to each
wheel so the left and right distances to the walls are
equal.
- A third IR sensor looks directly forward to
attempt to avoid a head-on collision. If an object
is detected too close to the front of the robot,
both wheels are immediately stopped.
--TOPWALL------direction-of-motion-of-sensor-bump-into--TOPWALL--then-reverse-direction
"----------/"
"---------/"
"--------/"
"-------/"
"------------------"
"|-----------------|"
"|-ROBOT------|--->direction of motion and third sensor"
"|-----------------|"
"------------------"
"-------\"
"--------\"
"---------\"
"----------\"
--BOTTOMWALL------direction-of-motion-of-sensor-bump-into--BOTTOMWALL--then-reverse-direction
Potentiometer transducer--Distance Meter--Measurement
of Distance: 7 objectives of lab:
Link
to embedded systems Potentiometer Transducer Distance
Measure Lab Files
What we Learned from This Lab Project
- intro. to sampling analog signals using the ADC
interface
- development of ADC device driver
- learning data conversion and calibration
techniques
- the use of fixed-point-numbers, which are integers
used to represent non-integer values
- development of an interrupt-driven real-time
sampling device driver
- development of a software system using multiple
files
- learn how to debug one module at a time
How We Used Potentiometer, Resistance and the
microcontroller SysTick interrupt to convert analog sample
to distance:
- A linear slide potentiometer converts distance into
resistance "(0 <= R <= 10 kiloOhms)". The software uses
the 12--bit ADC in microcontroller sampled at 40 Hz using
SysTick interrupts. A function converts the ADC sample
into distance: units of 0.001 cm.
- Data stream: will be passed from the ISR (interrupt
service routeine) into the main program using a mailbox,
and the main program will output the data on a
display.
- Microcontroller ADC: input from potentiometer: converts
the input voltage to a number from 0 to 4095. The ADC
is a successive approximation device with a conversion
time on the order of several microseconds.
- Software: calculates distance with a resolution of
0.001 cm.
- Position measurements: should be displayed on the Nokia
display through UART0. A periodic interrupt can be used
for the real-time sampling.
- Distance resolution: smallest change in distance that
the system can reliably detect. Resolution depends on
electrical noise, number of ADC bits, and the resolution
of the output display software. Accuracy is defined as
the absolute difference between the true position and
the value measured by the device.
- The armature is defined as the part that moves, and in
this lab we were measuring the position of the armature,
which in this lab is the slide potentiometer.
DAC (Digital to Analog Conversion and Sound)--an R2R DAC 3-bit desgin example:
In this class example, we created a sine wave analog
output from digital inputs using an R2R 3bit design for
the Digital to Analog (DAC)
conversion.
Link
to embedded systems Lab Files, and R2R Digital to Analog
Conversion and Sound, a 3 bit design example
- We had to generate a 100 Hz sine wave whose table size
was 16 entries of integers that when sent to the output
port would create the various levels of the sine wave,
so we needed a 100Hz*16 = 1.6 kHz interrupt.
- Each time the SysTick interrupt handler was run it
output one of the 16 voltage levels that created the
output sine wave.
- The bus is 80MHz, so SysTick period was
80000kHz/1.6kHz = 50000 for the sine wave.
- Each time the switch was pressed, it either activated
playing this 100Hz sound wave, or stopped it.
Digital Piano Example using Digital to Analog
(DAC):
The 3 objectives were to:
- learn about DAC conversion
- learn how digital data stored in a computer could be
used to represent sounds and music
- study how the DAC and interrupts can be used to create
sounds
The lab created a 4 note output digital piano. The DAC
is 4 bits, but the example we did in class was 3 bits.
Interrupts: Softsound Example
This class example used the SysTick timer to request
interrupts at 500Hz. It helped prepare us to do the
tuning fork example at 440 Hz.
Link
to embedded systems class Files, Softsound Example
Tuning Fork Example with interrupts:
The square wave sound is 440 Hz, a standard frequency
made by a tuning fork. A positive logic switch was the
input, and headphones were used as an output. A resistor
placed in series with the output to the headphone speaker
controls the loudness (larger resistor, quieter sound, but
never go off).
Link
to embedded systems lab files, Tuning Fork Lab
- Pressing the switch: the square wave sound begins, press
it again, it stops. When the output was oscillating, the
period was 1/440 sec = 2.2727ms, so interrupt at 1/880 Hz
= 1.13636 ms.
- The time "t" between touching a switch and the change in
output need not be immediate, as long as the toggling
begins before the next SysTick interrupt.
- The resistance of the headphones is 32 ohms, and Power
(P) = Volts (V) * Current (I), and the output high voltage
is 3.3 volts, and the in series resistor from the output
to the headphones is 1500 ohms.
- So the current delivered to the headphones was: I = 3.3 /
(1500 + 32) Amps.
- The power delivered to the headphones should be less than
1 milliwatt, and with P = I**2 * 32 ohms, with R = 1500
ohms, the power delivered = 0.15 mW.
- Sound was created only when the voltage across the
speaker oscillated.
- The frequency of the oscillation will determine the pitch
of the sound.
- Frequency 440 Hz: note A, above middle C on the piano.
- To output silence, it requires less energy to leave the
output low.
- An unchanging output results in no sound from the
speaker, but it also requires current to flow through the
electromagnet in the speaker.
- The PLL(Phase Locked Loop): runs at 80 MHz. With the
SysTick interrupt, we found that timing was more accurate
than software loop delays, and creating the 440 Hz wave
with the 880 Hz interrupt worked better.
- SysTick interrupt service routine: looked at the state of
switch and tracked whether the switch was pressed during
the previous ISR service to know whether to toggle or
quiet the output.
- We checked the output wave period as 1000 ms for one
toggle cycle (high and low) divided by 2.272 ms = 440 Hz
wave form to speaker to make sound.
Pulse Width Modulation:
Link
to embedded systems class example files, using Sys Tick
Interrupts to implement software Pulse Width Modulated
output (PWM) to drive a DC Motor at a given duty cycle
- This class example used SysTick interrupts to implement a
software pulse width modulted output (PWM) to drive a DC
motor at a given duty cycle. The builtin button switch1
(SW1) increases the speed, and switch2 (SW2) decreases the
speed.
- Developed a system that outputted to a DC motor that uses pulse
width modulation. We designed and tested a guitar tuner,
producing a 440 Hz tone.
Edge Interrupts Example:
This class example demonstrated how to use the microcontroller board
builtin switch button to create a falling edge interrupt.
Link
to embedded systems class example files, on Edge Interrupts
Periodic SysTick Interrupts: This class
example used the SysTick timer to request interrupts at a
particular period.
Link
to embedded systems class example files, on Periodic Sys Tick Interrupts
Phase Lock Loops (PLL): A software function to change
the bus frequency using the PLL:
Link
to embedded systems Lab Files, Phase Lock Loop (PLL)
- Being able to dynamically control bus frequency and
I/O devices is important for low-power design.
- The execution speed of a microcontroller is determined
by an external crystal.
- The microcontroller board we used had a 16 MHz
crystal.
- Most microcontrollers include a phase lock loop (PLL) that
allows the software to adjust the execution speed of the
computer.
- Typically, the choice of frequency involves the
tradeoff between software execution speed and electrical
power.
- In other words, slowing down the bus clock will
require less power to operate and generate less
heat.
- Speeding up the bus clock obviously allows for more
calculations per second, at the cost of requiring more
power to operate and generating more heat.
- The default bus speed for the microcontroller internal
oscillator is 16 MHz ±1%.
- The internal oscillator is significantly less
precise than the crystal, but it requires less power and
does not need an external crystal.
- If we wish to have accurate control of time, we will
activate the external crystal (called the main
oscillator) to use the PLL to select the desired bus
speed.
- There are two ways to activate the PLL. We could call
a library function, or we could access the clock
registers directly.
- To save power, we slow down the bus frequency removing
as much of the wasted bus cycles while still performing
all of the required tasks. For battery-powered systems
the consumed power is a critical factor.
SysTick Timers and their accuracy:
Link
to embedded systems class example files on Sys Tick Timers
- The accuracy of SysTick depends on the accuracy of the
clock.
- We use the PLL to derive a bus clock based on the 16
MHz crystal, the time measured or generated using
SysTick will be very accurate.
- More specifically, the accuracy of the NX5032GA
crystal on the LaunchPad board is ±50 parts per million
(PPM), which translates to 0.005%, which is about ±5
seconds per day.
- One could spend more money on the crystal and improve
the accuracy by a factor of 10. Not only are crystals
accurate, they are stable. The NX5032GA crystal will
vary only ±150 PPM as temperature varies from -40 to
+150oC.
- Crystals are more stable than they are accurate,
typically varying by less than 5 PPM per year.
- We learned how to implement time delays based on
SysTick. The RELOAD register is set to the number of bus
cycles one wishes to wait. If the PLL function has been
executed, then the units of this delay will be 12.5 ns.
Writing to CURRENT will clear the counter and will clear
the count flag (bit 16) of the CTRL register. After
SysTick has been decremented delay times, the count flag
will be set and the while loop will terminate. Since
SysTick is only 24 bits, the maximum time one can wait
with SysTick_Wait is 224*12.5ns, which is about 200
ms.
- To provide for longer delays, the function
SysTick_Wait10ms calls the function SysTick_Wait
repeatedly. Notice that 800,000*12.5ns is 10ms. What
is the longest time one could wait using
SysTick_Wait10ms? The maximum delay is 232 * 10ms,
which is about 500 days.
Finite State Machines (Mealy and Moore):
- To Introduce Finate State Machines:
- We learned to use the static timer to get precise
delays.
- Precision like this is required in real time
systems where not meeting delays can have
consequences, ranging from minor inconveniences to
serious catastrophes (air traffic control, nuclear
power plants, anti-lock brakes in a car,
etc).
- We learned to build an abstraction called a finite
state machine which makes as a design, complex
systems using a simple abstraction that lends itself
to probability of function.
- FSMs are a design process that is easy to verify
and has a set of theory behind it.
- The same engine we build for one FSM can be used
no matter how complex the system is.
- An FSM is a 5-tuple: sets of: inputs, outputs,
states, transitions (STG = state transition graph,
and a matrix can be used too), and output
determination.
- The Moore FSM was the focus for this class, where the
next state is a function of current state and input,
and the output is a function of the current
state.
- Mealy machines are not covered in this class, but
their output is a function of the current state and
the input.
- Odd Ones Detector Finate State Machine:
(introductory example)
Link
to embedded systems Lab Files, Odd Ones Detector Finite
State Machine
- For the odd ones detector shown in the code link,
the input is a bit, either one or zero, as is the
output.
- There are 2 states, even and odd.
- When in even state and input = 1, you go to odd
state where output = 1.
- When in even state and input = 0, we stay in even
state and output = 0.
- When in odd state and input = 1, you go to even
state and output = 0.
- When in odd state and input = 0, you stay in the
odd state and output = 1.
- This is a very, very simple Moore FSM to
demonstrate the concept.
- The time delay is 1 sec. spent in each
state.
- Traffic Light Controller Finite State Machine
(FSM) First Example
Link to
embedded systems class files for the Traffic Light
Controller Class Example Finite State Machine
- We designed a traffic light controller for the
intersection of two equally busy one-way
streets.
- The Solution: The intersection has two one-ways
roads with the same amount of traffic: North and
East.
- We begin the design defining what constitutes a
state.
- In this system, a state describes which road has
authority to cross the intersection.
- The basic idea, of course, is to prevent
southbound cars to enter the intersection at the
same time as westbound cars.
- In this system, the light pattern defines which
road has right of way over the other.
- Since an output pattern to the lights is necessary
to remain in a state, we solved this system with a
Moore FSM.
- It had two inputs (car sensors on North and East
roads) and six outputs (one for each light in the
traffic signal.)
- The six traffic lights were interfaced to Port B
bits 5–0, and the two sensors are connected to Port
E bits 1–0:
- PE1=0, PE0=0 means no cars exist on either
road
- PE1=0, PE0=1 means there are cars on the East
road
- PE1=1, PE0=0 means there are cars on the North
road
- PE1=1, PE0=1 means there are cars on both
roads.
- The next step in designing the FSM was to create
some states.
- We created decision rules defining what to do for
each possible input and for each state.
- For this design we listed heuristics describing
how the traffic light was to operate:
- If no cars are coming, stay in a green state,
but which one doesn’t matter.
- To change from green to red, implement a
yellow light of exactly 5 seconds.
- Green lights will last at least 30
seconds.
- If cars are only coming in one direction, move
to and stay green in that direction.
- If cars are coming in both directions, cycle
through all four states.
- Vending Machine Finite State Machine
(FSM):
Link to
embedded systems class files for the Vending Machine Finite State Machine
- This section uses a function
variable.
- For example we defined function variables in this format:
"void (*functionPt)(void);"
- The design goals were as follows: design a
vending machine with two outputs (soda, change)
and two inputs (dime, nickel).
- Our Solution: This vending machine example
illustrates additional flexibility that we built
into our FSM implementations.
- Rather than simple digital inputs, we created
an input function that returned the current
values of the inputs.
- Similarly, rather than simple digital outputs,
we implemented general functions for each
state.
- This approach provided an alternative
mechanism when the input and or output
operations become complex.
- Our simple vending machine had two coin
sensors, one for dimes and one for
nickels.
- When a coin fell through a slot in the front
of the machine, a light from the sensor reflected
off the coin and was recognized back at the
sensor.
- An op amp created a digital high at the Port B
input whenever a coin was reflected.
- So as the coin passes the sensor, a pulse (V2)
was created.
- The two coin sensors were inputs to the
FSM.
- If the digital input was high (1), that meant
there was a coin currently falling through the
slot.
- When a coin was inserted into the machine, the
sensor went high, then low.
- Because of the nature of the vending machines
we assumed there cannot be both a nickel and a
dime at the same time.
- This meant that the FSM input could be 0, 1,
or 2.
- To implement the soda and change dispensers,
we interfaced two solenoids to Port E.
- If the software made PE0 high, waited 10ms,
and then made PE0 low, one soda was
dispensed.
- If the software made PE1 high, waited 10ms,
and then made PE1 low, one nickel was
returned.
- Engine Control Mealy Type Finite State
Machine (FSM):This used a pointer
implementation of a Mealy finite state machine to
operate an engine with a control input, gas and
brake outputs, and two states.
Link to
embedded systems class example files for the
Engine Control Finite State Machine
- Finite State Machine (FSM) Used to Control
a Stepper Motor to a Robot: This is what we
learned from this class example.
Link to
embedded systems class example files for the Stepper Robot Finite State Machine
- A motor can be evaluated in terms of its
maximum speed (RPM), its torque (N-m), and the
efficiency in which it translates electrical
power into mechanical power.
- Sometimes however, we wish to use a motor to
control the rotational position "(θ=motor shaft
angle)" rather than to control the rotational
speed "(ω=dθ/dt)".
- Stepper motors are used in applications where
precise positioning is more important than high
RPM, high torque, or high efficiency.
- Stepper motors are very popular for
microcontroller based embedded systems because
of their inherent digital interface.
- In this design, the first button made it spin
one way, and the second button made it spin the
other way, and the third button made it step
just once.
- If both of the first two buttons were pressed,
it wiggled back and forth.
- Traffic Light Finite State Machine (FSM):
second example:
Link to
embedded systems class files for Traffic Light Finite State Machine
- This lab demonstrated how to design a Moore
FSM based on lecture examples to control a
traffic light.
- The microcontroller had 3 input sensors, one
each indicating cars on the east to west and
north to south roads, and one for a
pedestrian.
- There were 8 output LEDs, 3 each for the
traffic lights for the east to west and north to
south roads, and one each for the walk and don't
walk signals.
- There were 9 states with each output wait time
0.5 seconds.
- Cars were not allowed to crash, and when the
don't walk signal flashed on and off, the
pedestrian knew to hurry up and cross.
- When don't walk did not flash pedestrians knew
not to cross.
- Pedestrians were not allowed to cross when
cars were present on either road.
- If all 3 sensors were on, an output pattern
was output to the LEDs for 20 seconds.
- The system had input independence since each
state had 8 arrows to the next state, depending
on the input and current state.
- A Moore machine was used since the LED output
pattern was based on what state you were
currently in.
Arrays and Functional Debugging:
Developed a system that debugs by dumping data into
an array.
Link to
embedded systems class files for Arrays and
Functional Debugging Lab
UART (Universal Asynchronous Receiver
Transmitter),The Serial Interface, I/O:
Link to
embedded systems class files for UART Serial Interface Example
- UART Network Tool Example:
Synchronization:
Link to
embedded systems class files for UART Network Tool Example
- The class developed a communication network
between 2 LaunchPad boards over the UART
channels.
- The switches were inputs, LEDs were outputs,
and UARTs were used to communicate.
- Information was encoded as colors on the
LEDs.
- There were 5 questions with each question
associated with one of the 5 colors.
- There were 3 answers to these questions
associated with 3 other LED colors.
- Lessons Learned: A communication network
includes both the physical channel hardware and
logical procedures and software that allow users
to communicate with each other.
- The network provides the transfer of
information as well as the mechanism for process
synchronization.
- When faced with a complex problem, one could
develop a solution on one powerful and
centralized computer system.
- Alternatively, a distributed solution could be
employed using multiple computers connected by a
network.
- The processing elements of a distributed
system may be a powerful computer,
microcontroller, an application specific
integrated circuit (ASIC) or a smart sensor and
actuator.
- Distributed processing places input, output
and processing at multiple locations connected
together with a network.
- There are many reasons to consider a
distributed system network over a centralized
solution.
- Often multiple simple microcontrollers can
provide a higher performance at a lower cost
compared to one computer powerful enough to run
the entire system.
- Some embedded applications require input and
output activities that are physically
distributed.
- For real time operation, there may be not
enough time to allow communication for a remote
sensor and a central computer.
- A distributed system can often be deployed and
scaled.
- If complexity increases, you can add a network
node, and vice versa.
- Nokia 5110 Display Class Example Using
UARTS:
Link to
embedded systems class files for UART Nokia 5110
Display Class Example
- This code wrote a series of images and text to
the Nokia 5110 84x48 graphic LCD.
- We were told not to drive the backlight with
5V sinec it would smoke. However, the backlight
on the LCD seemed to be happy with direct drive
from the 3.3V regulator. Although the PCD8544
controller datasheet recommended 3.3V, the
graphic Nokia 5110 LCD can run at 3.3V or
5V.
- No resistors were needed on the signal lines.
We needed 5 signal lines to connect to the LCD,
3.3 or 5V for power, 3.3V for LED backlight, and
1 for ground.
- UARTs Lab: Universal Asynchronous Receiver
Transmitter: read in a number, converted it to
ASCII, and sent it to a display connected to the
UART.
- Lessons Learned: Serial Interface and
UARTs Lab Functions: UART Universal Asynchronous
Receiver Transmitter serial interface.
Link to
embedded systems class files for UART Lab
- A UART input function accepted ASCII characters
from the serial port and adds them to a string
until "enter" is typed or until max length of
the string was reached.
- It echoed each character as it was inputted.
If a backspace was inputted, the string was
modified and the backspace was echoed. It
terminated the string with a null
character.
- It used busy waiting synchronization on
RDRF.
- A UART output function outputed a 32 bit number
in unsigned hexadecimal format. Variable format
was 1 to 8 digits with no space before or
after.
- A UART hex input function accepted ASCII input
in unsigned hexadecimal (base 16) format. No
"$" or "0x" needed to be entered, just the 1 to
8 hex digits.
- It converted lower case a to f to uppercase A
to F and converted it to a 16 bit unsigned
number value range is 0 to FFFFFFFF. If you
enter a number above FFFFFFFF, it returned an
incorrect value.
- Backspace removed the last digit
typed.
- The UART output function for decimal numbers
outputted a 32 bit number in unsigned decimal
format.
- Variable format was 1 to 10 digits with no
space before or after.
- A UART Input function for decimal numbers
accepted ASCII input in unsigned decimal format
and converted them to a 32 bit unsigned number
with the valid range from 0 to 4294967295
"(2^32-1)". If you enter a number above
4294967295, it returned an incorrect
value. Backspace removed the last digit
typed.
- The UART output string function outputted a
null terminated string.
- The UART character output function outputted
an 8 bit character to the serial port.
- The UART input character function waited for a
new serial port input.
- The UART input function waited for a new
serial port input.
- The UART Init initialized the UART for 115,200
baud rate (assuming 50 MHz UART clock), 8 bit
word length, no parity bits, one stop bit, and
FIFOs enabled.
Goal of course: to put together all
that we learned in an old fashioned video game from the
1970s and 1980s, Space Invaders, which was optional and I
did not do, but may do someday! Here are some details
about that.
Link to
embedded systems class files for final project that we were
given to evaluate. Project was optional, so I evaluated
without putting all my labs together here.
- Hardware: ARM based microcontroller
board (LaunchPad) and a simulator (from
professors).
- Game controller hardware involved was a slide
potentiometer, 2 switches, 2 LEDs, resistors to
interface to the switches and LEDs, and a mini
display.
- Images of the space invaders, space ships, lasers,
bunkers, etc, were 2 dimensional arrays.
- Microcontroller timers were used for periodic
interrupts.
- The DAC (Digital to Analog Converter) was used to make
sound.
- Graphics were displayed on the mini display
LCD.
- Programming involved: timers,
interrupt service routines, the Analog to Digital (ADC)
Converter, and device drivers for the DAC and
LCD.
- Professors provided some code:
interfacing the graphics to the mini display.
- Game controller:
- Audio files: were provided and a DAC
was used for making sounds to a speaker or headphones
connected by an audio jack.
- Main game engine: ran in an infinite
loop, interrupted by 2 interrupt service routines
(ISRs).
- SysTick ISR ran 30 times per second (30
Hz) and handled:
- the player ship fires (button
presses)
- the player ship being moved (slide
potentiometer ADC (analog to digital
input)
- the sound made for a button press fire was
scheduled by SysTick ISR, so that when the other
faster ISR, Timer2A ISR runs, it could output
more quickly (11 kHz, runs 11,000 times per
second)
- the explosion sound array to the speaker or
headphone.
- Timer2A ISR this interrupt
service routine ran faster than SysTick ISR. It ran
at 11,000 times per second (as opposed to 30 times
per second for SysTick ISR). Timer2A ISR was 11KHz,
but SysTick ISR was 30Hz.
- Graphics (space invader enemies, player ship,
etc):movements were put into a buffer, but the
main game engine outputed them to the LCD display, (was
time consuming).
