Go Down

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


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? 



Mar 09, 2013, 04:03 am Last Edit: Mar 09, 2013, 04:19 am by retrolefty Reason: 1
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!

States that Moco for LUFA is firmware and is loaded into the atmega8u2 on an UNO board in place of the default USB-serial firmware.

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.


Nick Gammon

You didn't say which board you had (or I didn't spot it), but this picture might make things clearer:

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.
Please post technical questions on the forum, not by personal message. Thanks!

More info:


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?



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.

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



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.


Go Up