I'm thinking of building a project with a very large number of LEDs and so I'm looking into using ATtiny chips as controllers for groups of them. I don't have much equipment outside of my mbed and I've been looking into building a USB ATmega/ATtiny programmer (something like this) but it occured to me, I alreday have an mbed!

Could an mbed program be written to program ATMEL (or even PIC) chips? This'd be a huge save in money for myself but also for loads of new hackers and makers who would look to the mbed as the device that does it all.

I'm about to make an order from Farnell so if anyone out there has suggestions as to which ATtiny etc. I should start with I'll order and try and write a program like this staright away!

Great to see some of the mbed team at the Maker Faire UK, thanks for all your hard work!

Is the programming protocol open?

Does it need any funny voltages (like 12V)?

Requirements for tight timing?

Do you know how the programming tools on PC talk to the programmer?

I know very little to absolutely nothing about the details of the programming (but I've programmed a few in my time) however it looks like people have built their own programmers (which implies the specification is open at least to some extent):

• AvrUsb500 -- an open source Atmel AVR Programmer
• AVR DUDE
• USBtinyISP (Oomlout)
• Original USBtinyISP

So I'm certain it would be possible to build the required circuit to get an mbed programming an AVR chip (or PIC chips, which appears to be easier tho less documented) and potentially also feasible to program the mbed to perform the tasks of the ATtiny in the serial-port—to—microcontroller section of the USBtinyISP.

Hopefully we'll be able to find someone with some knowledge of the AVR system, because I think this'd be a fantastic use of the mbed! Its only a shame I didn't think of this earlier, both Oomlout and mbed were at the Maker Faire this weekend!

Cheers!

Okay, looks like AVR uses SPI protocol, so it shouldn't be too hard. I found relevant documents on Atmel's site: AVR910: In-System Programming and AVR068: STK500 Communication Protocol. You will need the first to talk to the AVR chip and the second to talk to the programming software on PC. Some parts of the firmware of other adapters might be reusable.

(That second link should point to the AVR068: STK500 Communication Protocol)

Looks like I've got my work cut out for me! Thanks for the links, I'm going to try and find the code behind what's in the AvrUsb500 as the mbed offers a simple way to turn usb (serial) into SPI messages, hopefully I'll be able to get something working.

If anyone out there knows anything in detail about the AVR programming process please get in touch!

Are you talking about ISP or ICSP?

Ummmm, you've lost me there :P I'm new to microcontrollers, I was wondering if I could forgo having to buy a programmer by just rigging a simple circuit up with mbed! Why do you ask?

I'm actually very interested in this topic myself. Having used homebrew JTag programmers on computers with serial ports, I think it'd be nice to be able to program an AVR or PIC using an mBed through the USB port, because it would essentially allow one to program the chips on any platform with a USB port. Let me know how this goes.

Great idea! I'll always turn to mbed when I need a USB-UART bridge now just because it is easily to hand and I know it'll work on all platforms, so love the idea of it being used as a universal programmer too :)

A quick look suggests projects like USBtinyISP use the SPI interface so no high voltages etc, and use avrdude as the command line program with the logic to program chips, suggesting it supports a range of different programmer protocols. That suggests the hardware and programming logic is in place already.

I suspect then building a USBSerial-SPI bridge is the best approach (i.e. no special USB interfaces needed etc), and it is more about navigating these protocols to find out which one is simplest and most suited to that approach. It could be the AVR910 protocol, but just because it said "simple" in the avrdude intro; there may be a better choice.

Simon

Years ago before mbed, I used to play with AVRs and I used to have one AVR programming another over SPI. I seem to recall the protocol was something like, reset the device with an ISP-like pin held low, and then just squirt the binary in over SPI starting at 0x0  (with some handshaking and pausing while the flash writes).

You could use an mbed's SPI interface and a couple of GPIOs to reset AVR, put it into bootloader mode, and then fill the AVR over SPI. Better still, you could drag and drop the AVR program file onto the mbed Flash Disk and then have the mbed use the LocalFileSystem to fopen the file and load it into the AVR. Drag and drop programming for AVR via the mbed :-)

Just an idea ...

I need some help on this topic. I wrote a program that tries to use the AVR910 protocol, but every time I check for 0x53 when I program the third byte to enable programming mode it fails. The programming enable sequence as I see it is to write 0xAC, then  0x53, then check for 0x53 returned when writing 0x00, then if successful write 0x00. I've printed each time I do an spi.write (i.e. I do pc.printf("%x",spi.write(0xAC)); ) and it seems like I always get back FF FE or 0. For the format of the spi on the mBed I used pins 5,6,7, with 8 bits per frame and 0 POL and 1 PHASE (i.e. spi.format(8,1); ), and with the default 1MHz. I used some protection resistors with values of 220 and 470 on MISO, MOSI, and SCK. I also didn't use an input on CLK because I thought the internal oscillator would work. I may try to implement the parallel programming protocol if no one has any ideas on this. Thanks.

