Foobarred is Normal

Recently I started using my linux laptop as my primary avr-usb development environment. When I upgraded the laptop to the current Ubuntu-LTS release (10.4 aka Lucid lynx) a bunch of stuff was broken including all of the wonderful udev rules provided by my linux savvy friends at dorkbotpdx.

I mean jeesh even lsusb was broken.

$ lsusb -vd "03eb:"|grep iM
cannot read device status, Operation not permitted (1)
iManufacturer           1

When I started looking at what changed and how to adjust, the web dead ended to a lot of threads like the one at http://ubuntuforums.org/showthread.php?t=1360412 ; where two people declared that having to escalate privileges to root in order to talk to a user device was “normal”. Even when the developer said it wasn’t normal the ubuntu folk redeclared it normal (apparently after Bush you just have to repeat something blatantly stupid for it to be true). As an administrator the last thing you want is everything and its dog requiring root privileges.

Hanging around the #ubuntu channel was a lot like having people repeat the searches on the web that provided me with the same dead ends that I joined the channel trying to resolve.

Cherchez la femme (look at the squeeze)

This was getting stupid. All I wanted to do was to have devices that I could plug in and program and then communicate with them using ruby or perl or some other haphazzardly thrown together scripts without having to be root. Then I realized once again that ubuntu is really focused on making the users life easier and that this leads to a lot of non technical help. So I asked my friends what the nick name was for the Debian release that was the basis for the Ubuntu release nick named “Lucid” and then re did all of my dead ended web queries replacing “Ubuntu Lucid” with “Debian Squeeze”.

The results were heavy on the technical detail and light on social skills.

More importantly I quickly found the solution that I needed in the middle of this link (http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=blob_plain&f=README&hb=HEAD) what I was missing was the difference between the new and the old udev rules.

“If you are running a newer version of udev (as in Debian Squeeze and
Ubuntu 9.10), you need to adapt the rules-file to the new udev-version:
sed -i -e ‘s/TEMPNODE/tempnode/’ -e ‘s/SYSFS/ATTRS/g’ -e ‘s/BUS/SUBSYSTEMS/’ \
/etc/udev/rules.d/xusbdfwu.rules”

One line of sed was all I needed and it had taken me a week of asking about lucid when i should have been asking about squeeze. With this I also was able to find the changes to the lay out of the /dev and /proc trees and the new tools to monitor udev and diagnose issues.

All-Your-Atmel-Belong to Us

I really just wanted to change the permissions so I could use my devices. Adding the following udev rule to your system will do just that.  You will also need to restart the udev service. Both of these will require you to be root.

# cat >/etc/udev/rules.d/98-all-your-atmel-belong-to-us.rules<<EOF
#------------------------/etc/udev/rules.d/98-all-your-atmel-belong-to-us.rules
#
# Make atmel devices (dfu, LUFA, obdev) accessible in userland
# 
ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", MODE="0666"
EOF
# service udev restart

To actually own all my atmel I could have also added ‘ ,USER=”don” ‘ after the mode part but I just wanted to talk my Atmel usb-avr devices and the open source firmware I was developing. And the above rule made things “just work”.

$ lsusb -vd "03eb:"|grep iM
iManufacturer           1 mycompany.com
$

This rule fixed all of my LUFA based devices including the my open source arduino programmer as well as the dfu programmer.used to code them. Hopefully it will be a while before I have to go through this again.

Posted in Avr Development | No Comments »

feurig: ax have you gotten anything to work with deans post feburary lufa?
[1:29pm] ax: post feb. hmm, i’d have to look into my project files to remember which version i was usting
[1:29pm] ax: just a sec
[1:29pm] feurig: I was pulling my hair out with the may release and then I went back to the standard “what ever ax was using” and things started working
[1:30pm] feurig: you used the feb19 release on the midimonster stuff
[1:30pm] feurig: where is that (explicitive deleted) tourist????
[1:34pm] ax: yeah, /lufa_100219/
[1:35pm] ax: i like this ‘whatever ax was using’ standard
[1:35pm] ax:
[1:48pm] bzztbomb: That should be a source control tag

Posted in Avr Development, Mac Development | No Comments »

