When should I start using more than 1 micro controller
I'm asking this because I have a semi complex project, one that I feel a single Arduino won't cut it for but im not completely sure yet because this is my first time working with one. I don't want to get into the product details to much but basically it will be running a stepper motor and 3 displays
First display for using my product like menus and stuff etc
the last two displays for the actual function of the product think of like a MSLA 3d printer how the LCD helps cure each layer of the print, now this is only one part of the machine im making so I was thinking I should give each display its own microcontroller to handle displaying the single still image that will change after every run (probably)
Nothing in the presentation calls for that. If You have lots of experience in communication and protocols You would not go for that. Having not much experience You will have real problems managing it.
What kind of programming experience are you bringing to this?
It is probably not time to start using more than one microcontroller.
You could… develop your code in stages, keeping functional areas separate, and see how far you get with one board.
For example, use the serial monitor to report the data that would later inform the output you want on LCD screens.
Use input from the serial monitor instead of keypads or whatever buttons you will want.
When the system is starting to come together, at some appropriate time go ahead and add the LCDs one at a time. And the keypad, or whatever. One small step for mankind at a time, get each step happy before adding more trouble.
Always looking for getting anywhere near consuming all your resources - i/o pins, processor time and memory.
Which woukd be a good plan even if it wasn't helping you answer your big question.
Multiple processors may seem like an easy way to go, but that would introduce distraxting challenges of a different kind.
It may all just come down to what kind of fun you want to have.
I wouldn't use two when one, with good programming and organization, would itself perhaps not be very highly taxed.
Then before you start, begin to work with two micro controllers and get them to communicate and when that is done and is satisfactory, start on the real project. You will know if one will do the job or if you need two, the hard part is done.
If you want to update the display at the same time as the stepper-motor shall run
there is a good chance that this makes the stepper-motor "hickup" depending on the used stepper-library.
stepper.h and AccelStepper.h would react like with hickups due to the concept how the step-pulses are created.
The MobaTools-library will manage it because the stepper-motor-pulses are created by a hardware-timer.
I would not use an arduino uno. I would use a microcontroller with more RAM and higher clock-speed
A STM32F103 can be programmed with the Arduino-IDE and works with the MobaTools-library
Or an ESP32.
Still it depends on what you want to do all in all.
Generally, I would not recommend multiple microcontrollers, but I would likely change my stance on your requirements. Stepper Motors really need a no hiccup access to the uC; especially for 3D printing and GCode.
As alluded to in previous comments, uC to uC comms are the big concern. If you are up to managing that aspect, I think 2 uC's would really be doable. Otherwise, maybe a RP2040 or look into a SoC like Raspberry Pi using one of the variant 'real time" OS.
It does depend on what the steppers are doing and how quickly they need to operate. In my current project a stepper is driven at about 13Hz and i have structured the code around this, all the other functions are interleaved. Initially I thought of using a Nano just for the stepper function but it turns out the Nano can do everything in parallel without breaking sweat.
If you have to ask... you are probably not ready to tackle a project where 2 MCUs need to talk to each other... especially given your 2nd comment above.
You are adding complexity that is likely not required. A single controller can manage many peripheral devices... unless you have some very unusual requirement I cannot see why having multiple controllers would deliver any tangible benefits.
If you have to ask... you are probably not ready to tackle a project where 2 MCUs need to talk to each other... especially given your 2nd comment above.
You are adding complexity that is likely not required. A single controller can manage many peripheral devices... unless you have some very unusual requirement I cannot see why having multiple controllers would deliver any tangible benefits.
and as others have said... consider a more power processor like the EPS32.
I think using more MCUs can often reduce complexity in some way. Also many people use multiple MCUs without knowing it. AFAIK many sensors such as DHT22 thermometer or HC-SR04 ultrasound distance meter have a MCU onboard. Also ESP-01 is a MCU acting as a peripheral device - often controlled by an Arduino Uno which is funny because the ESP has much more processing power.
Those are examples where using another MCU makes sense. There is some work to determine some usable communication protocol but when this is done the additional MCU dedicated for some simple task offloads a lot of (timing sensitive) work from the main MCU. Also it is simpler to reuse this part for another project.
Another possibility is that you have to control something that is "far" away from the main MCU. Imagine a keyboard - it makes sense to read the keyboard locally to reduce the amount of wires connecting the two parts. Noise is another issue - it is much less noise sensitive to read some analog sensor locally and send the data digitally. Also you will generate less noise by instructing a local MCU what PWM duty to use instead of generating the PWM far away.
unless there is a requirement for multiple processors keep to a single microcontroller - if you find a project requires more IO ports, RAM, etc move to a more powerful processor increasing power, flash, SRAM as required
in a recent project which has gone thru seven prototypes at prototype three the end user decided what if we required functionality for controlling multiple targets with different sensors so a set of PCBs was implemented each with a processor communicating by I2C - the interprocessor communication ended up as the most complex part of the system. Prototype four went back to a single processor with simple slave sensor PCBs.
Sometimes one may require a more powerful system for data presentation, e.g. a medical project had a Texas DSP processor with ADCs transmitting data over Ethernet 1000baseT to a PC running Matlab for ananysis and display.
Do you understand the difference between "commanding" a second processor and "controlling" a second processor. You need to clarify what you would want a second processor to do.
