Boards with 16u2 - Uploading sketch directly on ISP (from USB)

Development Suggestions for the Arduino Project
1

Hi, I'm just thinking of this. Many arduinos come with two processors, one 16u2/8u2 and one main processor, be it 1280, 2560 or 328. It has been said that 16u2 is there as a USB serial adaptor to assist downloading of sketch into the 328, but I discovered that it is still using the bootloader-stk500 protocol. Why??

I do thinking connecting 16u2 to 328 upon SPI line is a better choice. Some reasons for this.

  1. SPI lines on the 16u2 are not used anyway.
  2. We can definitely emulate any of the programmers out there using the 16u2. If MKii/debugWire is possible, we can plug in an Arduino for AVR Studio to program and debug. Fuse setting will also be possible using this.
  3. We save space by scraping the redundant boot loader on main processor. And there's no boot loading timeout at startup, since the 16u2 handles all the ISP programming that does not require a boot loader setting.
  4. Use only one ICSP port as they are interconnected. And we just need to toggle the RESET line on either processor to determine whether this port is used for ISPing the 16u2, 328 or just pure SPI communication. Another jumper maybe, to toggle the RESET pin to any GPIO on 16u2.
  5. We can get rid of the ArduinoISP thing. Uploading program to another Arduino or any board made easy be simply connecting one ICSP header for another. (while the programmer Arduino is set with ICSP RST line attached to 16u2's SS or whatever.) This can be done much easier than the past, which we are required to remove the micro controller to do that.
  6. At the same time, still acts as a serial/whatever adaptor, as the firmware can serve concurrent functions.
  7. Bootloading main processor via USB. There's no need to external programmers. However, this is only possible if we want to revert to legacy scheme (due to some reasons), or intend to prepare a removable processor for external use.
  8. While flashing, other devices can be attached as well, as SPI is a bus (unlike Serial, that Serial 0 needs to have no devices attached in order to upload program).

Looks quite feasible as well. Anyone can give more suggestions on how to implement this, or getting Prof Banzi to notice it? Haha

Thanks!:slight_smile:

2

wxhemiao:
Hi, I'm just thinking of this. Many arduinos come with two processors, one 16u2/8u2 and one main processor, be it 1280, 2560 or 328. It has been said that 16u2 is there as a USB serial adaptor to assist downloading of sketch into the 328, but I discovered that it is still using the bootloader-stk500 protocol. Why??

I do thinking connecting 16u2 to 328 upon SPI line is a better choice. Some reasons for this.

  1. SPI lines on the 16u2 are not used anyway.
  2. We can definitely emulate any of the programmers out there using the 16u2. If MKii/debugWire is possible, we can plug in an Arduino for AVR Studio to program and debug. Fuse setting will also be possible using this.
  3. We save space by scraping the redundant boot loader on main processor. And there's no boot loading timeout at startup, since the 16u2 handles all the ISP programming that does not require a boot loader setting.
  4. Use only one ICSP port as they are interconnected. And we just need to toggle the RESET line on either processor to determine whether this port is used for ISPing the 16u2, 328 or just pure SPI communication. Another jumper maybe, to toggle the RESET pin to any GPIO on 16u2.
  5. We can get rid of the ArduinoISP thing. Uploading program to another Arduino or any board made easy be simply connecting one ICSP header for another. (while the programmer Arduino is set with ICSP RST line attached to 16u2's SS or whatever.) This can be done much easier than the past, which we are required to remove the micro controller to do that.
  6. At the same time, still acts as a serial/whatever adaptor, as the firmware can serve concurrent functions.
  7. Bootloading main processor via USB. There's no need to external programmers. However, this is only possible if we want to revert to legacy scheme (due to some reasons), or intend to prepare a removable processor for external use.
  8. While flashing, other devices can be attached as well, as SPI is a bus (unlike Serial, that Serial 0 needs to have no devices attached in order to upload program).

Looks quite feasible as well. Anyone can give more suggestions on how to implement this, or getting Prof Banzi to notice it? Haha

Thanks!:slight_smile:

I guess in theory one could convert the on-board 16U2 chip to be a USB ISP hardware programmer, but then one would lose the ability to talk to the serial monitor or PC application programs using serial COM port. Not a real good trade off in my mind.

One can buy a $5 USBasp programmer on E-bay if you just with to work without the bootloader on the main chip and then still be able to use the on-board USB serial chip for communicating with the serial monitor. It comes in awful handy just for program debugging even if you are not using it in the final project.

3

lose the ability to talk to the serial monitor or PC application programs using serial COM port

I believe it is possible to stay connected in serial, as composite device can be emulated via atmega USB series (like Leonardo that acts as a COM and Keyboard concurrently)
The reason I suggest using ISP + debugwire(if possible) emulation is because of its great flexibility and speed (committing pages through ISP is much faster than Serial)

4

wxhemiao:

lose the ability to talk to the serial monitor or PC application programs using serial COM port

I believe it is possible to stay connected in serial, as composite device can be emulated via atmega USB series (like Leonardo that acts as a COM and Keyboard concurrently)
The reason I suggest using ISP + debugwire(if possible) emulation is because of its great flexibility and speed (committing pages through ISP is much faster than Serial)

Not sure if ISP via the IDE/AVRDUDE is any faster. A group of us have been playing with 1284P boards running the bootloader at 1M baudrate and many are not seeing much speed difference from standard baudrate as AVRDUDE/STK500 protocol/flash writing speed might be the speed limiting factor and that might hold true for ISP programming.

Anyway don't let me rain on your idea, get it a go, check your results, and then share your findings and code. That is the 'arduino way' :wink:

5

I've thought this, on occasion...

composite device

Composite devices (actually, any non-COM device) can be problematic when it comes to multi-OS support, or so I've heard.

The other problem is that this would increase the number of pins with multiple connections. You'd have 5 pins rather than only 2 that you'd have to be careful didn't do the wrong things during "upload."