Go Down

Topic: Bootloader, Firmware, Sketch Relationship? (Read 1 time) previous topic - next topic

kylejudd


It was the Uno Rev3 that I got the MocoLufa stuff to work on, but part of my confusion comes from the fact that I was also evaluating the Leonardo at the same time.  If I understand correctly now, the Leonardo has USB on the Main AVR meaning there is only 1 bootloader/firmware pair, wheras the UnoRev 3 has 2 chips & 2 bootloader/firmware pairs. I was wonding why the Uno had 2 ICSP headers and the Leonardo only had 1.

My goal in all of this is to find a way to have the chip enumerate as a USB Midi Device, yet still be software programable (updatable). Am I correct in thinking that the Leonardo is the better choice for me? I realize I would have to write some of the USB code myself.  Is there anything about the Leonardo or the USB spec that would prevent it from enumerating as a USB MIDI Device and CDC device at the same time?

Thanks,
Kyle

mrburnette

#6
Mar 09, 2013, 03:05 pm Last Edit: Mar 09, 2013, 03:11 pm by mrburnette Reason: 1

<...>
I realize I would have to write some of the USB code myself.  Is there anything about the Leonardo or the USB spec that would prevent it from enumerating as a USB MIDI Device and CDC device at the same time?


I have some VUSB experience with UNO, ATtiny85, and Mini and as a general statement, messing with the USB foundation layer is problematic - primarily due to timing issues.  With HID, key mappings and such can be safely changed, but mucking deeper has been problematic for me... for whats its worth.

The LUFA author's page is here: http://www.fourwalledcubicle.com/LUFA.php and in reading the specs, it appears that the Leonardo will perform MIDI and CDC as the CDC code is implemented in the bootloader section... so that during CDC use the LUFA stack is not active at the same time.  The MIDI personality kicks in after the sketch is loaded and the bootloader resets (exits) the CDC mode (Communication Device Class.)  At least that is the way I read the summary page.

Summary:
LUFA also contains USB bootloaders for the following USB classes:

  • CDC Class, AVR109 protocol compatible (AVRDude)

  • DFU Class, Atmel DFU protocol compatible (Atmel FLIP, dfu-programmer)

  • HID Class, with an included custom cross-platform loader application




Ray

kylejudd


Thanks for the info Ray, I am sure that it will save me some grief.

I have a new idea that might work out better for me.  The plan is to try to use the Uno Rev3 loaded with MocoLufa and write my "sketches" to the Atmega328P through MocoLufa using MIDI Sysex Messages. For those unfamiliar, Sysex (System Exclusive) messages are a part of the MIDI Spec designed to allow bulk data transfers to specific hardware.  You could call it Serial-over-MIDI, and back in the day it was commonly used to send programming information to synthesizers. Of course I would have to write a software app that loads the .Hex file into memory and sends it over MIDI to the Atmega16U2 (MocoLufa), but I am a software developer, and that is my wheel-house.

Then I just need to adapt MocoLufa (or some Lufa project) to strip the Serial data from Sysex messages and write to the Atmega328P in the same manner the native Arduino Serial Firmware does, right?  Is there any reason this shouldn't work? I realize that MIDI works at a funky baud rate (31,250) - is there any restrictions on how fast/slow I can update the Atmega328P memory?

This should allow my device to 1) enumerate as a MIDI device, 2) be reprogrammable, and 3) not expose an additional COM Port to the host OS. This would be the best of all possibilities. I'm gonna do my research and experimentation, but I would appreciate any insight into my plan, especially if anyone knows a reason why this wouldn't work.

Thanks,
Kyle

Go Up