collapseos/doc/avr.txt

70 lines
3.0 KiB
Plaintext
Raw Normal View History

2020-08-30 22:42:33 +10:00
# Working with AVR microcontrollers
# Assembling AVR binaries
TODO
# Programming AVR chips
To program AVR chips, you need a device that provides the SPI protocol. The
device built in the rc2014/sdcard recipe fits the bill. Make sure you can
override the SPI clock because the system clock will be too fast for most AVR
chips, which are usually running at 1MHz. Because the SPI clock needs to be a
4th of that, a safe frequency for SPI communication would be 250kHz.
Because you will not be using your system clock, you'll also need to override
SPI_DELAY in your xcomp unit: the default value for this is 2 NOP, which only
works when you use the system clock.
Alternatively, you could run your whole system at 250kHz, but that's going to be
really slow.
The AVR programmer device is really simple: Wire SPI connections to proper AVR
pins as described in the MCU's datasheet. Note that this device will be the same
as the one you'll use for any modern SPI-based AVR programmer, with RESET
replacing SS.
(TODO: design a SPI relay that supports more than one device. At the time of
this writing, one has to disconnect the SD card reader before enabling the AVR
programmer)
The AVR programming code is at B690.
Before you begin programming the chip, the device must be deselected. Ensure
with "(spid)".
Then, you initiate programming mode with "asp$", and then issue your commands.
At this time, only fuse commands are implemented. You get/set they values with
"aspfx@/aspfx!", x being one of "l" (low fuse), "h" (high fuse), "e" (extended
fuse).
Each command will verify that it's in sync, that is, that its 3rd exchange
echoes the byte that was sent in the 2nd exchange. If it doesn't, the command
aborts with "AVR err".
At the time of this writing, it is recommended that you perform your commands in
batch, that is, running your commands right after the "asp$" command, ending
your batch with "(spid)" so that the next batch works. In my tests, interacting
with the chip "live" in a single "asp$" session sometimes resulted in unreliable
data that didn't properly detect sync errors. TODO: investigate further.
2020-09-06 04:07:13 +10:00
# Writing data to Flash
Writing to AVR's flash is done in batch mode, page by page. To this end, the
chip has a buffer which is writable byte-by-byte. To write to the flash, you
begin by writing to that buffer using aspfb! and then write to a page using
aspfp!.
Please note that aspfb! deals with *words*, not bytes. If, for example, you want
to hook it to A!*, make sure you use AMOVEW instead of AMOVE. You will need to
create a wrapper word around aspfb! that divides dst addr by 2 because AMOVEW
use byte-based addresses but aspfb! uses word-based ones. You also have to make
sure that A@* points to @ (or another word-based fetcher) instead of its default
value of C@.
Beware of bootloader sections! By default, AVR chips have a bootloader using the
first few pages (by default, the ATMega328P uses 4 pages for its bootloader).
Check (or modify) the BOOTSZ fuses to confirm where you whould start writing
your program.