izaya/collapseos
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Improve AVR docs

Browse Source 
After many trials and errors in reliably accessing AVR chips through
my SPI relay design, I resigned myself to accepting 125kHz communication
speed with it. I find the complexity of solutions allowing to keep 250kHz
speeds to be excessive.
This commit is contained in:
Virgil Dupras 2020-10-05 16:46:16 -04:00
parent 44bcdd4327
commit ebafa79795
1 changed files with 49 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
doc/avr.txt
View File

@ -11,11 +11,26 @@ tem 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.
# The programmer device
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.
This device should have an on/off switch that controls the
chip's power for a very simple reason: Because we can't control
what's on the chip, it could mess up your whole SPI bus when
RESET is not held low. This means that as long as it's connected
and powered, it is likely to mess up your other devices, such as
the SD card.
You could put the AVR chip behind a buffer to avoid this, but
an on/off switch also does the trick and satisfies the low-tech
lover in you.
# Programming software
The AVR programming code is at B160.
Before you begin programming the chip, the device must be desel-
@ -28,6 +43,40 @@ 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".
# Ensuring reliability
The reliability of your communication depends a lot on the
soundness of your SPI relay design. If it's good, you will sel-
dom see those "AVR err".
However, there are worse things than "AVR err": wrong data. Sync
checks ensure communication reliability at every command, but
in the case of commands getting data, you might be out-of-sync
when you receive your result without knowing it! To ensure that
you're still in sync, you need to issue a command, which might
spit "AVR err". If it does, your previous result is unreliable.
Here's an example word that reliably prints the high fuse value
from SPI devid 1:
: get 1 asp$ asprdy aspfh@ asprdy .x 0 (spie) ;
Another very important matter is clock speed. As mentioned
above, the safe clock speed is 250kHz. If you use the SPI design
in rc2014/sdcard recipe, this means that your input clock speed
can theoretically be 500kHz because the '161 divides it by 2.
In practice, however, you can't really do that because depending
on the timing of your SPI write, the first "bump" of the SPI
clock might end up being nearly 500kHz, which will result in oc-
casional communication errors.
The simplest and safest way to avoid this is to reduce your
raw input clock by 2, which will reduce your effective communi-
cation speed by 2. There certainly are options allowing you to
keep optimal speed, but they're significantly more complex than
accepting slower speed.
# Access fuses
You get/set they values with "aspfx@/aspfx!", x being one of "l"