It is getting difficult to find a desktop or laptop computer with only a single CPU. Even a typical ARM-based computer now probably has multiple cores. Of course, there’s nothing to stop you from using multiple microcontrollers — like the Arduino — together. To make the process neater, [Dimitris Platis] put together Moltoduino, essentially an Arduino on a shield made to plug into another Arduino. And, yes, they will stack. You can see a video about the open source boards, below.
The key is how the board brings the pins out to connections that are easy to jumper between boards. There are several obvious use cases, but one that [Dimitris] is particularly interested in is hardware-in-the-loop testing. The idea is that you can use a simulated I/O device in one computer to exchange fake data with the software under test.
For example, you might be working on a sous vide cooker that reads a temperature and controls a heater. A second computer could stand in for the temperature sensor and heater. You could log outputs and also control the inputs. This is really nice when you want to set up repeatable test cases.
Of course, you don’t have to stack the boards to make that work. In fact, you don’t have to use another Arduino. A PC or some other controller could be the surrogate test device. But having it all in a stack is handy. There are several examples of doing testing using simulated hardware on the project’s GitHub page. The test subjects are a robot car and an ultrasonic device.
One neat feature is that each board has a switch to enable the master Arduino to ISP program it. So while you might not need to stack boards to use any of the proposed techniques, it does make for a nice and compact package.
Usually, when we see a cluster it uses Raspberry Pis. Or, sometimes, PCs.
But how to make sure that simulated I/O device is simulating properly? Write a test program to for another device test the simulated device that tests the final main device? But how to make sure that test device for your simulated device for end device is working properly? Program another test device for test devices that test simulated devices for end devices? But how to make sure that that test device for test devices that test simulated devices that test end devices works properly?
If you were writing something to control a heater based on a temperature sensor, at least you’d be able to test that “When this signal goes below that value, the heater turns on”, etc. And test your PID tuning to some extent. A naive simulation will probably not have errors like switch bounce, but at least you’ll get the structure of things in place.
To my mind, you mostly wouldn’t really write much of a “simulator” for most things. For instance, for an i2c temperature or distance sensor, you’d probably just write something to turn potentiometer data into an i2c stream.
Testing software and hardware in embedded systems is something completely normal. Tests are written in a way so they try to cover as much of of the code as possible. No test is 100% foolproof, but trying to get there is the goal.
Yeah some people seem to think that test cases are the panacea for all developer issues, but they are only as good as the cases you can think of….
How many can it be stacked and still work? Someone want to try for “Over 9000duino”?
power supply is the limit, 9000duino could need some 200A to operate
At 5V. That’s just a kilowatt, not so difficult to provide.
The power isn’t too much, but that’s a lot of current to provide, you’d have to provide power and many different points, probably to every few boards at least. 200A through the bottom Arduino’s traces would “remove” them.
While the immediate use for this might be limited, my first thought is that we don’t see a lot of distributed task builds (eg. many inexpensive Xduino/xPi board running on a system similar to Controller Area Systems) so that a lot more “local” response can be built into a system beyond what I2C might get you.
The furby organ seemed to have some arduinos in there https://youtu.be/GYLBjScgb7o?t=231
The build video (https://www.youtube.com/watch?v=Ju6kLgyeL0Y) has a good deal in it, but I’m not sure if there’s real data changing “hands” there or if it’s just pre-programmed operations being triggered by a hi/lo state and operating remotely. Certainly that’s a step forward (and hilariously entertaining) but having complete nodes operating in near autonomy is where it begins to get really interesting.
I like the idea, but for most common uses of an Atmega 328-class controller you can probably achieve the same using interrupts (timer and external). If you need faster devices, use a faster CPU such as the teensy or even the ESP32 (which BTW is dual core).
“It is getting difficult to find a desktop or laptop computer with only a single CPU. ”
No, it isn’t.
CPU =/= Core
Keyboard has a CPU, Display has (a) CPU(s), hard drive has a CPU…
Many specialized driver/controller chips are embedded CPUs
I think I disagree. A core generally is a CPU. Just like in a multi-chip CPU configuration, it will share certain things with other CPUs/Cores. However, AMD plays fast and loose with this lately. I have an “8 core” CPU but not 8 cores can do all things at once. Intel has Hyperthread which is sort of a context switch for a single core. So in that respect, yes, the hyperthread cores are not the same as a CPU. And AMDs disregard for semantics aside, a real “core” is, in fact, a complete CPU with some connection to the outside memory that may or may or not be shared across other cores. But even if you disagree, it really doesn’t have much to do with the point to the article or the original post. As Mark points out, if you really want to belabor semantics, then sure, the keyboard, the GPU, the drives, the mouse — all CPUs operating under control of the main processor, but honestly that wasn’t what I was going for.
Just link your arduinos via i2c,? No need to stack them just to communicate
What’s the fun in that?
B^)
That’s not doing you any good if you want to mock hardware…
so does this mean I can blink 2 LEDs at the same time now?
It means now, you can SIMulate them, blinking.
No. For that you would need two additional LED-Blink(tm) shields.
Nice, but why not just use a Parallax Propeller? That would be like having eight 32bit Arduinos in one with less power draw, and just as easy to program. Interesting idea, though.
Imagine a Beowulf cluster of that…