Programmer on USB port

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know there are a variety of USB based AVR propgrammers aroud but I thought that this project would be a way to learn to use the USB with AVR.

My simple thought is to make the target AVR look like an external disk attached to the development computer.

So, to program the AVR one would just copy the object file into that disk. Same would apply to EEPROM and fuse settings.

To read the contents one would do the vice versa - copy those files out of the "disk".

I could also imagine on how to edit the fuse "file" with notepad and then just save the changes - LOL :) and render the MCU totally useless ...

To make this gadget more versatile it could have a way to save the images into the gadget and then do the programming off the computer. I could - for example - climb into my radio mast and then reprogram the antenna rotor controller there just by plugging the gadget and pressing the big red button.

Any experience on USB controllers that are "disk" capable?

I have used a RS232 USB device FT232R and the experience was ... fun :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Any experience on USB controllers that are "disk" capable?

Just use MSD - LUFA (of course!) has the structure in place to do this.

(I've seen a CortexM3 bootloader that works like this - it's a nice idea)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Uh-Oh ... For LUFA one seems to need an AVR that has the USB hardware built in. I am not lucky enough to have those in my cabinet. Instead I do have hundreds of ATmega32:s ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So you have to do it with V-USB - that could be a problem as I have a feeling its support of MSD is either limited or completely non-existent. Why not simply buy the right chip for the job. If you were feeling really adventurous that could even be one of the new X-U chips. (if you don't mind 3V3)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Someone did manage to put together a crude MSD implementation using v-usb although I am not sure it would be up to the task at hand.

http://forums.obdev.at/viewtopic.php?f=8&t=3399
http://forums.obdev.at/viewtopic.php?f=8&t=5692

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have also tooked into that option as well - not the V-USB as such but bit banging the USB myself - actually creating a library much like that on my own.

The problem here is the minimum clock speed requirement. My puny ATmega32:s do not come near enough with their 8MHz. 12 MHz is required.

Well - I do have another 800 pieces of ATmega851516PI in my closet so maybe it is time to make some use of those. They can clock 16MHz. The downside is that these are in 40-pin PDIP whilst the ATmega32 would have been in a comfortable TQFP. Seems that one cannot have this both ways. I hate drilling holes!

I also have a flock of DS75176 tranceivers which propably could find their use here.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eskoilola wrote:
My puny ATmega32:s do not come near enough with their 8MHz. 12 MHz is required.
According to the DS it's 0-16 MHz for ATmega32. Even the ATmega32L will probably be fine run slightly out of spec so long as Vcc is 5 Volts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Will your AVR have sufficent free RAM remaining to hold the object file the PC is giving it? Or are you planning on writing the file into flash?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whoa !
I just started REALLY reading the documentation of FT232R and what do I see...

This device has a so called bit bang mode which obviously makes it act as a raw material distributor between the host and the gadget. So using the device in this mode should do the trick. Obviously all the USB layers have to be coded or Monkey-Pasted from some existing code - but this makes it doable.

LOL :) - not enough memory !

ATmega32 has not even near the amount of memory required for this sort of task. One has to add more. I prefer using static RAM with address latching with 74HC373.

For longer term starage I have two options:
- DiskOnChip device MD2202 for bigger needs
- Macronix MX29LV160ABTC for this sort of need

Of course all this forces to create a bus system since ATmega32 does not have that many I/O lines after all. It is not really complex - just tedious to design the PCB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

This device has a so called bit bang mode which obviously makes it act as a raw material distributor between the host and the gadget. So using the device in this mode should do the trick. Obviously all the USB layers have to be coded or Monkey-Pasted from some existing code - but this makes it doable.


But it's not going to enumerate as MSD is it? I presume the bit-bang mode is either some variant of HID or maybe generic/vendor specific. The bottom line is that Windows is not going to see it as a "drive" for drag/drop of files or editing fuse.txt with notepad or whatever.

Apart from a sector buffer or two (which should easily fit in 2K) I can't see why you need a lot of memory? You're surely not going to try and buffer the entire new firmware image to be programmed are you? Write it to the AVR as DOS/Windows/whatever writes it to the "drive".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Esko, it's nice to hear from you again after a couple of years of silence. I have nothing to add to the discussion except good luck!

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually - it IS my intention to store the entire firmaware into the device. This is needed if I intent to use it while dangling on the tip of my radio mast.

This device has the VID and PID in EEPROM - so it should be possible to alter those. This is the first step in altering it into a MSD.

But, You're right - this is propably going to be the hard way to do MSD emulation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eskoilola wrote:
This device has the VID and PID in EEPROM - so it should be possible to alter those. This is the first step in altering it into a MSD.
As I am sure you are aware, there is much more to usb device class enumeration than simply changing the VID/PID.
To me one of the main attractions of FTDI chip is that you don't need to fork out for your own vendor ID.