Adding ATtiny support to Arduino IDE 1.6.1

March 22, 2015

I recently upgrade from the 1.0.5 version of the Arduino IDE to 1.6.1. Things aren’t completely smooth – in particular, I was using Coding Badly’s cores for ATtiny85, ATtiny84 and ATtiny2313.

Unfortunately, those haven’t yet been updated for the new layout specified in the 1.6.x IDE. So instead I switched for now at least to the damellis cores (which support ATtiny85 and ATtiny84, but not ATtiny2313/4313).

Installing this is a matter of unzipping it in the sketchbook/hardware folder (on my Windows box in C:\Users\{my user}\Documents\Arduino).

In Windows cmd shell:
cd "C:\Users\{my user}\Documents\Arduino"
mkdir hardware
unzip c:\{whatever}\attiny-ide-1.6.x.zip
cd hardware
move ..\attiny-ide-1.6.x\attiny .
cd ..
rmdir attiny-ide-1.6.x

At some point in the future either the Coding Badly cores will support IDE 1.6 (hopefully with the nice variants structure that the damellis cores use) or the damellis cores will do ATtinyX313s.

Advertisements

Using the TinyLoadr to program ATtiny84s

November 27, 2013

I’ve been using the excellent TinyLoadr Shield to program a bunch of ATtiny2313 chips I’ve got. Doing so was easy.

But when I moved over to program ATtiny84s, I ran into a bunch of problems. First, I’d get an error when burning the bootloader:

configuration file for part ATtiny84
avrdude: Yikes!  Invalid device signature.

This was because, although I’d switched all the switches on in the second bank (and off in the first and third banks), I’d neglected to move the three jumpers below them from ATtinyx313 to Other.

Once I did that, I started getting different errors:

avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
avrdude: stk500_cmd(): protocol error

and

avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
avrdude: stk500_cmd(): programmer is out of sync

This is due to a defect in Arduino 1.0. Luckily, more information about the problem is here:

http://code.google.com/p/arduino/issues/detail?id=661

The upshot: I went into
c:\Program Files\Arduino\hardware\arduino\cores\arduino
and edited HardwareSerial.cpp to have the following:

#if (RAMEND < 1000)
  #define SERIAL_BUFFER_SIZE 16
#else
// Was 64; changed to 128 for serial buffer overflow problem
// http://code.google.com/p/arduino/issues/detail?id=661
  #define SERIAL_BUFFER_SIZE 128
#endif

I then reburned ArduinoISP on my Uno, then plugged the TinyLoadr back in. After that, I was able to burn ATtiny84s with no problem.


Upgrading the Arduino Uno 8U2 using Fli

April 14, 2011

The instructions on the Arduino DFU update page are pretty vague when it comes to updating to the latest firmware using the Atmel Flip utility. Here’s what I did to get my Uno 8U2 firmware updated using Windows XP:

  1. Install Flip from the Atmel webpage. If you don’t already have a JRE, you probably want the 20 megabyte package that includes one.
  2. Download the 8U2 firmware. That’s the “Arduino-usbserial-uno.hex” file. The “UNO-dfu_and_usbserial_combined.hex” is the Arduino Uno bootloader firmware for the 328p. If you try installing the 328p firmware onto the 8U2 in Flip, you’ll get an error dialog:
    class com.atmel.flipGui.FileMenuHandler
    Address is out of range.
    
  3. I ended up cutting & pasting the hex file contents into a text editor because I couldn’t figure out how to download a single file from github, and I didn’t want the whole 200 megabyte wad.
  4. Hook up wires and touch them to the right spots on the Uno at the right time as described in this Arduino forum post by pluggy.

    Update: Pluggy’s image has disappeared. Here it is:
    flasheo8u2-1-300x216
    I found it at www.ardumania.es/reflashear-el-8u2/.

    You’ll know you did it right when Windows detects a new device. It took me a few tries to keep the first wire steady enough when touching the second wire. Make sure you’re going to the right pads – you could short out your Uno if you touch the wrong place!

  5. After Windows detects the new device, you don’t have to hold the wires in place any more. Move them to the side so you don’t accidentally short out something.
  6. When the Windows device installer comes up, select “have disk” and install the Atmel USB driver. By default the Atmel USB driver is installed in C:\Program Files\Atmel\Flip 3.4.2\usb\atmel_usb_dfu.inf
  7. Notice that the driver is AT90USB82, not ATmega8U2
  8. Although it tells you that you have to reboot XP when you install the driver, I didn’t bother.
  9. Start Flip from the Program menu
  10. File->Load HEX file->Arduino-usbserial-uno.hex
  11. Device->Select->AT90USB82
  12. Settings->Communication->USB and press Open
  13. At this point, you should be ready to program. Press the “Run” button on the main screen.
  14. Programming is quick, taking about 4 seconds. After it’s done, remove the two wires you put in earlier, then unplug the USB cord and reinsert it.

Once you’ve done that, your Uno should be out of DFU mode and back into normal mode.

You can go to My Computer->Manage->Device Manager->Ports (COM & LPT), right-click on “Arduino UNO” and select “Properties”. Under the Details tab, Firmware Revision should now be 00.01.

Update: Someone mentioned they couldn’t find the atmel_usb_dfu.inf file. Looks like there’s a copy here.


Testing the USBtinyISP on Arudino Uno

April 9, 2011

After building a USBtinyISP programmer to burn new bootloaders to my Uno (and other devices) I wanted to test it before putting it in the case.

