stm8: enslaving a controller with another mcu - Page 1
Forum section: electronics / general

author: aae30
author_rank: Contributor
timestamp: September 10, 2025, 06:11:14 am
content: I've been hacking on a firmware for a (motor) controller running on stm8s105, and was thinking of best way toadd "features" given there's not much resources left. Came to a conclusion that adding another mcu would be,or atleast might be the most fun. Other mcu will be the same stm8s105@16MHz, so moving existing "tasks"and new features to it should be easy, if i come up with way to keep things synchronized between the two.While it might be possible to have say 9gpios assigned for the communication(8bits+"clk"?), i'm guessing any ofthe "hardware" options available(uart/i2c/spi) would be easier for me to implement, and likely fast enough too.I suppose there's no harm done by splicing in floating inputs, so that for example hall and brake sensors wouldbe seen concurrently by both ?Any suggestions about what to do(or not), or links to projects doing anything similar to learn from?

author: Whales
author_rank: Super Contributor
timestamp: September 10, 2025, 10:42:12 am
content: https://store.steampowered.com/app/370360/TIS100/QuoteYes.You can also have shared outputs if you make them open-collector with a pullup resistor.QuoteThere are infinite ways to do this, complex to simple, unreliable to bulletproof. I'd suggest trying to avoid having to synchronise data as much as possible, otherwise things can get hairy quickly.QuoteI'd be running for the hills!What sort of jobs do you want to split up between the two micros?

author: Doctorandus_P
author_rank: Super Contributor
timestamp: September 10, 2025, 06:20:17 pm
content: What can a motor controller on an 16MHz STM8 do? I've done some PWM DC motor controllers with a PID loop on an AVR, and that fit in a few kB and does not need processing power. Can your setup (need to) do FOC or similar?There are quite a bunch of reasons to use multiple uC's in an application. an uC is these days much cheaper then a PCB8584 I2C port expander. Heck, two small CPU's may be cheaper then a big one with pins to handle all I/O. But not all applications are fit for this approach. If you need tight timing control between the uC's then the benefits are already turning in the direction of headaches.Sometimes there is a "logical" functional split. For example one uC doing keyboard scanning, keeping track of rotary encoders and controlling a display (behind a front panel), while the other is doing lowish noise ADC measurements somewhere else in the system.And then there are the "safety" systems. where two or more uC's check whether any of them is computing out of line, but those are not trivial to setup. In the PLC world these things are often bright yellow or red, and they are also above my budget.https://duckduckgo.com/?t=h_&q=saftety+plc&ia=images&iax=images

author: aae30
author_rank: Contributor
timestamp: September 10, 2025, 06:45:27 pm
content: Quote from: Whales on September 10, 2025, 10:42:12 amI'm kinda hoping to get away sharing just one or two values. First would be 0-100%(or 0-255 doesn'tmatter i guess), and later i might do some "position/angle calc" on the other mcu, which would be theone that might require synchronising more accurately.Wondering if it would help running the slave by clock output by new master ? Found out there's apossibility to output a clock by a pin w/"RCC_CCO"(which can apparently be "muxed" by optionbyte).Quote from: Whales on September 10, 2025, 10:42:12 amMostly everything beside the main thing it does, which is complementary pwm for the three phases.Would prefer not modifying things on the pcb as far as possible(i do have a soldering iron, but the lessi need to use it the better). Short list of what i would move completely:- communication with display- throttle- any other possible input by user not including brakesThe main pcb has current sensor only on one phase, and i will look at moving current sensing/limitingto the other mcu as well - while the main board will still have original overcurrent input by a opamp.

author: aae30
author_rank: Contributor
timestamp: September 10, 2025, 07:19:52 pm
content: Quote from: Doctorandus_P on September 10, 2025, 06:20:17 pmUnfortunately there's more than just the throttle i would like to account for, of which atleast one would bestbe taken care of with an input capable of measuring pwm, and only one timer on stm8 can do that(the onealready used by the complementary pwm), so adding a chip isn't just for fun. Might also give me the optionto use a "break function" of that timer instead of manually reacting in my code with regards to safety youalso mentioned about.Quote from: Doctorandus_P on September 10, 2025, 06:20:17 pmSomething like that is what i'm aiming for by adding current sensors to all phases, but possible "perf"/"efficiency" enhancements via FOC aren't very high on my list of things to look out for.Quote from: Doctorandus_P on September 10, 2025, 06:20:17 pmYep. The possible tight timing control is a headache for the future. It is not yet the time to be worried aboutthat, and this is currently more about splitting off the UI to it(+here i consider current+speed limiting to bea part of that).