This is just ideas I have, and would like comments from those with usb knowledge on whether I'm barking up wrong trees. (I'm late to the USB scene).
I have a USBKey, Dean's LUFA drivers, and a brain that doesn't easily wrap itself around things pertaining to USB. Anyway, I like Mass Storage devices, since no 'special' drivers are needed, and any os (half-way modern at least) can 'talk' to it. I would also like to communicate with the avr from the pc, but do not want to deal with drivers (dll's or whatever the unixes use). For example, the USBKey for its built-in bootloader uses drivers (libusb+inf I think), the rs232-usb on the Win side you need an inf, and using HID for 'general' comm use you need to talk to a driver, etc. (I"m not an expert, so this is just what I understand to be the case).
Now I suppose one could learn to use these things, but I'm thinking I want to communicate by way of Mass Storage instead. Any os can deal with files, any programming language can deal with files, so I figure why not communicate with the avr as a file based device (or 'block' device, I guess).
I took the USBKey, the LUFA drivers, and made myself a 512 byte 'ram' drive (1 mbr, 1 fat table, 1 dir sector, 1 data sector). After playing around a lot, I got it to the minimal amount of data needed in the mbr,fat,dir to make it work without bringing Windows to its knees (Windows is one 'baby' os- it can choke on about anything you feed it that it doesn't like in the mbr/fat/dir). (Also for some reason, Windows needed at least 8 physical sectors to be happy, even though my ram drive was only 4 sectors). When booting to Fedora via a live cd, it was easier to please (and never started choking when things were screwed up).
The 'ram' drive as a ram drive it not real useful by itself, but it does provide a 'window' in which to communicate.
Next I made 3 dir entries- FLASH.AVR, EEPROM.AVR, and SRAM.AVR, and generated a fat table to match (along with appropriate file sizes, and an increase in the 'drive' sector count). Depending on which sector was going to be read by the pc, it would return either the ram based sectors (0-2, mbr/fat/dir), the flash (next 256 sectors), eeprom (8 sectors), or sram (16 sectors, io addresses are now returned 0 as I didn't want to read them as not all can be read without side effects). So basically I can plug in the USBKey, read the 3 files which read flash, eeprom and sram (pretty fast, too).
Right now, I can only read these files, but there is no reason writing can't be done to flash/eeprom/sram (and io with some extra care). A bootloader comes to mind- where the 'upload' is simply an upload of a binary file.
There are many variations one can dream up, and I'm sure this is 'old news' to those that deal with anything bigger than a little avr. (I think I'm into unix territory, where 'everything' is a file. Or something like that.)
So, is Mass Storage Misuse a bad idea, good idea, unnecessary, or none of the above? Assuming I want to write my own app to communicate to an avr via usb, is there an easier way than making it 'file' based as I am attempting? (and can be cross platform compatible). I suppose the cdc device would be the 'standard' way to go, but then I have to deal with serial port programming on the pc side, which is not as easy as 'file' programming.
I can probably post my examples for the usbkey if anyone is interested (its not very pretty at the moment, though).