The document provides an overview of embedded systems and firmware, highlighting their dedicated purpose as part of larger electronic devices. It contrasts embedded systems with general-purpose devices, emphasizing differences in programming languages, hardware access, and constraints. The text also discusses hardware interfacing, architecture, programming techniques, and debugging tools relevant to embedded systems.
3 // Background
AnEmbedded System is:
● A computer processor with a dedicated purpose
● Part of a larger electronic device (“embedded”)
● Not intended to be a general-purpose computer
Any device that contains a processor, but isn’t a PC or smartphone!
4.
4 // Background
Firmwareis Embedded Software
● Runs on embedded systems
● Directly controls electronic (or mechanical) hardware
● Historically, this software was set in stone at manufacturing time,
essentially becoming part of the hardware → “firmware”
○ Today, many devices have updatable firmware
6 // What’sdifferent?
● Runs on a general-purpose
device
● User-centric, graphical
● Operating system mediates
hardware access
● State of the art hardware
● A variety of higher-level
programming languages
● An integral part of the device
● Primitive or no user interface
● Direct hardware access
● Primitive hardware capabilities
● Programmed in low-level
languages such as C or assembly
● Digital
○ GeneralPurpose Input/Output (GPIO)
○ Serial communications (SPI, I2
C, etc)
○ USB
● Analog
○ Analog-to-digital converters (ADC)
● Specialized Peripherals
○ Radio on-chip (Bluetooth, ZigBee, Thread, RF4CE, etc)
10 // Hardware
Interfacing to the outside world
11.
11 // Hardware
MemoryMapped I/O
Address
Decoder
Memory
Cell
Enable
Read/Write
Address
Bus
Data Bus
Normal Memory
Latch &
Amplifier
Address
Decoder
Enable
Read/Write
Address
Bus
Data Bus
LED
GPIO
Address
Decoder
Peripheral
Enable
Read/Write
Address
Bus
Data Bus
Generic Peripheral
● The mostprimitive form of multitasking
● The interrupt vector stores callback functions
● Hardware triggers the CPU to invoke these functions in response to
certain events
○ Timer elapsing
○ Data arriving on serial interface
○ Many more!
13 // Hardware
Interrupts
● Usually C,sometimes assembly
○ Must allow addressing specific memory locations
● Low-level programming style -- abstraction is expensive
○ global variables
○ fixed-size arrays
○ avoid passing large objects on the stack
● Very often you’re counting every byte
○ fixed-width types are preferred
○ bitwise operations are common
15 // Tools and Techniques
Programming Language
16.
● ISRs mustbe fast!
● Only has access to global state
● Great care must be taken when main thread accesses shared global
state
○ Turn off interrupts (“go atomic”)
○ Use CPU instructions that are guaranteed to be atomic
● You can poll the interrupt flags when interrupts are turned off
16 // Hardware
Interrupt Service Routines
18 // Toolsand Techniques
Compiler/IDE
● Expensive, awkward, buggy
● Cross-compiled from your computer
● Emulators are not usually useful because of the tight coupling to
external hardware
19.
● No obvioussign! It’s just a brick
● Logging is not always available
● Stack traces are not always available
● External hardware is required to debug
● Limited number of breakpoints!
● LEDs are pretty great
19 // Tools and Techniques
When things go wrong...
20.
20 // Toolsand Techniques
Programming/Debug Hardware
● Expensive, awkward, buggy
● Some device interfaces are proprietary, but there are also standards
such as JTAG or SerialWire