Can we make the 16U2 on arduino board a ISP ?
Putting it in dfu mode or using Flip, program it with the 16U2 as ISP sketch , bootload/burn the chips we want and then make that USBtoSERIAL again. It will help someone with only one arduino board.
-Malhar
In theory it might be possible to write code to do that. However, I have never heard of it, therefor I can only assume that there is no working code for it yet.
I believe there have been various posts here in the forum and in instructables and blogs about doing that. I think with IDE 1.6.6 and above it may be almost practical to do because in that version the ATmega16U2 support was added to the main core. I have compiled the Caterina bootloader for 16U2 and added a boards.txt entry for it, and can upload to it from the IDE just like any other Arduino. It is not terribly convenient because the regular firmware that does USB-to-serial work is not sketchified, so it is still necessary to use avrdude on the command line to put the 16U2 back to normal after using it for sketches. This is interesting for experimenting with doing things with the additional I/O pins on the 16U2 and communicating between the 328P and 16U2 via serial. I have not uploaded the ArduinoISP sketch and tried it, but may get around to that eventually.
Making the 16U2 an ISP programmer is mostly an academic pursuit, because:
- Getting a cheap programmer or clone Arduino is much more easy than getting yet more software such as DFU/Flip and messing with that, and
- Chances are very high if the 328P needs bootloading due to something like voltage abuse, the 16U2 is going to also be blank and not have the DFU bootloader on it anyway, thus an external ISP programmer is needed in most cases.
HoodLoader2 by NicoHood is probably the most widely known way of turning the 16U2 into an ISP programmer. The ArduinoISP sketch overhaul in IDE version 1.6.6 has enhancements specifically for using with HoodLoader2. It is still an obscure topic, though.
The technical answer is yes. However, the proper way to handle this would be to update the 16u2 firmware to be smarter so that there is a single f/w image that does it all. Switching between two different f/w images is not necessary as there is room in the part to have smarter f/w that can do it all.
It would then be possible to eliminate a bootloader in the 328 and use the 16u2 for both serial communication and uploading.
This would free up the space in the 328 as no bootloader would be needed anymore and uploads could potentially be faster as well as it wouldn't be limited by the speed of the serial interface.
It could be handled in either of two ways.
-
Mode based.
The 16u2 could automatically switch between serial pass-through mode and stk500 programming mode.
-
have a 2nd USB endpoint for the programming.
The second endpoint could be another serial interface or could be something differnt like USBasp or USBtiny etc...
Neither of these is that difficult to do and I've often wondered why the Arduino boards still use a bootloader in their AVRs given that they have a smart AVR part sitting right there that can perform both serial passthrough and ISP programming.
In order to get it to work on an existing Arduino board, there are some h/w modifications that will have to be made to the board to create the needed ISP signal connections from the 16U2 to the 328.
But overall still not a difficult project.
--- bill
I like the way you think bperrybap. That would be pretty nice to have a no-bootloader-needed 328P-based board. I like the idea #1 you give. Features I would like to see:
- Caterina bootloader on the 16U2
- Firmware as a sketch
- An Uno-size version and small size version in the form factor of Metro Mini 328 and a stand-alone ISP/serial adapter version
- A mode button for the 16U2 firmware so you can select what the firmware does. Perhaps a small 7-segment display to tell what mode it is in, or an LED blink pattern to tell. A special sequence of characters sent via serial could also select a mode. Modes:
A. auto switch between ISP to onboard 328P and serial passthrough
B. ISP to external board or chip
C. stand alone optiloader to onboard 328P
D. stand alone optiloader to external board or chip
E. other things we haven't thought of yet
I know C sounds weird, but this would give the ability to burn bootloader and set fuses on a freshly-inserted 328P, and would also allow the board to be "switched" to conventional Uno behavior.
Perhaps it is time for a community-designed board. And a community name for it.
Seems a simple matter to connect 16U2's MISO-MOSI-SCK and one of PB4-5-6-7 to the 328's 4 ICSP pins for programming. Use the other pins of PB4-5-6-7 to control an LED and a couple buttons for mode control.
Hardware-wise, a pretty straightforward change.
16U2 software wise, hasn't bootload installing code already been developed?
Use a portion of that to set the fuses, and either install a bootloader, or install sketch directly to get the 1000 bytes of flash back (or whatever size optiboot is).
Heck, don't even do a hardware change - just connect 4 jumpers to connect the 2 chip, and power/gnd/3 wires for the LED and 2 buttons to a little "control panel" board that you connect up as needed. Then any 16U2 equipped board could be used.
dmjlambert,
I'm not sure what all those features are but it sure looks like a lot of feature creep.
I'm thinking much much simpler.
I was thinking of tweaks to the existing code that simply detects when the host is trying to do the Arduino upload and flips to processing the stk500 session itself.
That is it. This keeps it very simple and no feature creep.
The host wouldn't be able to tell the difference. It thinks it has autoreset the AVR and is talking to the bootloader inside the AVR, but the Arduino stk500 session is really now terminating in the 16U2 that is doing ISP serial programing to the AVR.
When the stk500 session ends/terminates the 16u2 drops back to doing serial passthrough.
--- bill
I'm just talking about taping into the firmware's ability to act as an ISP programmer, to let it burn the bootloader and also program external chips and boards. The ISP code is going to be there anyway, just adding some logic to direct the programming to different pins.
Sorry for the late reply as I was on a vacation.
I'll check solution provided by everyone and report back.
-Malhar