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)?
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
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!
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).
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).
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.
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.
xtraorange:
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.
CrossRoads:
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.
"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.
CrossRoads:
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).
CrossRoads:
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.
LarryD:
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.
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.
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.
