Sunday, September 27, 2009

So.. I just got this Arduino..

So, I decided (for no particular reason, I might add), to order a few geek gadgets. Namely, a couple of Arduino's, with all the fixin's. (Mega and 3v3 Pro, XBee's, with the obligatory XBee Shield and XBee Explorer from Sparkfun.)

Good stuff, I really like that I can get straight to programming it (yes, I have been staring at a stupid blinking LED for several days now, wondering quietly what I was thinking when I placed the order..) and I like how I dont have to spend days assembling all the "ancillary" circuits just to get the damn thing working. Most of all I like the fact that it can be programmed with the Arduino software and the bootloader. Which means, of course, that I have a platform for programming microcontrollers with simply a USB-cable and free software. No need to buy (or solder) an expensive (or cheap) programmer, no need to make a Decision as to which architecture to go with. Buy it, and go. Hassle free. Or so I thought..

So for the not-so-good stuff. Full disclosure; I've owned these things for exactly 3 days, so my knowledge of the hardware and software may not entitle me to an opinion.. I have one none the less. I have also next to no experience with electronics. That only puts me right in the target demographic for the Arduino.

From my understanding, the makers of Arduino (and the related projects) put this package together so that people could get started with HW-hacking quickly and painlessly. Which works just fine, up to a point. You see, the arduino GUI and language hides so much of what's going on under the hood that it becomes a pain to map the real hardware, lets start with the AVR1280 datasheet, to the Arduino software.

I quickly figured out that my path of progression would be something like

  1. Make the LED blink using the Arduino GUI
  2. Move on to AVR Studio and AVR GCC to get more control and understanding of the operation of the chips
  3. Use AVR Studio with ASM.
  4. Sit back and congratulate myself for understanding the AVR8 architecture, as well as buildtools

That last point would have to be done quietly, lest someone should overhear me. It would not do.

So, as I mentioned, Step 1: blinking LED, CHECK.

Moving on to Step 2 was more of a pain than I imagined. To recap, I have now written the obligatory blinking LED using the actual registers etc in AVR Studio 4, compiled it, and now I want my Arduino to execute it.

But the Arduino GUI gives no clue whatsoever on how the hex-file gets to your board. A little Googling will reveal it uses AVRdude, which sounds just fine. Of course, things arent a simple as that. I ended up digging through the sourcecode for the GUI to find the interesting bits, an lo and behold, you can add "upload.verbose=true" to your preferences file, which will output all the details on how it uses AVRdude! Success! (For the interested, it's in svn/trunk/app/src/processing/app/debug/AvrdudeUploader.java)

Erm.. No. For reasons I don't fully understand, it doesn't work with the stock AVRdude. Take the following example:

avrdude -Uflash:w:Test.hex:i -cstk500v1 -P \\.\com4 -pm1280 -vvvv -b 57600 \
-D -C\Ole\arduino-0017\hardware\tools\avr\etc\avrdude.conf

avrdude resolves to the version bundled with WinAVR, which I've installed for use with AVR Studio. It is pretty much an exact copy of what the Arduino GUI does. Still, it spits back at me

D:\Ole\Avr Studio Projects\Test\default>avrdude -Uflash:w:Test.hex:i -cstk500v1
-P \\.\com4 -pm1280 -vvvv -b 57600 -D -C\Ole\arduino-0017\hardware\tools\avr\etc
\avrdude.conf

avrdude: Version 5.6, compiled on Mar 5 2009 at 09:59:30
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "\Ole\arduino-0017\hardware\tools\avr
\etc\avrdude.conf"

Using Port : \\.\com4
Using Programmer : stk500v1
Overriding Baud Rate : 57600
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv:
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: Send: Q [51] [20]
avrdude: Recv:
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

avrdude done. Thank you.
Thank you, indeed.. So. Now what? Turns out, someone must have patched something. If you specify the AVRdude.exe that comes with Arduino, it all works like a charm..

\ole\arduino-0017\hardware\tools\avr\bin\avrdude -Uflash:w:Test.hex:i -cstk500v1 -P \\.\com4 -pm1280 -vvvv -b 57600 -D -C\Ole\arduino-0017\hardware\tools\avr\etc\avrdude.conf
Is this behaviour documented? Quite possibly. It didn't show up in the first 10 results from Google (that I checked). My current guess is that is has something to do with DTR resetting the Arduino. If I use stock AVRdude, and reset the Arduino at precicely the right moment, it will load correctly. Topic for another post..

So, thats one hurdle overcome. Strangely, I couln't really find a cookbook recipe on how to use AVR Studio 4 with the Arduino.. Here is one.

1. Add "upload.verbose=true" to the preferences file of a working Arduino. (This must be done with the GUI shut down, or it will be overwritten)
2. Observe the output
3. Write and compile your program in AVR Studio
4. Upload, using the AVRdude from the Arduino, and using the options observed in step 2.
5. Rinse and repeat.


1 comment:

  1. I'd like to thanks you for for this blog, it was really helpful for me to bootload with a XBee Shield. This has been bothering me for a long time!

    I have a Series 1 XBee, and all I had to do is set DIO7 modes on each device, and I can remote bootload using the Ardurino IDE 021 and XBee explorer...no command line AVEdude needed, no sleep issues.
    As of the latest Linux kernel (2.6.32-25 Ubuntu), the jumper/resistor between DTR and CTS isn't needed anymore either (does not work with the jumper anymore). Perhaps new FTDI drivers got installed with the kernel?

    ReplyDelete