next topic »

[on:]

I have been investigating the procedure for bootloading a chip with Arduino, and have gotten confused over something. I'm wondering why some Arduino boards put the bootloader on an auxiliary microcontroller (Atmel AVR® AT32UC3B1256 for the MEGA-1284P Xplained Board http://www.atmel.com/Images/doc8377.pdf) and the (ATMEGA16U2-MU for the Mega 2560 Board   http://arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf).

In the following example on the Arduino website (http://www.arduino.cc/en/Main/Standalone), the main chip is bootloaded. I don't see any auxiliary chip here. A couple questions come to mind:

1) Why is a secondary microcontroller needed? Can't you just bootload the main chip and use a dedicated USB-to-Serial chip (FTDI?) for communication?
2) How do you know which secondary microcontrollers are compatible for bootloading and how do you connect them to the main chip?
3) How do you know what code to put onto the secondary chip?

Thank you

[Reply #1 on:]

1) Why is a secondary microcontroller needed? Can't you just bootload the main chip and use a dedicated USB-to-Serial chip (FTDI?) for communication?

Yes you can do that and for a long time this was done. However the secondary micro controller is cheaper than that FTDI chip, it is also more flexible meaning it can look like a keyboard or a mouse.

2) How do you know which secondary microcontrollers are compatible for bootloading and how do you connect them to the main chip?

Not sure who the "you" is here. If your a designer then its your job to know the capabilities of chips.

3) How do you know what code to put onto the secondary chip?

Again who is "you"?
The designer writes code.

[Reply #2 on:]

Not sure who the "you" is here. If your a designer then its your job to know the capabilities of chips.

I'm wondering what the logic is behind using those particular microcontrollers. I could just grab one of those and load on the bootloader code, but I still wouldn't understand why that chip and why it can be used as a USB communicator. If we could use one of those microcontrollers as a USB/Serial converter, then why do chips like those from FTDI exist and are used?

[Reply #3 on:]

If we could use one of those microcontrollers as a USB/Serial converter, then why do chips like those from FTDI exist and are used?

Because not all AVRs are USB capable?

[Reply #4 on:]

not all chips are USB capable as someone pointed out, like the atmega328 used in the arduino

not everything connects to another chip, I have been known to connect an FTDI usb cable's handshake lines to a SSR to ghetto up a 2 bit computer controlled do hicky when I need to do something quick

the FTDI chips came first and served a specific reason, the second avr came later and serves whatever reason you want it to

options are always good

[Reply #5 on:]

If we could use one of those microcontrollers as a USB/Serial converter, then why do chips like those from FTDI exist and are used?

Because not all AVRs are USB capable?

Well not all AVR chips have USB hardware built in, but even the lowly ATmeg8 is used as the only chip in USBasp programmers, so maybe the OP's question is not framed well.

Lefty

[Reply #6 on:]

I have been investigating the procedure for bootloading a chip with Arduino, and have gotten confused over something. I'm wondering why some Arduino boards put the bootloader on an auxiliary microcontroller (Atmel AVR® AT32UC3B1256 for the MEGA-1284P Xplained Board http://www.atmel.com/Images/doc8377.pdf) and the (ATMEGA16U2-MU for the Mega 2560 Board   http://arduino.cc/en/uploads/Main/arduino-mega2560_R3-sch.pdf).

In the following example on the Arduino website (http://www.arduino.cc/en/Main/Standalone), the main chip is bootloaded. I don't see any auxiliary chip here. A couple questions come to mind:

1) Why is a secondary microcontroller needed? Can't you just bootload the main chip and use a dedicated USB-to-Serial chip (FTDI?) for communication?
2) How do you know which secondary microcontrollers are compatible for bootloading and how do you connect them to the main chip?
3) How do you know what code to put onto the secondary chip?

Thank you

Historically:
The earliest Arduinos used a RS232 serial connection for communications and programming -- and this is still a good method, but slower, and one needs a RS232 port on one's computer, and these are getting harder to find.   
The development of the FTDI (usb-to-serial) chips allowed the next generation of Arduinos to use USB.  Using USB is faster and convenient, and optionally can supply power to the Arduino. 
As is stated in other posts, the next 'step' was to use a usb-capable microprocessor to replace the FTDI chips, as this was both cheaper and allowed additional capability. 

It is possible to use USB directly with microprocessors, and there are several projects that do just that.  This is both cheap and convenient.  However, the disadvantages are that you are limited to the slow version of USB (which may not be a big deal), and the usb-driver code takes u a lot of space in the microprocessor, leaving not much left for user-code. 

Lots of options.  For ultimate cheapness, you can use a separate USB-serial adapter to talk to a minimal system, see: http://arduino.cc/en/Main/ArduinoBoardMini and http://arduino.cc/en/Main/USBSerial

David

[Reply #7 on:]

Note  that the second chip on the Arduino boards does NOT house "the bootloader"; it has USB/Serial converter firmware (and potentially other functionality related to USB communications.)

[Reply #8 on:]

Note  that the second chip on the Arduino boards does NOT house "the bootloader"; it has USB/Serial converter firmware (and potentially other functionality related to USB communications.)

Speaking of bootloaders why does the main chip need a bootloader anyways would it not make more sense for the second chip to act as an ICSP programmer.

[Reply #9 on:]

iscp causes funny issues if things are also attached to the SPI ports

[Reply #10 on:]

would it not make more sense for the second chip to act as an ICSP programmer.

Well, not when the "second chip" was a dedicated USB/Serial peripheral that wasn't programmable.  Nor before that when it was some sort of level converter for a "real" serial port.  Implementing a serial port provides a common denominator that is easier to deal with from all sorts of host systems.  (Consider that at least one of Official Atmel Device Programmers needs different drivers and/or firmware depending on whether you're using it with Atmel Studio or AVRDude.  And that several load different firmware depending on the version of Studio.)

When the Uno was released, it COULD have implemented an ISP programmer in the second chip.  But it still would have had to implement the USB/Serial function for sketch-level communications AS WELL.  And when you start trying to implement multiple USB devices in one chip, you quickly get into "unexplored" territory.  (for example, I'm pretty sure I've heard that you can't use the OS-core CDC (serial) drivers if the USB CDC device is part of a "composite" USB device, on some OSes.)