Electronics project notes/Avrusb500v2 notes

From Helpful
Jump to navigation Jump to search
This is for beginners and very much by a beginner / hobbyist.

It's intended to get an intuitive overview for hobbyist needs. It may get you started, but to be able to do anything remotely clever, follow a proper course or read a good book.


Some basics and reference: Volts, amps, energy, power · batteries · resistors · transistors · fuses · diodes · capacitors · inductors and transformers · ground

Slightly less basic: amplifier notes · varistors · changing voltage · baluns · frequency generation · Transmission lines · skin effect


And some more applied stuff:

IO: Input and output pins · wired local IO · wired local-ish IO · ·  Various wireless · 802.11 (WiFi) · cell phone

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

Noise stuff: Stray signals and noise · sound-related noise names · electronic non-coupled noise names · electronic coupled noise · ground loop · strategies to avoid coupled noise · Sampling, reproduction, and transmission distortions

Audio notes: See avnotes


Platform specific

Arduino and AVR notes · (Ethernet)
Microcontroller and computer platforms ··· ESP series notes · STM32 series notes


Less sorted: Ground · device voltage and impedance (+ audio-specific) · electricity and humans · power supply considerations · Common terms, useful basics, soldering · landline phones · pulse modulation · signal reflection · Project boxes · resource metering · SDR · PLL · vacuum tubes · Multimeter notes Unsorted stuff

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · JY-MCU · DMX · Thermal printer ·

See also Category:Electronics.

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

The Avrusb500v2 is an stk500 V2 compatible 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 it's 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).

In windows it'll show up as a (probnably 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