Confusion: ATMega16U as ISP with Bootloader?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

  I'm struggling with a concept - I've noticed that your average 'Arduino' board has the ATMega328 as its core controller but also has an ATMega16U to handle USB.

 

So far so good, the Arduino IDE can send a 'sketch' via USB, the 16U takes that and programmes the 328, except that it doesn't? As far as I can tell the 16U appears simply to convert USB to SERIAL and passes that on to the 328 which then runs it through its bootloader and programs itself.

 

My question is why? Why does the 16U not use SPI to program the 328 (which is what happens when you use 'Arduino as ISP')? If you're going to the trouble of including a whole extra MCU on a board, why not use its resources and save the boot loader space on the 'main' MCU?

 

I ask this because I'm struggling with the next iteration of a design for a small gaming device. I'm using the ATMega1284P as my main MCU and currently just break out the ISP pins to a header and program it directly. I'm trying to be a little more elegant in using USB to program it. My researches so far have lead me to conclude that having a separate chip to deal with USB might be a good idea, but I don't understand why I would still then have to put a boot loader onto my 1284? I refuse to believe that this great idea of mine is the first time anyone has thought of this, so what have I missed that makes it obviously stupid? I suppose I can save a handful of pins maybe? but then surely I can still use the ISP pins if I really need to because they only program when RESET is low?

 

What I'd *really* like is the ability to drag-and-drop a .hex file using USB Mass Storage, which I'm sure is possible if complicated and surely something you'd stick on a separate chip so you don't have to worry about boot loader size creep? The BBC micro:bit does this and it's really neat!

 

-Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The traditional Arduino design provides a separate Serial link.

 

The main MCU uses the Serial link for the Bootloader or as a simple Serial link for the Application.

 

The Duemilanove used a FTDI USB->UART bridge chip

The Uno uses a ATmega16U2 as a USB->UART bridge

Some Uno clones use 16U2.

Other Uno/Mega/Nano/... clones used CP2102 or CH340

 

Yes,   it is possible to re-program some FTDI for other purposes.   CP2102, CH340 are single purpose.

 

The 16u2 can obviously be re-programmed to do many different things as well as provide a Serial link.

 

Personally,   I am happier with a single purpose bridge.   e.g. the 16u2 as it comes out of the Arduino box.

The beauty of traditional Arduino is that the Serial link is always available and it always works.

 

The Leonardo attempts to do Serial + MCU in a single 32u4 chip.

The M0 attempts to do Serial + MCU in a single SAMD21 chip.

 

This is ok if nothing goes wrong.    It is not as robust as the two-chip design.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah ok, that makes some sense. It's a mixture of "because that's how it's always been done" and "We used this thing because it's all we had, now we use this other thing that pretends to be the first thing because it gives us more options in the future".

I don't want my thing to be tied to the Arduino IDE, hence why I want to eventually go the Mass Storage route. Using a Mega16U seems like a good place to start, and leaving out the boot loader part makes things a little simpler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never looked at how Mass Storage works.    But I supect you will struggle with a 16u2.    There is not enough Flash and SRAM to contain Mass Storage and a useful application.

 

I suggest that you look at 32u4 applications.  e.g. Arduino Leonardo projects.

And standalone 32u4 projects.

 

Be realistic.   All other manufacturers produce USB-capable ARM chips with 128kB and more.    And probably cheaper.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed, I was thinking of the u4. My plan was to have that handle all the usb stuff and then program whatever 'main' chip to do the hard work.

I keep vascillating between sticking with AVR and moving to ARM. I've finally managed to get an environment that I can build and upload to a SAMD10 I soldered to a little PDIP board. But then I get put off by the huge jump in complexity programming for it - even just setting up the clock feels like an odessy compared to setting a fuse bit!

The next version of what I'm building is exploring new buttons, an OLED without the breakout board and everything SMD. I'm going to break out the programming pins for the 'main' MCU and experiment with building a little USB programmer as a separate board. EVENTUALLY I'll get an ARM chip going reliably enough to switch!

Thank you

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SAMD10 is a bit of a waste of time.     I would start with a medium size ARM.    Develop and debug your project.

 

Then rebuild and test for the smallest cheapest target.    SAMD10 might fit the bill.

 

But quite honestly,   a Cortex-M4 can give excellent performance.    And sleep when not needed.

 

Choosing a SAMD10 for development is a bit like choosing a Tiny5 or Tiny13 for developing AVR.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
The SAMD10 is a bit of a waste of time.

Very probably. I originally bought it to replace an ATTiny85, but ended up not having time to work it all out. Because I had it, I used it as training wheels to work out how to work them.

-Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using the 16u2 to do ISP programming would mean six connections between the 16u2 and the 328p pins (Rx and Tx since you still want the Serial capability, MISO, MOSI, SCK, and  RESET.)  Each potentially interfering with some function of the user sketch.  In the existing design, there are only the Rx/Tx connections (which they go to some effort to isolate), and a sort of half-connection to RESET.

 

And then there's "sideways compatibility"  with the non-16u2 based products (Nano, Pro-Mini, etc.)