Unfortunately, the obvious place talks about programming with WinAVR and other random things that you don’t care about when you’re hot to see if the thing actually works.

Here’s what I did instead (using a Windows XP machine, since that is what’s claimed to cause the least trouble):

  1. I downloaded the USBtinyISP drivers and unzipped them into a directory.
  2. I plugged the USBtinyISP in (before putting the programming cables / case on yet). It was recognized as a USB device, and I installed usbtinyisp.inf from the unzipped driver.
  3. I immediately tried to talk to the device using the Arduino 022 IDE and “Burn Bootloader -> w/USBtinyISP”. It failed with the error message “Could not find USB device 0x1781/0xc9f”.
  4. So I unplugged the device and plugged it back in. This time I got “Initialization failed, rc=-1” which is correct.

Whew, that meant my device was talking – in other words, I’d probably put it together correctly. Next was to see if it actually could program my Uno.

  1. I plugged the 6-connector programming cable in. The red stripe went on pin 1 of the silkscreen of the USBtinyISP, and the pin with a dot on it on the programming header of the Uno. (At first it looked wrong, but when I turned the cable around it was fine. The cable goes across the whole length of the Uno.)
  2. Then I made sure the jumper on the USBtinyISP was off (not supplying voltage).
  3. Next, I plugged the USBtinyISP into my USB port and verified that the green light came on.
  4. After that, I plugged in my Uno (to a different USB port) so it was getting power and was recognized.
  5. Finally, I went to the Arduino IDE and did Tools -> Burn Bootloader -> w/USBtinyISP.
  6. The red light came on for about two minutes to program my chip. After it turned off, I uploaded a sketch to make sure it worked – and it did. “Done burning bootloader.” Yay!

Finally, I put the 10-pin programming cable in and the case on. I had to push the LEDs around a little (the green one was getting pretty close to the USB header). Then I was able to snap the case on and catch my finger in there as well, removing a little skin I didn’t need.

That was it – I now had a good programmer. I did another program with the case on to make sure it worked and I hadn’t broken anything.

Next I’ll look on the Arduino firmware github page to see if there’s any newer boot firmware.


Should I malloc on Arduino?

March 29, 2011

I’ve been defining an Event class for Arduino processing so I don’t have to think quite so hard about timing loops myself. In the process of doing this, I got the following error:

undefined reference to `operator delete(void*)'

I discovered that the Arduino C++ doesn’t include new() or delete(). (Ok, I guess I shouldn’t be calling it C++….)

I did a quick web search and discovered replacement functions… but then I started thinking.

Why did these get removed from the Arduino C++ variant? On a device as limited as the ATmega328, it makes no sense to malloc() from a pool. Might as well just allocate the variables you want. (Or in my case, allocate an array of variables up front). That way, you know you don’t have a pointer leak that will hose you as you run.

So… I think the answer is no, I shouldn’t malloc on Arduino.

(Edit) Unless, of course, I’m writing a library.


Using an Arduino Serial USB board with an Ardweeny

January 30, 2011

This afternoon I joined the world of Arduino hacking. I put together an Ardweeny and hooked it up to an Arduino Serial USB Board. I probably should have used a newer FTDI basic breakout board which supports auto-reset, but I didn’t.

Assembly and Power Up

Putting the Ardweeny together was pretty simple. One word of advice: you do not want to do this without a third hand tool. Even that won’t be enough for soldering the chip onto the headers – you’ll need a friend or some good gentle alligator clips to hold the chip while you do the first tack solders.

I powered it up by connecting +5v of the Ardweeny to +5v of the Serial USB board, and then connecting Gnd on the Ardweeny to Gnd on the Serial USB board. It started blinking right away – always a good sign.

Connecting to USB Serial

Connecting the Ardweeny to the Serial USB board was a little trickier. I used a pair of jumper wires. In one end of each one I stuffed a little clipping of 22 awg bell wire, so I had a female connector at one end and a male connector at the other.

Next, the big (and as far as I can tell undocumented) question: does TX on the Serial USB board go to RX on the Ardweeny and vice versa, or does TX on the Serial USB board go straight to TX on the Ardweeny? The answer:

TX on the Serial USB board (the pin furthest from Gnd on the left side) goes to RXI (the pin above A4 on the Ardweeny v1.1a)

RX on the Serial USB board (the pin just above +5v on the left side) goes to TXO (the pin above A3 on the Ardweeny v1.1a)

I hooked those up backwards and my USB port stopped recognizing the Serial USB board. I had to pull the Serial USB board from the USB hub and plug it back in to continue. (I’m doing all of this through a powered USB hub just to avoid burning out my motherboard’s USB if I make a mistake.)

Downloading Code

Once I’d done that, I sent a program down. The first program went with no problems after I set my COM port and chose the “Arudino Duemilanove or Nano w/ATmega 328”.

Subsequent programs wouldn’t write – I got the following error:

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51

It turns out the Ardweeny is pretty particular about when things get uploaded to it. (This is where the auto-reset function of the FTDI basic breakout board shines, but I didn’t know that since I’d never done Arduino programming before.) So the magic trick to upload is to wait until you see:

Binary sketch size: 1018 bytes (of a 30720 byte maximum)

in the IDE, then immediately hit the reset button on the Ardweeny. At that point, you’ll see the TX and RX LEDs flash on the USB Serial board, and your code should be uploaded.