All posts by Jeff

Electrical engineer, tinkerer, maker.
Microcontrollers, Projects

Fixed USBTinyISP drivers for 64-bit Windows 7 / Vista x64

7 Comments

For some time now, those wanting to use the Adafruit Industries USBTinyISP with the 64-bit versions of Windows 7 or Vista were faced with the following errors when attempting to install the device drivers supplied by Adafruit:

For some reason, the 32-bit versions of these operating systems don’t prevent the unsigned drivers from being installed, although they do complain.

There are a few workarounds that involve hacking Windows or disabling digital signature checking, but thanks to a tip by user wayneft on the Adafruit support forums, I was able to make the process much more straightforward.

The USBTiny drivers are based on libusb-win32.  Based on some notes I found on the libusb-win32 wiki, I discovered that the latest libusb drivers contain a proper digital signature:

Vista/7 64 bit are supported from version 1.2.0.0 since a Microsoft KMCS accepted digital signature is embedded in the kernel driver libusb0.sys. libusb-win32 based device drivers can also be submitted for Microsoft WHQL testing. Several companies have successfully finished the WHQL testing with their libusb-win32 based driver package. This will allow the customers to install the driver without a warning under current 32bit/64bit Windows.

This is good news!

I downloaded the latest version of libusb-win32 (1.2.1.0) and used the included inf-wizard tool to create new drivers for the USBTinyISP:

usbtinyisp_libusb-win32_1.2.1.0

I used the Windows device manager to upgrade the broken drivers on my Windows 7 64-bit machine.  There is still a warning that “Windows can’t verify the publisher of this driver software” but there are no more errors about digital signatures and the new drivers appear to install and work correctly.

I haven’t done a huge amount of testing with the drivers, but I was able to communicate with the USBTiny via avrdude and flash a simple program to an AVR.   I also haven’t tested this fix on Vista, as I don’t have access to a computer running it.  If anyone tests these drivers on Vista x64, please post your results in the comments!

Microcontrollers

Fix for broken avr-size in Ubuntu 10.04 (Lucid Lynx)

8 Comments

If you have never used it before, avr-size is a very useful command that does a relatively simple thing – it tells you how large your compiled avr-gcc programs are.  This is very useful knowledge when you are trying to fit as much code as possible into a part with only a few K of flash memory.  Additionally, the actual flash footprint of an AVR program is not something you can easily distill from a .hex file.  Hex files are usually much larger than the actual compiled code due to the overhead of that file format.

avr-size comes with the binutils-avr package in Ubuntu (and is installed as part of WinAVR and CrossPack on Windows and OSX, respectively).  Unfortunately, Ubuntu 10.04 (Lucid Lynx) ships with a broken version of avr-size that doesn’t include the necessary patches to support the AVR.

To see if your avr-size is working, open a Terminal in Lucid and try executing this command on a compiled avr-gcc .elf file of your choice:

avr-size -C --mcu=attiny2313 main.elf

You’ll probably see something like this:

avr-size: invalid option -- 'C'
Usage: avr-size [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B     --format={sysv|berkeley}  Select output style (default is berkeley)
-o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal or hex
-t        --totals                  Display the total sizes (Berkeley only)
--common                  Display total size for *COM* syms
--target=<bfdname>        Set the binary file format
@<file>                   Read options from <file>
-h        --help                    Display this information
-v        --version                 Display the program's version
avr-size: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex

Bad news, but it’s not surprising. You have the broken version of avr-size that comes with binutils-avr for Lucid.

The solution:

I was able to fix this issue by installing the binutils-avr package for Debian Squeeze, an approach I learned about from this Ubuntu bug report.

To download the Debian binutils-avr package, either go to the Debian package repository or execute this command:

wget "http://ftp.us.debian.org/debian/pool/main/b/binutils-avr/binutils-avr_2.20.1-1_amd64.deb"

Now install the package by double clicking on it or executing:

sudo dpkg -i binutils-avr_2.20.1-1_amd64.deb

If you tell Ubuntu to “hold” the package you just installed, it should stop trying to revert to the broken version in the Lucid repository every time you run a system update:

echo "binutils-avr hold" | sudo dpkg --set-selections

You can check the hold status by running

sudo dpkg --get-selections | grep binutils-avr

The status should be shown as “hold” (not “install”).

Now if you run avr-size, you should see the special AVR option ‘-C’ is now present.

jkeyzer@atom:~$ avr-size --help

Usage: avr-size [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B|-C  --format={sysv|berkeley|avr}  Select output style (default is berkeley)
--mcu=<avrmcu>            MCU name for AVR format only
-o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal or hex
-t        --totals                  Display the total sizes (Berkeley only)
--common                  Display total size for *COM* syms
--target=<bfdname>        Set the binary file format
@<file>                   Read options from <file>
-h        --help                    Display this information
-v        --version                 Display the program's version
avr-size: supported targets: elf32-avr coff-avr coff-ext-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex

Report bugs to <http://www.sourceware.org/bugzilla/>

You can also test it out on a compiled .elf file:

jkeyzer@atom:~$ avr-size -C --mcu=attiny2313 main.elf

AVR Memory Usage
----------------
Device: attiny2313

Program: 2008 bytes (98.0% Full)
(.text + .data + .bootloader)

Data: 23 bytes (18.0% Full)
(.data + .bss + .noinit)

It works!  You now have a working avr-size command for Ubuntu.

There is a good chance this package will eventually be fixed in the Lucid repository, but based on the bug report above, it could be a while (2012?) before we see an update.  Until then, installing the Debian package seems to be a good solution.

If anyone reading this is close to the Ubuntu package maintainers, can you please kick them about this issue?

Uncategorized

Ahh, that’s better!

12 Comments

About a month ago, I complained about Time Warner’s anemic upstream bandwidth cap on home cable modem service.  (512k!  Oh, the humanity!)

Well, a phone call to Time Warner and $10 a month later, my cap has been increased to 2 Mb.  They call this their “Turbo” plan.  (Turbo == fast, right?)

The asymmetry of my speedtest result below is still laughable, but the improvement in upstream AND downstream performance is very noticeable.  Now my uploads to Flickr don’t completely saturate the connection and more than one person can actually use the network without hosing everyone else.

I still suspect that my upstream bandwidth puts a cap on the actual download performance I can achieve.  I haven’t been able to find a rule of thumb to calculate how much upstream bandwidth is required to support a 20+ Mb/s download.

Surely there is a relationship between data coming down the pipe and the acknowledgements (or other handshaking packets) that are sent back?

Ahh, that's better.