Week 8: Embedded programming
Reading the ATMEL ATtinyX4A datasheet
Introduction
I am quite used to read simple and short datasheets of both analog and digital components: amplifiers, gates, counters, sensors.
Long time ago, I also have read microprocessors datasheets. From my non-specialist&non-professional-point-of-view, reading a microcontrollers/microprocessors datasheets is very different form reading other datasheets. For most of the components, reading the datasheet is often just checking an information (a gain for an amplifier, an abacus for transistor, the pins positions on a gate). Most of them are self-explaining, and need few external references...
Reading a microcontroller datasheets is like starting to read a novel: who are the characters (the registers), what is the context (time and landscape - clocks and levels) ? Even if you know what is the end of the story (everything ends being C !), you need to accomodate the writter's language (the instruction set). Datasheet is not enough to understand the whole thing: you have to refer to many other documents/sources.
What it reminded me
Harvard architecture: separate bus and memories for instructions and data
ADC takes time;
Flash memory and EEPROM memory have finite write/erase cycle endurance.
What I learned
How brown-out detector works.
ADC gain is tunable from 1x to 20x (although I have not investigated how)
Fuses are described p.159, section 19.2. Extremely important.
Full registrers description is p.266, section 22.
Full instruction set description is p.268, section 23, but there is no hex code/mnemonic table... Therefore, it is impossible to code my own assembler (joke).
What I still do not know
I found not hint about endianism. I had no reason to look for it until reading ADIW
and SBIW
. Which is Rdh
and which is Rdl
? (page 268). This means: if I want to re-write ADIW
with several ADC/ADD
, I cannot (OK, this would be inefficient, but let consider what could be "ADIL
" for longs). Again, it is impossible to code our own assembler (joking again). Only solution: read avr-gcc sources (arf...) ? Or find information elsewhere.
Previous week
Back to index
Next week