Go Down

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

xtraorange

Hello!

A friend and I are working on a laser tag project.  We're both pretty new to electronics, but both have computer science degrees.

We decided to have multiple MCUs handle different parts of the gun's operation.  This sounds like it should work well, especially for some plans we have for alternative devices.

The problem that just dawned on me as we plan this out is how on earth I'm going to update all those MCUs with just one USB connection.  Despite further research, I have not been able to determine if there's a way to do that.

So, the question is, is there a way to have a single USB connection update the sketches on various chips (either through a stand-alone chip or through something like a mini pro)?

Thank you!

larryd

No technical PMs.
The last thing you did is where you should start looking.

xtraorange

It's an option, but we're running into a combination of limitations that makes modularizing certain aspects appealing.
Pin limitations, memory limitations, speed, and division of labor are the things that made us look at farming out some of the tasks into independent modules.  We may certainly be on the wrong route, but based on some earlier reading, it sounded like separate MCUs was the right answer.

Of course, if there's no way to accomplish the update via a single USB connection, we'll be forced to limit ourselves to one MCU

larryd

No technical PMs.
The last thing you did is where you should start looking.

xtraorange

To expand on my last post, in case I wasn't clear, here's what our thinking was:
Even with something along the lines of protothreading, we're concerned about the amount of things one MCU would be required to manage (touch screen LCD, IR encoding, IR sensors, hit indicators, sound, RF, etc) without blocking any of the other pieces.
We also would run dry on pins fairly quickly (although I do understand that there's a way to solve that) with the various ins and outs.
Further, we are hoping to make a fairly advanced system, and it seems pretty likely we'll be pushing the boundaries of the on board memory of the single MCU.

Beyond all this, I have a love for modularity, and I love the idea of some MCUs being responsible for only one piece of the system.

Again, we're new.  I did a lot of reading, but I'm far from even intermediate, so I would love to get any feedback if there's a smarter way!

xtraorange

Look into using an Atmega1284.
I'll take a look at that.  Is a modular design just not the right way to go about this then?

larryd

No technical PMs.
The last thing you did is where you should start looking.

DrAzzy

There's nothing wrong with using multiple microcontrollers if the task calls for it. You need to program each of them individually though, so if you have to update the firmware on multiple MCUs, that means multiple programming operations - I'd probably use something where you could plug in a serial adapter with the 6-pin FTDI pinout to program each micro in turn (assuming you'd changed the code on it).
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

xtraorange

There's nothing wrong with using multiple microcontrollers if the task calls for it. You need to program each of them individually though, so if you have to update the firmware on multiple MCUs, that means multiple programming operations - I'd probably use something where you could plug in a serial adapter with the 6-pin FTDI pinout to program each micro in turn (assuming you'd changed the code on it).
This was sort of what I was thinking, but would that require multiple connection points, or is there a way to tie them together and somehow address them?

Another possible solution I came across was the ability for one MCU to act as a programmer for another (though I don't recall the protocol).  I'm wondering if I could adapt this so that I have an "updater" MCU that steps through updating each of the other MCUs in turn.

I feel like I'm overcomplicating this, and might be better off surrendering to a single MCU.  :/

CrossRoads

#9
Mar 08, 2017, 05:58 pm Last Edit: Mar 08, 2017, 06:01 pm by CrossRoads
Could add a 3-pole, x-throw switch (Rx, Tx, DTR) after the USB/Serial chip and then just select the uC that you want the PC to talk to.
Could be mechanical (expensive), could be electronic multiplexing using DG406, DG408, DG409 or similar with 3 toggle switches you flip to select the uC to connect to.
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.

DrAzzy

This was sort of what I was thinking, but would that require multiple connection points, or is there a way to tie them together and somehow address them?

Another possible solution I came across was the ability for one MCU to act as a programmer for another (though I don't recall the protocol).  I'm wondering if I could adapt this so that I have an "updater" MCU that steps through updating each of the other MCUs in turn.

I feel like I'm overcomplicating this, and might be better off surrendering to a single MCU.  :/
Multiple connection points or what crossroads suggested are your options. I would start with multiple connection points if using multiple

The updater MCU sounds like you could sink a lot of time into it and get nothing useful out of it. Don't throw your time down that rat hole.
ATtiny core for 841+1634+828 and x313/x4/x5/x61/x7/x8 series Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts (some assembled), mosfets and awesome prototyping board in my store http://tindie.com/stores/DrAzzy

xtraorange

could be electronic multiplexing using DG406, DG408, DG409
Alright, I'm trying to wrap my head around what this setup would look like.

For the sake of argument, let's just say there's 5 MCUs in the whole unit that potentially might receive updates.

I would be using the electronic multiplexer to pass the input from USB to each of the MCUs as needed, correct?
What would you suggest control the switcher?

I'm having a hard time imagining how I could have the computer indicate the MCU it wants to communicate with, but I'm also very unfamiliar with those devices, so maybe I'm misunderstanding.

Thank you for the help, I really appreciate it!

CrossRoads

"I would be using the electronic multiplexer to pass the input from USB to each of the MCUs as needed, correct?"
No, use the mux to connect Rx, Tx, and DTR from the FTDI Basic to the boards. USB is very high speed and too sensitive for muxing like that.

Have 3 toggle switches to the 3 address lines of the mux - toggle them as 000, 001, 010, 011, 100 to select which board gets connected to output 0,1,2,3,4 to talk with the PC. You manually select which gets programmed -  I'm assuming each gets a unique program.
Actually, can probably get by with 2 muxes - connect the FTDI's Tx to the Rx of all devices, and only switch DTR and Rx back from the devices. Only 1 gets reset, its bootloader listens to the PC output and responds accordingly. The others don't get reset so their bootloaders don't start, they listen to the code download but don't act on it.
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.

larryd

No technical PMs.
The last thing you did is where you should start looking.

xtraorange

#14
Mar 11, 2017, 08:59 pm Last Edit: Mar 12, 2017, 03:20 am by xtraorange
No, use the mux to connect Rx, Tx, and DTR from the FTDI Basic to the boards. USB is very high speed and too sensitive for muxing like that.
I'm sorry, that's what I meant, I wasn't very precise in what I said (mostly because I blanked out on the term FTDI).

Have 3 toggle switches to the 3 address lines of the mux - toggle them as 000, 001, 010, 011, 100 to select which board gets connected to output 0,1,2,3,4 to talk with the PC. You manually select which gets programmed -  I'm assuming each gets a unique program.
This works for a temporary solution, but I would ideally like to find a way to not have it based on toggles. 

I'm getting in over my head here, but I wonder if I could use an MCU (like a tiny) to act like a sort of "traffic controller"?  In its setup phase, it could point the mux to itself.  When connected to the computer, it could be passed an instruction of which MCU to change the mux to.  On reset, it would restore the mux back to itself, ready for the next target?

I'm still pretty green on this stuff, so feel free to point out if I'm missing something obvious here, ha ha.


16 UNOs with supervisor processor.
Wow, that is exactly what I had in mind, ha ha.  I tried to find some more detailed information, but no such luck.


Go Up