• http://en.wikipedia.org/wiki/The_Unix_Programming_Environment
• http://en.wikipedia.org/wiki/The_C_Programming_Language_(book)
• http://www.nongnu.org/avr-libc/user-manual/index.html
• http://www.avrfreaks.net/wiki/index.php/Documentation:AVR_GCC
• http://tom-itx.dyndns.org:81/~webpage/how_to/atmega168/mega168_howto_main_index.php

Posted in Avr Development | No Comments »

An introduction to physical computing for artists and musicians.

What:

This workshop is an opportunity for 15 to 25 people to spend a week working on the fundamentals of integrating micro-controllers into the arts. At the end of the week participants should be able to build and program their own Arduino compatible micro-controller system and use it to interact with the physical world using motors servos lights relays and switches.

The workshop will be structured with a hands on approach. The theory being that we learn best by doing. The first two days will be devoted to building and programming the base platform and using it to control various devices. The remaining 3 days will be a lab devoted to incorporating the new tools into actual pieces. The cost of the course is $105 and includes the materials listed below as well as 5 days of hands on instruction.

What you will get.

• A Benito usb to serial programmer
• A Dorkboard! (an Arduino clone) Kit
• An introduction to the Arduino and microcontrollers in an artists setting
• A servo and a geared motor with paper feed.
• A motor driver board.
• Misc parts.
• Help when you need it
• To know that what you built worked at least once
• Ideas

What to bring:

• A laptop (there will be some (not many) loaner systems available)
• A soldering iron (20-30W Pencil type)
• A standard usb cable (A->B)
• Some basic tools (esp wire cutters, x-acto knife)
• superglue
• A hot glue gun.
• foamcore or cardboard.
• A copy of your rsvp / paypal reciept.
• Ideas.

When:

June 7th through June 11th from 1-5pm.

Where:

Object Space Gallery:

1818 1/2 E Sprague, Spokane WA

How do I rsvp?

