I can not seem to find a clear explanation of the difference between Bootloaders, Firmware, and Sketches. There is a specific dilema I am trying to sort out that I will get to in a sec. I am a software developer with 15 years experience, but I am just now getting into chip programming. I have read through all the tutorials, and have had great success getting my Arduinos to do what I want, but I am having some difficulty understand the true definitions of Bootloader, Firmware, and sketches.
My example:
I am making a USB-MIDI Controller. I started by writing a sketch that sends MIDI Data over the serial port, and I had no problems reading the data in my software via the serial connection. But since I want the Arduino to be recognized as a true MIDI device, I reset the board, used "Atmel Flip" to upload MocoLufa to the Arduino. Sure enough, everything worked as planned. My original sketch remained on the chip and worked perfectly with MocoLufa.
So why didn't reseting the board and replacing the firmware (with MocoLufa) erase my original sketch? Is MocoLufa really acting as Firmware or a Bootloader, or both? Having looked through the source for MocoLufa and the original sketch (Core stuff included), I don't see them working together as 1 executable. Is the chip running 2 executables seperately?
There are two micros on a typical Arduino Uno or Mega type board, the main AVR micro and a AVR USB chip usually loaded with firmware to act as a USB serial converter chip for the main AVR chip. When you loaded the MocoLufa firmware it was loaded into the 16U2 chip not the main avr 328P or 2560 chip. So MocoLufa must just allow the USB chip be be better/easier to interface with Midi stuff then the normal COM port serial that the standard set up uses. I'm not really Midi aware much.
Firmware = all the code loaded onto a microcontroller chip.
Bootloader = small software program that is burned into high flash memory to be the main means to burn user code into the reset of the flash memory. Once user's code is loaded the bootloader is no longer used or needed by the users code in the arduino environment.
Sketch= Is just arduino's 'cute name' for the source file you create in the IDE editor, which you then compile and upload, which then becomes the firmware that is loaded into the main AVR chip on the board.
Prepare to get various responses since the answer to your question is flavored a bit by the perspective of the responder.
A bootloader is firmware used to load your program (sketch). If (bootloader) could also provide additional features (routines) it would be more appropriately called firmware. For example, SoftWareSerial could be incorporated into the bootloader to "always" provide that feature for every sketch at the expense of having a larger bootloader eating flash memory. Obviously, folks writing large sketches NOT needing the features of SoftwareSerial would be unhappy!
Sketch is an Arduino program generally written using standard Arduino syntax and within the Arduino GUI. However, the general term "sketch" is a synonym for Arduino program regardless of the host compile environment: exception, assembly or C code off in a library. Consider "sketch" your main program, the one with setup() and loop().
Thanks for the quick & clear response. I didn't realize that the Arduino was working as 2 chips, MocoLufa acting as Firmware for the USB Chip, the "Sketch" code acting as firmware for the Main AVR. It makes a lot more sense now.
Notice the two ICSP headers, one for programming each chip.
You really have potentially four lots of code:
Bootloader on the Atmega8U2 (USB) chip
Main code on the Atmega8U2
Bootloader on the Atmega328P (main) chip
Main code on the Atmega328P
The bootloaders in each case are intended to allow you to replace the "main code". The bootloaders reside in upper memory of the chip, the main code starts at address 0.
Resetting the board, BTW, does not replace anything. Reprogramming it would.
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?
kylejudd:
<...>
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:
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.
I read a lot about bootloader, of course include your website; and for a long time I thought the codes I was writing is to rewrite the bootloader, because I uploaded the .hex file, which is generated from AVRStudio, to ATmega328P through ICSP by a programmer all the time, which is the same way to rewrite the bootloader.
However, that is different with what Arduino IDE has done to upload the sketches.
The problem is, I wrote the exact same codes both in AVRStudio and Arduino, and both of them work very well.
So what did I wrote? is it bootloader of ATmega328P? or something else that work in ATmega328P instead of bootloader?
I will design my own board later, and now trying to clone Arduino Uno board; and this is a problem that I could not figure out.
Could you please help me with these questions?
Thank you!
The bootloader is not needed to program ATmega through ICSP, but the programming device is needed. Arduino uses programming via USART (serial port). In this case the bootloader is needed and programming device is not needed except of transceiver to serial. Of course, the way how to get the bootloader into ATmega is through ICSP e.g.
In your design you have to choose the method of programming. ICSP is a standard way, but requirement for programmer makes it less comfortable. On the other hand, the final design how often will require to reprogram? The Arduino is 'development tool'. It is assumed for frequent reprogramming and serial programming is more comfortable for this. Disadvantage is some flash memory spending for the bootloader.
I am trying to clone Arduino Uno R3, if that is the case, and with my AVR Pocket USBtiny programmer, do you know where I can find the .hex code of the bootloader for Atmega328P on Uno R3?
I can find the bootloader for Atmega16U2, however was not able to find that of Atmega328P. In order to get the frequent serial programming available, that is pretty important.