Hi Chester,

In a previous life, I was able to program one AVR from another and I recall that the SPI interface worked pretty well once it spring into life.

Just taking a very quick look at http://www.atmel.com/dyn/resources/prod_documents/doc0943.pdf there are a couple of tings to check.

Firstly, you've not mentioned how you are driving nRST. It looks like you have to ensure SCK is stable before trying to program, and it suggests achieving this by pulsing nRST high. You'll also have to do this when you do chip erase.

Secondly, how fast is the internal RC oscillator on the part you are trying to program? I recall they are all about 4MHz. The doc suggest that the SCK has to be low for >1 XTAL cycle and high for >4 XTAL cycles. If you are running SPI at 1MHz and using the internal osciallotr at 4MHz, you might well be violating this. Try winding your SPI clock back to 100kHz or soemthing - you can optimise for speed when it works!

I couldnt find any mention about using the internal RC oscillator. You could always try setting up a PWM out at 500kHz as use it as the system clock for the AVR.

Hope that helps.

Cheers,
Chris

Thank you for the helpful tips Chris. I looked at the ATMega8/88/168 datasheet and found that the internal oscillator was 125kHz, and so I set the spi frequency on the mbed to 32kHz (the datasheet says low > 2XTAL cycles and high  > 2XTAL cycles, but I wanted to be sure). After a few failed attempts I tried the pwm on the mBed hooked to the XTAL1 of the ATMega with 50% duty cycle at 1MHz. This too failed...that is until for kicks I tried to measure the frequency of the SCK line. It seems that having my DMM hooked up to the SCK line stabilizes it and allows for successful data transfer. I successfully read the signature byte as 1e (i.e. manufactured by Atmel), which made me curious to see if my previous setups were also correct save the stabilization of the SCK line. And, it turns out that using the internal oscillator and an spi at a frequency of 32kHz, as long as you have a DMM measuring something on SCK to stabilize it, you get good results. Now, my question for now is how do you stabilize SCK without the use of a DMM? I will now attempt to flash the program onto the uC and I'll post results soon. Thanks for the troubleshooting help.

Chester

Hi Chester,

Great to hear that you've got something working - at least you've proven that what you were doing was right.

The first thing that sprung to mind was ringing cause the AVR to see multiple clocks, but I'm not sure that would be a problem at 32kHz. It looks like you already have a 470R resistor in series with the SCK line, so you could also add a capacitor to ground to make a low pass filter, and surpress any ringing. You might need this sort of circuit if you hook up an external oscillator and run SPI at a higher speed.

It could also be a bad connection somewhere that is made into a good connection when you press the DVM onto it, i;ve certainly been cought out by that before.

Let us know how you get on.

Cheers,
Chris

Just to keep this thread updated:

The problem with the SCK line turned out to be the resistors to the SPI port on the AVR. I took them off and connected the two SPI ports directly and the communication was stable. I then implemented my programming algorithm which basically loaded a word into each address, low byte first, until 64 bytes were loaded, and then I wrote the program page.

However, I am now having trouble getting the write function to actually work. I know the values I'm writing are getting through, because I'm reading the value echoed back from the AVR, and it lags by 1 as the protocol says it should. But after writing all of the pages that the hex file gives me I try to read a specific memory location and check the values, and the values are wrong...consistent...but wrong, and no obvious pattern.

I don't have time tonight, but tomorrow I will try writing only a few program addresses and writing the page after each word I load to try to find where my error is. As a side note, I know it's not the reading instruction, because I got a fresh AVR out and read the fuse byte correctly as the default value that they ship with.

Chester

Okay. After much head banging and failed programming attempts, I actually acquired a mkII programmer from a professor's lab. I then programmed the ATMega88 with a hex file and attempted to read the values using my mBed. In this way I managed to determine one key problem...the Atmel ATMega8/88/168 datasheet contains faulty information. In the document they say "The Flash is programmed one page at a time. The memory page is loaded one byte at a time by supplying the 6 LSB of the address and data together with the Load Program Memory Page instruction." and "The Program Memory Page is stored by loading the Write Program Memory Page instruction with the 7 MSB of the address."

HOWEVER, the memory page is actually loaded with the 8 LSB...i.e. 0xFF max. The way I determined this was after reading the programmed chip at all possible 0x00 LSB locations (i.e. I read LSB 0x00 and MSB 0x00-0x3F) and noticing that the first word was showing up everywhere where MSB & 0xF was '0' (i.e. 0x10,0x20,0x30) suggesting that any bits past the least significant 4 of the MSB were ignored. Then I decided to read LSB 0x40 (if the 6 LSB were true, this would not be a valid value for the spi load instruction). Much to my combined chagrin and delight I read the next word in the hex file. Thus, I changed my program to load bytes using 'address & 0xFF' rather than 'address & 0x3F' and the mBed programmed the ATMega88 perfectly. I then generated a hex file that was ridiculously long to make sure that the concept scaled, and it did. Thank you for all of the advice and helpful pointers, the mBed can in fact quite easily program an AVR chip given correct datasheet information XD I can post the project if anyone's interested.

