stm8: enslaving a controller with another mcu

[aae30]

I've been hacking on a firmware for a (motor) controller running on stm8s105, and was thinking of best way to
add "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 of
the "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 would
be seen concurrently by both ?

Any suggestions about what to do(or not), or links to projects doing anything similar to learn from?

[Whales]

https://store.steampowered.com/app/370360/TIS100/

I suppose there's no harm done by splicing in floating inputs, so that for example hall and brake sensors would
be seen concurrently by both ?

Yes. 

You can also have shared outputs if you make them open-collector with a pullup resistor.

if i come up with way to keep things synchronized between the two.

There 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.

might be the most fun

I'd be running for the hills!     What sort of jobs do you want to split up between the two micros?

[Doctorandus_P]

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

[aae30]

if i come up with way to keep things synchronized between the two.

There 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.

I'm kinda hoping to get away sharing just one or two values. First would be 0-100%(or 0-255 doesn't
matter i guess), and later i might do some "position/angle calc" on the other mcu, which would be the
one that might require synchronising more accurately.

Wondering if it would help running the slave by clock output by new master ? Found out there's a
possibility to output a clock by a pin w/"RCC_CCO"(which can apparently be "muxed" by optionbyte).

might be the most fun

I'd be running for the hills!     What sort of jobs do you want to split up between the two micros?

Mostly 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 less
i 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 brakes

The main pcb has current sensor only on one phase, and i will look at moving current sensing/limiting
to the other mcu as well - while the main board will still have original overcurrent input by a opamp.

[aae30]

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.

Unfortunately there's more than just the throttle i would like to account for, of which atleast one would best
be taken care of with an input capable of measuring pwm, and only one timer on stm8 can do that(the one
already used by the complementary pwm), so adding a chip isn't just for fun. Might also give me the option
to use a "break function" of that timer instead of manually reacting in my code with regards to safety you
also mentioned about.

Can your setup (need to) do FOC or similar?

Something 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.

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.

Yep. The possible tight timing control is a headache for the future. It is not yet the time to be worried about
that, and this is currently more about splitting off the UI to it(+here i consider current+speed limiting to be
a part of that).