Electronics project notes/Avrusb500v2 notes

From Helpful
Jump to: navigation, search
This is for beginners and very much by a beginner. It's meant to try to cover hobbyist needs, and as a starting point to find out which may be the relevant details for you, not for definitive information.

Some basics and reference: Volts, amps, energy, power · Ground · batteries · resistors · changing voltage · transistors · fuses · diodes · varistors · capacitors · inductors · transformers · baluns · amplifier notes · frequency generation · skin effect


And some more applied stuff:

IO: IO and wired communication · localish communication · wireless (ISM RF, GSM, RFID, more) · 802.11 (WiFi) · 802.15 (including zigbee)


Sensors: General sensor notes, voltage and current sensing · Knobs and dials · Pressure sensing · Temperature sensing · humidity sensing · Light sensing · Movement sensing · Capacitive sensing · Touch screen notes

Actuators: General actuator notes, circuit protection · Motors and servos · Solenoids

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · Bluetooth serial · JY-MCU · DMX · ESC/POS notes

Audio notes: basic audio hacks · microphones · amps and speakers · device voltage and impedance, audio and otherwise ·

Less sorted: Common terms, useful basics, soldering · Microcontroller and computer platforms · Arduino and AVR notes · ESP series notes · Electronics notes/Phase Locked Loop notes · mounts, chip carriers, packages, connectors · signal reflection · pulse modulation · electricity and humans · Unsorted stuff


See also Category:Electronics.

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

AVR programmer http://tuxgraphics.org/electronics/200705/article07052.shtml

Keep in mind that 'avrusb500' and 'avrusb500 version 2' refer to a board change and are not particularly related to the stk500/stk500v2 distinction.


IO

When you're programming an AVR outside of its target circuit, or in a non-powered board:

  • 5V - to power the AVR you're programming, if necessary
  • clock output - to provide to AVRs that have fuses set to expect an external oscillator, and the AVR's not in a circuit with one (e.g. when you use)


You need to short one thing to do the initial bit-bang programming. If you don't like the finicky temporary connection, you could e.g. put a male header here to use a jumper.

If you already have an ISP programmer, you can save a bunch of time by using it to program the firmware (there's a row of pins where you can add a header for it).


Before the first use: Programming the programmer

Preparing/running the tools you need

To avoid the chicken-and-egg problem of having to program the programmer, the board was designed to program its own chip by bit-banging from the FTDI serial chip.


The progam that does this is written for linux's USB interface. There seems to be a way to use it under windows, but a little easier on linux.

...and probably easiest to use from the bootable tuxgraphics kit's CD, but it doesn't seem to boot for a bunch of people, including me. If it doesn't boot, you probably want to avoid the uisp_bbpg in there. First, it's linked against and old libc++ that you probably don't have anymore, and for me it never worked even when I worked around that: it gave me "ftdibb error: Device not connected". Downloading[1] and compiling a new uisp-patched-with-bbpg fixed that.

When building your own uisp_bbpg:

  • depends on libusb-dev, and on a working g++
  • uses -Werror in its CXXFLAGS, so it's going to treat every warning as a fatal error.
  • you'll want to copy the resulting binary somewhere.
    • In the avrusb500 package the the bbpg_firmware_load script relies on the path to call uisp_bbpg, so it should be called that (the makefile calls it uisp) and either in the path (or change bbpg_firmware_load to refer to where you have it)
    • in the avrusb500v2 package the Makefile calls ./bin/uisp_bbpg, so you'll want to copy it in there


The programming

Notes:

  • Keep in mind that the firmware for the two board revisions don't work for each other, so look out for the difference between avrusb500-x.x.tar.gz and avrusb500v2-x.x.tar.gz. It won't brick, it won't smoke, it will just produce a board that seems to do nothing, and a bunch of confusion in you.
  • running uisp_bbpg will unload the ftdi_sio module (visible if you watch syslog), which also removes the /dev/ttyUSB device. This is normal: bitbanging as it is used here needs to talk to the FTDI directly, not as a standard serial port.
  • bit banging uploads this way is slow, very slow. Think a few bytes per second, meaning the ~5KB firmware takes ~20 minutes to upload and another ~20 minutes to verify. 'course, you'll only need to do this once.


If you didn't bridge the thing you need to bridge, any attempt to program will complain fairly quickly.

You can try test_1 as a tiny test that'll only take a minute or two to upload-n-check:

make load_test_1

You'll need gcc-avr and avr-libc for it to build.

When the LED blinks, that means that most obvious things that could have gone wrong went fine, so you can upload the actual programmer firmware:

  • use make load to make avr-gcc compile the programmer, then have that uploaded, OR:
  • use make load_pre to upload the precompiled file (avrusb500_pre.hex) that came with the package


See also:

Using the programmer

Software

You now have a serial programmer that speaks stk500v2 (and stk500).

The USB part should be transparent to use. In windows it'll show up as a (high-numbered) COM port, in linux it's usually /dev/ttyUSB0


For example, for avrdude you can use it like: (The m8 in there referring to an Atmega8. Avrdude docs have a list)

avrdude -p m8 -d /dev/ttyS0 -c stk500v2 -e -U flash:w:test.hex


Note that in windows, com ports up to 8 can be specified as com1 to com8, ports above that should be specified like \\.\com12 so e.g.

avrdude -C ..\etc\avrdude.conf -c stk500v2 -p m328p -P com8 -U flash:w:test.hex
avrdude -C ..\etc\avrdude.conf -c stk500v2 -p m328p -P \\.\com12 -U flash:w:test.hex

Reading out the current code:

avrdude -C ..\etc\avrdude.conf -c stk500v2 -p m328p -P \\.\com12 -U flash:r:backup.bin:r


Physically connecting