Go Down

Topic: Programming multiple ATMegas from one Arduino/FTDI? (Read 972 times) previous topic - next topic

CrossRoads

I'd go manual just to not have to deal with PC coding.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

xtraorange

I'd go manual just to not have to deal with PC coding.
Ha ha, that's the one part I feel okay with since that's what my degree is in.  :)

CrossRoads

Then I'd suggest two ports - one to set up the mux channel to pass data thru, and the other with the IDE comm's for the actual programming, assuming you can kick that off on the PC side from code also.
Conceptually, that'd be easy to do.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

xtraorange

Huh, that's a solution I wouldn't have considered.  I will do some tinkering.

Thanks!

Jiggy-Ninja

It is certainly possible for multiple modules to be updated from a single connection point, but the system has to be designed with that in mind. Cars, for example, have many modules hooked up to the same CAN bus. It only works because the programming software and the modules' bootloaders are designed to work together, so that when the computer addresses one module for programming, all the rest ignore it. Reprogramming your power steering won't screw up your brake controller.

The Arduino toolchain is designed fundamentally different. The bootloader and programming software (avrdude) are based on UART, which is a point-to-point topology and not a bus. It assumes one-on-one communication, not a group.

The only way to make this work with the existing toolchain is some form of multiplexing. The actual multiplexing part is easy, just use 3 analog multiplexers to switch TX, RX, and DTR to each board. The problem left is how to switch them.

I think that having the switching done automatically under control of the computer is probably going to be much more difficult than you expect, because the current toolchain isn't set up for that. The switch controller would need to monitor the UART stream and decide what to interpret as a switch command and what to passthrough as programming information. Unfortunately, because UART doesn't use addresses there's no way to fully disambiguate between commands and the stream. There's also the problem of how you select the proper stream when you're doing the program. How are you going to select the different channels when programming the different sketches? I imagine it'd be very hard to do without significant changes to the toolchain.

The easiest method is a physical selection switch. Either a set of DIP switches, or a multi-position selector switch connected to a decoder feeds into the inputs of the multiplexer.

One method you might use to guard against mistakes is to program a value into each EEPROM that is different for each different sketch. Then, next to the debug port wire one LED for each controller. Each controller's sketch reads the EEPROM location and if the value is not what is expected, it means you programmed the wrong sketch into the controller and it lights up the LED and goes into an infinite loop. This requires the LED to be connected to the same pin on each controller. If you see the LED lit after programming, it means you goofed and need to fix it.
Hackaday: https://hackaday.io/MarkRD
Advanced C++ Techniques: https://forum.arduino.cc/index.php?topic=493075.0

Go Up