Next I might implement an AVR programmer that uses VUsb and SPI to program other AVRs using the same protocol. I realize that USBasp already does this, but I think it'd be fun to roll my own.

Chester Hamilton

Hi Chester,

Impressive work! If you're still willing to post the project, I'd very interested in taking a look as I have an AVR chip I want to program with mbed.

Cheers,

Aaron

Hi Aaron,

Sorry, I've been very busy these past few weeks, but I will post the code soon (this weekend hopefully).

Chester Hamilton

No worries; I've come up with a solution that seems to work (which you can find here AVR910: In-System Programming using mbed if you're interested), but it would be great to compare it to yours to see if I've missed anything or where things can be improved.

AVR_SPI_Programmer_v2 Here is my program. I noticed that yours was object oriented...I took the C-style approach. I should also mention that I forgot to add a macro at the top for filename...so it's restricted to "avr" haha. My main problem with this program was that when I programmed each page I needed to use the 8 LSB when the datasheet said the 6 LSB. I'm not sure if the ATMega88 is just quirky or if that is the norm. In any case, this at least worked for me on an ATMega88, and I plan on using the ATMega88 to build the AVRasp programmer.

Cheers,

Chester Hamilton

I successfully recompiled the usbasp source code for the ATMega88, burned it using the mBed, and built the straightforward circuit for it. Currently it works sporadically in windows vista due to some sort of driver issue, but works like a charm on linux. I already got it to program the recompiled usbasp firmware to another ATMega88 and burned the required fuses, and verified that it was successful. If anyone has an interest in doing something similar, drop me a line and I'll help out as best I can.

Cheers,

Chester Hamilton

Amazing! I'm excited you guys have put the effort into making this work! Unfortunately I still have no clue about AVR programming, but I'm more than happy to experiment and write up my findings for everyone else!

Chester, do you have any information I might find useful for experimenting with the three AVR chips I have at my disposal? (atmega8a, at89s51 and attiny14) - rough circuit diagrams for the ATMega8 you've tested would be really handy.

If I can I'll get a wiki page up here with details for programming AVR chips with an mbed (for newbies like myself!).

Thanks!

I tried both programs on a Atmega1284p. Both worked in programming the information but failed to read for verification purpose.

On the AVR data sheet, it mentions that data is clocked on rising edge during write and falling edge during read. Could that be the problem? How do I make sure?

Thanks.

anything you want to know, code to download, folks eager to help via the forum, on AVRs avrfreaks.net web site and user forum. The Atmel AVR ISP Mk II is the standard and well worth its modest price. Or the Atmel Dragon board.

Lots of people use serial/RS232 bootloading, or USB. Here's a low cost AVR mega328 with USB built-in and on a plugin http://www.pjrc.com/teensy/index.html

But... using an mbed as an AVR ISP is doable. But, er.

Hey qiangbo,

First of all, the data clock edges shouldn't really come into play here since this is basically acting as an ICSP programmer, and so all of the hardware specifications are handled through the SPI port of the mBed.

I just took a brief look at the datasheet for your Atmega1284p. It should be noted that when I wrote that code I had the very specific objective of programming an Atmega8 for use in a USBasp programmer (http://www.fischl.de/usbasp/) and so I hard-coded the lock and fuse bits according to my needs. Thus, I'd ask that you set edit these lines:

00206     write_lock_bits(0xFF);                  //1111 1111
00207     write_fuse_bits(0x62);                  //0110 0010
00208     write_fuse_bits_high(0xDF);             //1101 1111
00209     write_extended_fuse_bits(0xF9);         //1111 1001

to the defaults as listed in your Atmega1284p datasheet (or to whatever settings you need) (pp. 291-293 http://www.atmel.com/dyn/resources/prod_documents/doc8059.pdf).

Also, as mentioned in the program description the page size should be changed:

00013 #define MAX_PAGE_SIZE (64 >> 1) //divide max page size by 2 to get number of words per page 

(change the 64 to 256 for your particular microcontroller).

Lastly, I'd ask for a copy of your code, since I realize my code has the read functionality but does not actually exercise it in the published version.

Cheers and good luck,

Chester Hamilton

Note: I wrote this back when I was relatively new to programming, so I realize the code isn't the most readable, but I'm willing to help if you have any further issues/questions.

Thanks, both you. I've put the code in here:

http://mbed.org/users/qiangbo/programs/TestAVRISP/m39lru

I think I've configured according to atmega1284p's specs.

I understand there are chips on sale that take care of bootloading by itself already. It is kind of my own personal interest to explore and it is fun. Plus, if you want to put a mbed and a AVR chip in a single board and wish to have a single usb line for programming both, it might be helpful.

Bo