ECE 155 - Engineering Design with Embedded Systems
- Definition: any system hidden inside of a larger system to perform a task or set of tasks without the
user’s knowledge of the embedded system’s existence
- Ex. Pedometers, smartphones, microwaves, control units in vehicles/aircrafts
- Design constraints when choosing which processors or electronics include processor power and the
environment in which the embedded system will perform in.
- Challenges may include: Variability, No/Poor UI, No API/OS, loading software to the system
Embedded Systems Diagram
- Provides input from external environment
- Ex. Cameras, light sensors, microphones
- Converts sensor input from analog to digital
- Conversion is approximate
- Converts output signal into some effect to
the external environment
- Ex. Vibrator, blinker, speakers, displays
- Definition of an event: a notification of a change to the state of your system (ie. A mouse click)
- Definition: a programming paradigm where the direction of the program is determined by events.
- Inversion of Control : Embedded System gets to choose to run which block of code
- Definition: when the processor requests - Definition: tells the processor about a high priority
readings from the input at a certain time event in the current thread.
- Occasional Polling (whenever - When the processor gets an interrupt , it stops the
convenient) current task, saves state and execute a pre-defined
- Periodic Polling (at fixed time intervals) interrupt handler
- Tight Polling (constantly) - Interrupt handler: read event info and store it
- Can be considered Passive somewhere accessible.
synchronization - After the handler returns, resume
- One giant loop that consumes events and update the system state.
- Ex. All videogames Android Activity
- Consists of a single full screen window UI
- create widgets (TextView), event listeners
- Back Button: returns to the top most
activity off the stack and gets rid of it
- Switch Task Button: puts a different activity
and its stack in the foreground and puts the
old activity in the background
- Used to move to a new activity
- How it works? One component broadcasts
Ref: an Intent. Then, 0 or more components
d.com/reference/androii receive the Intent. Android may pick a
d/app/Activity.html component to act upon the Intent
- Use onActivityResult to receive results from
a sub-activity. This protected method takes
in int requestCode, int resultCode and
Saving and Restoring State
- Use onSaveInstanceState() to save data. In onCreate() you can restore the value(s).
Toast: aka pop-up message
Broadcast Receivers: Android uses Intents to broadcast info about the system (Ex. Wifi signal, battery
life, 3G signal) between applications.
ListView: a UI element that allows the user to see a list of items
How to send an event in the future True Interval Timer
1. Create a Handler object h - A true interval timer intrrupts the processor, rather
2. Create a Runnable object r using an than waiting for the executing thread to become free
inner class; code behaviour - In Java, use Timer class
3. Call h.postDelayed(r, delayinMS); - Remember to use runOnUiThread(timerTick) instead
*Example of Interval Timer of timerTick.run(); otherwise the program will crash
because you are trying to execute code on the wrong
Watchdog Timers Restart Restarts the clock so it doesn’t reach 0
Reset If reaches 0, reset the system. The system might
Ex. Self-destruct feature in the UWAR’s flying robot
to-Watchdog-Timers Software Design/Debugging
Real-Time Systems – requires software to respond to an external event in a fixed amount of time.
Simulations – a mathematical model of a system to estimate the behaviour of a system; cost effective!
Variables while programming
- If a variable exists only in the block, use a short name
- If a variable describes a whole class, use a descriptive name
- Use as little global variables as possible
Types of Bugs (from easiest to hardest to debug) Debugging Strategy
1. Compile-Time Errors - Essentially a modified scientific method
2. Runtime Exceptions (Ex. ArrayOutofBounds) - Test hypothesis, refine if necessary until
3. Runtime bugs (program executes but behaviour you find the cause of failure
is not as expected.
Code Review stare at code Code Instrumentation
(line by line) in the areas you Definition Insert print statements into your code and observe
believe the error is occurring outputs/variables
Assertion a statement where you know is always true
Single-Step Execution put Breakpoints
code line by line and inspects Line breakpoints halt at a line
the program state. Exception breakpoints halt program execution and load the
debugger when the program throws a particular execption
Watchpoints halt program execution when a particular memory
location changes (or accessed)
Method breakpoints halt at a particular method upon entry or exit
Debugging for Embedded Systems
For software debugging: a hardware simulator Debugging Challenges
For hardware debugging: test drivers and a test Bug Localization
harness Need for instrumentation (for diagnostic info)
Software breakpoints are hard
Programming for the Real World: Goals
1. Forage Look for software/code out there as base
2. Tinker Figure out what the code does and “mess” around with it.
3. Wield Combine the pieces you’ve foraged
- Dependencies sometimes there are missing components
- Impendence mismatches bridging components together
4. Grow Fix bad interfaces
5. Doubt be familiar with the library. Reuse code if possible.
6. Refractor Clean code and make it testable/readable Engineering Design and Analysis
1. Recognition of Need Design Heuristics general rule of
2. Definition of Problem thumb (ie. Simple UI)
3. Definition of Design Criteria Design Guideline a more general rule
Standard provides a widely used set of
4. Design Loop: Synthesis, analysis, decision-making
5. Evaluation requirements when designing the
6. Optimization solution
Specification description of solution
- Testing attempts to verify the functionality of Levels of Testing
your software Unit Testing test methods, classes
- A test case should contain what you input to independently and specifies behaviour
the software and what the software should Regression Testing Testing new code so that it
output in response still is functional
Industry Practice Integration Tests Testing software modules
Unit Testing together
Code Reviews System Tests testing the entire system (usually
Continuous Builds (Automated tests occur) via Black Box)
QA Team (Additional testing and verification)
Refactoring (AKA Cleaning Code)
Only changes local code and List of Refactoring
preserves semantics Techniques that allow for more abstraction:
Types of Refactoring Encapsulate Field: force code to access the field with getter and setter
Composing methods: change methods.
what code belongs to which Generalize Type: create more general types to allow for more code
Moving features between Replace conditional with polymorphism: use inheritance and virtual
objects: put fields, methods, dispatch instead of a conditional.
classes in different places; Techniques for breaking code apart into more logical pieces:
Organizing data: change how
Extract Method: as seen above, pull out part of a larger method into a
data gets stored in your new method.
program; Extract Class: moves code from an existing class into a new class.
Simplifying conditionals: make Techniques for integrating code that's needlessly spread apart:
your if statements easier to
Inline Method: integrate a copy of the body of a method into its calling
Making method calls simpler: Inline Class: put all of the fields and methods of a class into another
change how me