Where I describe the differences between the industry standard AVR microcontroller (ATmega328P), star of the Arduino Uno R3 and a minimal version of an AVR microcontroller, the Microchip ATtiny13A.
Introduction#
Why is this comparison important?
It is helpful to understand that this chip is significantly less capable than the chip used by the Uno. That said, it perfect for projects which need a “little bit of intelligence”, and only, three inputs and three outputs.
The chip has the following:
- 8 pin plastic dual-in-line package (PDIP), which is easy to use in a breadboard
- low-power CMOS 8-bit microcontroller, great for battery-powered projects
- 1K Bytes of Flash program memory, enough for small projects
- 64 Bytes EEPROM
- 64 Bytes Internal SRAM
- 6 general purpose I/O pins (GPIO)
- 4 channel 10-bit ADC
- 1 8-bit timer/counter
- debugWIRE On-chip Debug System
- In-System Programmable via SPI Port
- Internal Calibrated Oscillator
Comparison to the ATmega328P (Arduino Uno R3)#
| Feature | ATmega328P | ATtiny13A |
|---|---|---|
| Architecture | 8-bit AVR RISC | 8-bit AVR RISC |
| Flash Memory | 32KB | 1KB |
| RAM (SRAM) | 2KB | 64 bytes |
| EEPROM | 1KB | 64 bytes |
| GPIO Pins | 23 | 6 |
| Pin Count | 28/32 | 8 |
| Timer/Counters | 3 (Two 8-bit, One 16-bit) | 1 (8-bit with prescaler) |
| PWM Channels | 6 | 2 |
| ADC | 10-bit, 8 channels | 10-bit, 4 channels |
| Operating Voltage | 1.8V - 5.5V | 1.8V - 5.5V |
| Max Clock Speed | 20 MHz | 20 MHz |
| Communication | USART, SPI, I²C | SPI |
| Analog Comparator | Yes | Yes |
| Watchdog Timer | Yes | Yes |
| debugWIRE | Yes | Yes |
| Power Modes | 6 modes | Multiple low-power modes |
| Brown-out Detection | Yes | Yes (programmable) |
In another words, as the industry goes towards greater performance with significantly more complexity, the ATtiny13A is a well-documented, easy to understand, simple to implement microcontroller.
Development System#
For years, I approached teaching microcontroller development from a multi-platform approach. My approach would cover all three platforms, macOS, Windows and Linux in creating a toolchain for embedded development. This approach is needlessly complex and futile. I spent more time debugging the three platform’s than debugging my microcontroller code.
Raspberry Pi#
My new approach is to use a Raspberry Pi as the development platform. A stock Raspberry Pi 3B is $35 and one can connect either via ethernet or wireless. There might be a slight lag in performance, however this low-cost board is quite capable. Spending a little bit more to get the Raspberry Pi 4 can be worthwhile, its a more versatile, however until RAM prices comedown, the 4GB RPi 4 is just too expensive at $120.
Best OS for Embedded Development#
I use the Raspberry Pi as Linux is the best operating system for embedded development and the Pi is well-supported. The Rasperry Pi Connect feature makes it dead-simple to be able to connect to your Pi once you’ve flashed the OS onto an SD card.
Enables Bloom#
The second reason to use Linux, is that it allows you to use bloom. Bloom is a gdb-server for AVR microcontrollers. Using bloom and a low-cost, debugging board like the Microchip SNAP enables a true debugging environment, avr-gdb. I’ll go into detail as to why this environment is important in the next entry.
Repository#
One way to understand how to develop code for the ATtiny13A is to use this repository. It contains many examples in both assembly or the C language.
Per the repository…
“This repository provides example programs in C (ANSI C99) AVR-LibC and AVR assembly language which support programming the ATtiny13A.
All example programs live in the examples folder. A subfolder will either contain a C language, assembly language or mixed-C/assembly example. A C language or mixed-C/assembly will use main.cas the principal program. Assembly language examples are named with an asm_ prefix (e.g. asm_blink) and use main.S as their principal program. The same root Makefile will build all three kinds, as it auto-detects whether to link freestanding (assembly) or with the C runtime. The standard make commands such as make flash, make size, etc. work on all examples. See docs/assembly_examples.md for the assembly examples index.”
With only 1KB of FLASH (or 512 AVR instructions), its important to use assembly language where you can, to save space. That said, its nice to use the C language at times for easier development. There are also situations where assembly language enables capabilities which are easily managed using C.
Serial Example#
A great example is the serial interface. In C, the serial interface was limited to a flaky 9600 baud. It worked, however, not consistently and it wasn’t rock solid. Once I re-wrote the serial program in assembly code, the code was rock-solid at 9600 baud. I also realized that a simple serial interface was required, there is little need (and no space) for atoi/itoa (ascii to integer/integer to ascii) routines. The new version has the following (C API):
// Initialise TX/RX pin directions and idle state.
void init_serial(void);
// Transmit one hex byte at 9600-8-N-1.
void char_write(uint8_t c);
// Transmit one hex word at 9600-8-N-1.
void word_write(uint16_t c);
// Block until one hex byte is received at 9600-8-N-1.
uint8_t char_read(void);
// Write program memory text (ASCII) to console
void flash_write(uint16_t addr);The last routine, uses program memory to output text, saving the precious, 64-bytes of RAM. These four commands, along with the initialization command are sufficient to use the 2 pins as a debugging port, albeit at the cost of 2 pins.