Commit 0258e709 authored by Jake Read's avatar Jake Read
Browse files


# The Wonderful World of Microcontrollers
The documentation in the CBA's **pub/hello-world** world is shotgun examples of how to use our favourite microcontrollers.
Many others use extensive libraries to abstract hardware functionality into easy to read code (i.e. arduino, or STM32's HAL). We tend to avoid this - this is something of an aesthetic choice, but also has [measurable performance benefits](
For those just entering the world of embedded programming, there are a few useful concepts to have a handle on before beginning.
## Toolchains, Programmers
Getting code onto a microcontroller is no small feat!
The end result is that some block of memory in the micro contains the program instructions we have written. A few things need to happen for this to become true.
`` C Code -> Compiled Instructions -> Memory Block (.hex, .bin, .elf) -> Programmer -> Micro ``
### Compiling Code
Typically, we'll see systems use GCC (the GNU Compiler Collection) which is a command-line tool available in most systems. If we use another IDE (say, Atmel Studio or Arduino), these IDEs will actually be calling GCC when they make your code. With 'makefile' systems, when we run 'make flash' or 'make program' etc, one of the things we are doing is invoking GCC to compile the program.
A compiler needs to act a little bit differently given different processor architectures. I.E. AVR chips != ARM chips != Intel, because these all have different instruction sets. We need, at some point, to tell our compiler which device it is building for.
### Using a Programmer to Load Code
Now that we have a program, we'll need to push it into the memory of the chip. There are a few different protocols to do this.
Depending on your chip, you'll need to find a programmer (device, i.e. the Atmel ICE, USBISP, etc) - these are typically USB devices (i.e. they can talk to a PC) that 'convert' program memory files into a datastream that the microcontroller will load into its memory.
## Registers, Peripherals, oh my
While microcontrollers *include* tiny processors, they interface with the world with auxilliary circuits called **peripherals**. We can think of these like little bundled ASICs (application specific integrated circuits) that offload time-sensitive work from the processor. These also perform level shifting and current carrying capability.
Here's the diagram for an XMEGA
Some common peripherals:
- [PORT / PIN for digital logic (high, low, input)](
- [UART (universal asynchronous receive transmit)](
- [SPI (serial perhiperal interface)](
- [I2C (addressable two-wire interface)](
- ADC (analog to digital converter)
- DAC (digital to analog converter)
- PWM / TC (timer counter - powerful! useful! can do anything!)
If we imagine peripherals to be little machines that the processor operates, we can think of registers as *memory locations whose bits are switches* for those machines. This is a bit odd, but I find it a useful metaphor. When we write into register locations, we are switching these bits on and off.
So! Figuring out which registers to read / write to is where we come to the datasheet. These provide extensive information on which registers do what, what order they need to be configured in, etc.
[**Bitwise Operators**](
## Reading Datasheets
Is a PITA, but hugely enabling. Here are two guides: [one]( and [two](
## Other Architectures
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment