Supporting Different Chips

[DavePearce]

We need some mechanism to describe the various variations on the basic AVR architecture. Some kind of data file would make sense I guess.

[DavePearce]

Some links:

https://www.avrfreaks.net/forum/adding-atmega16u2-arduino-software https://github.com/ElektorLabs/Arduino/blob/master/source/avr/boards.txt

[DavePearce]

There are at least three main aspects:

• Configuration. Each device typically has it's own RAM / FLASH / EEPROM configuration.

• Pins. There are various pins which connect to the available ports (e.g. PORTB, PORTC, etc). Theses ports are accessed via output registers.

• Internal Components. There are various internal components (e.g. USB interface, SPI interface, etc) which drive pins. These are also accessed via output registers.

Examples:

• ATtiny85. Has 8 pins, 512 bytes of SRAM, 512 bytes of EEPROM, 8192 bytes of FLASH. There is only one port (PORTB) of which 6 bits are utilised (PB0--PB5). There are several peripheral components, including two 8bit counters and a Universal Serial Interface.

• ATmega328. Has 28 pins, 2048 bytes of SRAM, 1024 bytes of EEPROM, 32768 bytes of FLASH. There are three ports (PORTB, PORTC, PORTD), though only 7bits of PORTC are utilised. There are two 8bit timers, one 16bit timer and SPI and USART interfaces.

NOTE: The peripherals tend to map to different I/O ports.

[DavePearce]

So what do we need for a configuration? At least these things:

• List of I/O internal peripherals. Each of these should have one or more labelled registers (e.g. DDRB, USIDR, etc).
• Pin Labelling. A mapping of pins to labels (e.g. PB0).
• Allocation. Mapping of I/O labelled registers to actual I/O registers.

For the ATtiny85, we have:

• EEPROM(EEARH,EEARL,EEDR,EECR, etc), USI(USIBR,USISR, etc)

• Pin 1 => PB5, Pin 2 => PB3, etc

• EEARH => 0x1F, EEARL => 0x1e, DDRB => 0x17, PORTB => 0x18.

This is still missing a pin label to register bit mapping I think.

[DavePearce]

Currently, we have the WireArrayPort which accepts a list of pins and a list of register addresses. What it could do instead is expose a list of register labels (or descriptors) and pin labels. These can then be bound after the fact.

NOTE: the USI, for example, assumes that relevant I/O pins are set as outputs in the DDRB register (on e.g. ATtiny85). In essence, the I/O peripherals drive through the I/O ports.