• Via paypal — go to  TDI Products page: (http://tempusdictum.com/tdproducts.html)

– or –

• If you dont paypal contact me ddelmardavis , at the gmail.com directly to make other payment arrangments.

Posted in Avr Development, electronics | No Comments »

das blinkin

With a lot of my projects I have done my prototyping with Paul Stoffregon’s Teensy series of boards before moving them onto their own codebases. On those occasions where the “prototype was all I needed” I would compile the code using the teensyduino and then manually load the .hex file onto the target. As I am looking at using the arduino for more projects I decided to take a look at how paul interacts with the Arduino IDE and see if I could load code directly onto my chips.

boards.txt

The arduino allows for different chips and configurations through the boards.txt and the programmers.txt files. Each configuration usually will also have a “core” which maps the pins and handles the particulars of that chip. When you run paul’s teensyduino installer it adds several entrys to the boards.txt file including the entry below.

teensy_ser.name=Teensy 1.0 (USB Serial)
teensy_ser.upload.protocol=halfkay
teensy_ser.upload.maximum_size=15872
teensy_ser.upload.speed=38400
teensy_ser.upload.disable_flushing=true
teensy_ser.upload.avrdude_wrapper=teensy_reboot
teensy_ser.build.mcu=at90usb162
teensy_ser.build.f_cpu=16000000L
teensy_ser.build.core=teensy_serial
teensy_ser.build.post_compile_script=teensy_post_compile

teensy_ser.name=Teensy 1.0 (USB Serial)
teensy_ser.upload.protocol=halfkay
teensy_ser.upload.maximum_size=15872
teensy_ser.upload.speed=38400
teensy_ser.upload.disable_flushing=true
teensy_ser.upload.avrdude_wrapper=teensy_reboot
teensy_ser.build.mcu=at90usb162
teensy_ser.build.f_cpu=16000000L
teensy_ser.build.core=teensy_serial
...

#############################################################
fouryou.name = atMega32U4
fouryou.upload.protocol=atmega32u4
fouryou.upload.maximum_size=32256
fouryou.upload.speed=38400
fouryou.upload.disable_flushing=true
fouryou.upload.avrdude_wrapper=dfume
fouryou.build.mcu=atmega32u4
fouryou.build.f_cpu=16000000L
fouryou.build.core=teensy_serial
#############################################################
tooyou.name = atMega32u2
tooyou.upload.protocol=atmega32u2
tooyou.upload.maximum_size=32256
tooyou.upload.speed=38400
tooyou.upload.disable_flushing=true
tooyou.upload.avrdude_wrapper=dfume
tooyou.build.mcu=at90usb162
tooyou.build.f_cpu=16000000L
tooyou.build.core=teensy_serial

#############################################################

fouryou.name = atMega32U4
fouryou.upload.protocol=atmega32u4
fouryou.upload.maximum_size=32256
fouryou.upload.speed=38400
fouryou.upload.disable_flushing=true
fouryou.upload.avrdude_wrapper=dfume
fouryou.build.mcu=atmega32u4
fouryou.build.f_cpu=16000000L
fouryou.build.core=teensy_serial

#############################################################

tooyou.name = atMega32u2
tooyou.upload.protocol=atmega32u2
tooyou.upload.maximum_size=32256
tooyou.upload.speed=38400
tooyou.upload.disable_flushing=true
tooyou.upload.avrdude_wrapper=dfume
tooyou.build.mcu=at90usb162
tooyou.build.f_cpu=16000000L
tooyou.build.core=teensy_serial

I started with a blank script that just printed the arguments passed to the wrapper and then called it by restarting my Arduino (to reload the boards.txt) And then selecting one of the new boards and “Uploading” my code. This gave me a window to interactively work through my script. Since the avrdude_wrapper code just pretends to be an avrdude most of the script is munging the arguments passed to avrdude to get the commands to pass to dfu-programmer.

#!/usr/bin/perl
use Getopt::Std;
print @ARGV;
my %args;
my $hexfile;
my $dfu = "/usr/local/bin/dfu-programmer";
my $cpu;
my $hexfile;

getopt('pUc',\%args);
$hexfile=$args{U};
$hexfile =~ s/flash:w://;
$hexfile =~ s/:i//;
$cpu=$args{c};

print "\n[" . $hexfile . "]";
print "\n[" . $cpu . "]\n";
print "$dfu $cpu erase\n";
system "$dfu $cpu erase";
print "$dfu $cpu flash $hexfile\n";
system"$dfu $cpu flash $hexfile";
print "$dfu $cpu start\n";
system "$dfu $cpu start 1>&2";
print "\n";

There is one tricky bit. The current avr-gcc doesnt support the atmega32u2 correctly but the code for the at90usb162 is binary compatible so the build.mcu is set to the at90usb162. But then dfu-programmer supports the correct chip and wont find the device so we use the fact that the upload.protocol argument is passed directlyalong using the -c argument and everything works fine.

So now we just use the hwb and reset buttons to get the system into dfu mode and upload our code directly from the arduino. Its not as slick as the teensy in “auto” mode but it works.

Posted in Avr Development, Dorkbot | No Comments »

The testbox is an LCD/Dorkboard based arduino clone with two buttons and a pair of potentiometers. The switches, power and 4 io pins are made avaliable via screw terminals on the ouside of the testbox.


#include
/*--------------------------------------------------------------
pulse generator for test box

lcd.setCursor(0,1);
if (s1) {
lcd.print("ON ");
} else {
lcd.print("OFF");
}
lcd.setCursor(6,1);
lcd.print("# ");
lcd.setCursor(8,1);
lcd.print(pulsecount);
}


Posted in Avr Development | No Comments »

Getting code onto the MidiMonster or Benito device.

Midi Monster Button Locations.	Benito 7g Switch Positions.
Benito 2010 Switch Locations	Benito Without Buttons.

All of the code on the Benito and MidiMonster devices is open source and references an open source library called the Lightweight Usb For Avr (lufa). Getting the code compiled and onto the device requires a few other open source tools.

AVR-GCC

The most current and stable release of the toochain for the AVR has untill recently been maintained by Eric Wedddington and released as WinAvr (http://sourceforge.net/projects/winavr/) Winaver integrates nicely into atmels avr studio http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=2725 and I reccomend that you get both if you are running windows. Each Winavr Release is closely followed by objective developments CrossPack for avr http://www.obdev.at/products/crosspack/index.html and a script for building the current toolchain on linux which is hosted by AvrFreaks at present there is also a debian package that was put out last month http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=90172

HWB? DFU?

Most Atmel “atmega” devices have a pin dedicated to determining weather or not the device goes into the bootloader depending on the devices flag settings. This pin is labled HWB (for hardware boot) on most of  the datasheets. The usb avr family has this mode set up by default. When you hold the hwb pin low and reset the device it goes into the bootloader. On these devices the built in bootloader uses a usb device class called the Device Firmware Uploader (DFU). Atmel provides a tool called flip for programming DFU devices on  windows and linux. There is an open source programmer called dfu-programmer http://dfu-programmer.sourceforge.net/

That other guys stuff.

Those of you who have worked with the teensy boards from paul stoffregon will notice some subtle differences. Paul wrote his own (closed source) bootloader rather than use the bootloader tha comes installed on the chips. Then he uses a hardware trick similar to the auto reset hack to make a single button manipulate both the reset and the hwb pins to put his boards into the bootloader. I didnt feel that either the two button arrangement or the builtin bootloaders were broken so I like most people working with these chips dont fix them.

Using the dfu-programmer

All of the programs in Dean Cameras Lightweight Usb for Avr have a “dfu” target. Once you have the target into the DFU mode you can simply

$make dfu

This will cause the dfu-programmer to erase the flash reprogramm it with a new hex file and restart the chip. You can also do this manually with the following commands

$dfu-programmer atmega32u2 erase
$dfu-programmer atmega32u2 flash mycode.hex
$dfu-programmer atmega32u2 start

This will cause the dfu-programmer to erase the flash reprogramm it with a new hex file and restart the chip.

Posted in Avr Development | No Comments »

What: Focused workshop: programming Midi devices using the Lightweight Usb For AVR library (Lufa) and the MidiMonster.

When: Sunday 28 Feb 2010 1-5 pm.

Where: PNCA (NW 12th and Johnson) #205

Cost: $35 (includes Midi Monster)
(If you have a MidiMonster from the PD Workshop and wish to use it please bring $10)

Materials: you Should Bring, a laptop and a mini usb cable. Please install Arduino >16 as well.

In this workshop we will be going through the firmware built by Alex Norman as an example of how to develop midi devices using the avr microcontoller. Topics covered will include:

• The Midi Specification
• The USB Midi Specification
• The Lightweight Usb for AVR  library.
• Programming the avr using avr-gcc

To reserve a place in the class please rsvp at http://tempusdictum.com/tdproducts.html

Posted in Avr Development, Dorkbot, osx-avr | No Comments »

Its not very often that you get to go back to old designs and make improvements. Recently I got to rework a design from last year and build on the collective knowlege of 2 design teams and 3 design cycles.

Does practice make perfect? We shall see.

The first run.

Last year I got to build the electronics for a stationary bike racing system. The system had a large ballfield style clock with four hands that were run by these monster stepper motors The initial design was for two bikes done by Percor: a company that makes excercize equipment. Their design used these industrial (expensive and very bulky) cherry hall effect sensors which they loaned us for a race at Lance Armstrong’s bike shop in Austin (http://www.mellowjohnnys.com/). My job for that cycle was to replace Percor’s pic based board with a 4 bike setup.

I broke the stepper driver section into four individual boards. For the processor I built a custom mega128 based board and did the programming in wiring.

Second iteration.

When the Austin race was over Percor needed their parts back so I got to rebuild the sensors. I found some allegra hall effect sensors which were a small fraction of the cost of the cherry’s (like (75c<$25.00)X4). As an attempt to get a zero indicator on the clock I experimented with a triangle based design

While I never did get this particular part of the clock to work correctly the triange stuck as a shape that I liked working with.

I also wanted to replace the cat5 wire used in the Percor design with with less expensive phone cord. (I got a panicked phone call  from Texas and had to remotely direct someone how to get some very expensive ethernet cable on a weekend: it was not cool). To do this I put a non inverting buffer on the sensors and since buffers come in 6s I put an indicator led on the sensors output. In the practice of setting this up for the next race, the blinking lights were invaluable.

Third Time Charm.

A few weeks ago I was asked about another race setup in SanFrancisco. They were going to use a system called open sprints for the display but the open sprints people were out of their hardware for the sensors. So I got a 3 week timeline to put together a sensor and hardware interface that would be compatible with open sprints.

Open sprints (www.opensprints.org) is an open source ruby based software which takes information from an arduino and presents the race data in a way that can be projected instead of having a physical race clock. The only thing that needed to be built was the input side.

So I went back to what I liked and didn’t like about my earlier design and compared and contrasted the opensprints, the percor and my designs to come up with a new system which I could then have fabbed by our local pcb fab (sunstone.com). Looking at the opensprints design I revisited the hall effect sensors and found a set of sensors to experiment with and began to lay out my boards.

I had intended to use the dart design with a through hole led and a throuch hole (sip) sensor and then have some laser cut transparent plastic which could then be “lit” up by the led on the board. A second piece of opaque plastic would be cut to insulate the bottom of the board.

After talking to some of my ee freinds I decided to replace the on board drivers with a single schmidt trigger on the other end of the sensor cable (the percor design used these as well) When selecting the parts I found myself looking at a few options for the rj11 connectors. I ordered a few of each as well as both sip and the origional smt sensor from last year.

Who needs plastic?

When I got the parts I started looking at these rj11 connectors and rethinking things. The connectors were surface mount and shielded. The shielding wasn’t needed but they matched the un-soldermasked boards in texture in color they were about 7 cents more expensive apiece but they looked futuristic.

I went back to surface mount only. If I got rid of the sips and used the surface mount rj11 mounts then the bottom of the board would be shield/ground no insulation needed. The metal from the surface of the board and cable connector would reflect the light from the led and if any attention were payed to the layout of the traces it would look cool!

Even in the hand rolled prototype!

Who needs an Arduino?

At this point given Paul Stoffregon’s (pjrc.com) “teensyduino” software and his 90usb based boards there is no reason to buy any other arduino or arduino clone. ( at least in cases where you need usb to serial solution — in cases where usb-serial is not needed the dorkboard rules My first thought was to do a carrier board for on of Paul’s boards and adapt the opensprints code for the inverted inputs. The opensprints code needs to be adapted to invert the input signal and to adjust the registers for the different processor but using the teensyquino codebase that should be simple enough.
In this application however, the board was so simple that it made more sense to just adopt the eagle design for my at90usb162 board (the benito).

Tomorrow I get the boards from sunstone and I should have the hardware built out by late friday. The customer will be in portland saturday.

Does practice make perfect? We will let you know by next week.

Posted in Avr Development | 1 Comment »

While I am wrangling with the appropriate board design, I needed to get started working with the underlying software so I ran up one of the six samples I was able to get from Cascade on a tqfp adapter from measure explorer.

The AtMega32U4 http://www.atmel.com/dyn/products/product_card.asp?part_id=4317 is the midrange model in the atmel usb chipset. It follows a new standard naming convention that atmel is adapting U for Usb 4 is for the 40 pins 32k, there is another 32K part the U6 which has the same pinouts as the 90usb646/647/1286/1287. The U4 does not have a legacy pinout however the q1000 price for this board is around $2 which makes it a very powerful chip for the money.

Dfu-Programmer.

There is a recent release of dfu-programmer (0.4.6) but it seems that they havent read the atmel doc on the signatures for the dfu recently. http://www.atmel.com/dyn/resources/prod_documents/doc7618.pdf recently.

I need to check the memory and eeprom sizes against the datasheets for the parts. However the table in arguments.c should have the following entries; added new parts, corrected 64x and 82 signatures. (I will resubmit this patch).

/* ----- target specific structures ----------------------------------------- */
/*  { "name",         value,            ,device_type, chipID,VID   , MemSize,FPSize,abt,ifclass,eepgsz,eepmemsz} */
static struct target_mapping_structure target_map[] = {
    { "at89c51snd1c", tar_at89c51snd1c, device_8051, 0x2FFF, 0x03eb, 0x10000, 128, false, true,  0,   0      },
    { "at89c5130",    tar_at89c5130,    device_8051, 0x2FFD, 0x03eb, 0x04000, 128, false, true,  128, 0x03FF },
    { "at89c5131",    tar_at89c5131,    device_8051, 0x2FFD, 0x03eb, 0x08000, 128, false, true,  128, 0x03FF },
    { "at89c5132",    tar_at89c5132,    device_8051, 0x2FFF, 0x03eb, 0x10000, 128, false, true,  0,   0      },
    { "at90usb1287",  tar_at90usb1287,  device_AVR,  0x2FFB, 0x03eb, 0x1F000, 128, true,  false, 128, 0x0FFF },
    { "at90usb1286",  tar_at90usb1286,  device_AVR,  0x2FFB, 0x03eb, 0x1F000, 128, true,  false, 128, 0x0FFF },
    { "at90usb647",   tar_at90usb647,   device_AVR,  0x2FF9, 0x03eb, 0x0F000, 128, true,  false, 128, 0x07FF },
    { "at90usb646",   tar_at90usb646,   device_AVR,  0x2FF9, 0x03eb, 0x0F000, 128, true,  false, 128, 0x07FF },
    { "atmega32U6",   tar_atMega32u6,   device_AVR,  0x2FFB, 0x03eb, 0x07000, 128, true,  false, 128, 0x03FF },
    { "atmega32U4",   tar_atMega32u4,   device_AVR,  0x2FF4, 0x03eb, 0x07000, 128, true,  false, 128, 0x03FF },
    { "atmega16U4",   tar_atMega16u4,   device_AVR,  0x2FF3, 0x03eb, 0x03000, 128, true,  false, 128, 0x01FF },
    { "at90usb162",   tar_at90usb162,   device_AVR,  0x2FFA, 0x03eb, 0x03000, 128, true,  false, 128, 0x01FF },
    { "at90usb82",    tar_at90usb82,    device_AVR,  0x2FF7, 0x03eb, 0x01000, 128, true,  false, 128, 0x01FF },
    { NULL }
};

Then we test.

static
dfu-programmer atMega32U4 get bootloader-version --debug 20
     target: atMega32U4
    chip_id: 0x2ff4
  vendor_id: 0x03eb
    command: get
      quiet: false
      debug: 20
device_type: AVR
------ command specific below ------
       name: 0

Bootloader Version: 0x00 (0)

(after reading the datasheets for the 3 classes of avr usb chips and looking at the way that the avr-gcc library calls the cpu names there are some changes to the above that I will post later.)

Next up some code.

Tried running up the midiGate software that I wrote last week and found my first bug for the chip in avr-libc

UBRR1 is redefined in iom32u4.h

#define UBRR1 _SFR_MEM16(0xCC)

#define UBRR1L _SFR_MEM8(0xCC)
#define UBRR0 0
#define UBRR1 1
...

Which results in lvalue errors errors when trying to set the register to a given value. Setting the bit values as in some of the other registers seems to resolve this issue.

#define UBRR1 _SFR_MEM16(0xCC)

#define UBRR1L _SFR_MEM8(0xCC)
#define UBRR_0 0
#define UBRR_1 1
#define UBRR_2 2
#define UBRR_3 3
#define UBRR_4 4
#define UBRR_5 5
#define UBRR_6 6
#define UBRR_7 7

#define UBRR1H _SFR_MEM8(0xCD)
#define UBRR_8 0
#define UBRR_9 1
#define UBRR_10 2
#define UBRR_11 3

This is a pretty braindead error so I am sure that its been resolved by now. I need to see if it is fixed in 1.6.3 or the current release candidate (since AvrMacPack is out of sync and has 1.6.2) And yes this is the case.

We have a device!!!

Fix(ing) it!

Both of these issues were easy enough to fix within the source of the utilities but to make it possible for everyone else to use the new chips some body needs to Fix it! So I went about looking up the chain to get these issues resolved over the long run.

Dfu Programmer.

dfu-programmer is a source forge project so I logged an error through the sourceforge project page. https://sourceforge.net/tracker2/?atid=767783&group_id=147246&func=browse A new release has been made (0.5.0) which resolves the issue above.

Avr-Libc

Since avr-libc is a savanaha project and so making bug requests is a little different. http://savannah.nongnu.org/bugs/?group=avr-libc Fortunately (sort of) I had already been around the buggier parts of the release in question (1.6.2) when I first ran up the at90usb647. When Eric Weddington released the June rev of WinAvr (with avr-libc 1.6.3) I thought I had seen the last of it as obdev released the coresponding AvrMacPack. The bug noted above was fixed in 1.6.3 and I was able to verify that using my windows vmware session. For some reason this was not the case and AvrMacPack went out with the buggy (for this new chip anyway) libc. I filed a bug report with obdev and followed up with Christian from obdev and Eric until the version descrepency was resolved. The new version of WinAvr just came out and I am waiting to verify that the AvrMacPack version matches WinAvr.

If you are running linux plan on building from source and patching as in the script kept current at avrfreaks (you will need to log in) . http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631&start=0&postdays=0&postorder=asc&highlight= This script has not been updated for the latest winavr but it should at least give you a version above 1.6.2.

Posted in Avr Development | 2 Comments »