Additional MCUs as peripherals

Small MCU’s have gotten so inexpensive, that they are often cheaper than a dedicated peripheral chip that does far less. But other than program loaders, I don’t see many multi-MCU small-board computers. Part of the challenge is that such a design requires a communications protocol between processors. Perhaps the main CPU should just use SWD to communicate with the peripheral MCUs. Then the main MCU can reach into the peripheral MCU and read/write memory, configure interfaces, etc.

Any thoughts on the overall design of multi-MCU systems?

If speed isn’t an issue, I would rather use I2C Master-Slave protocol.

For speed, SPI or UART is faster than I2C. For cabling, I2C is the simplest.

Right on.
I have been doing this for years… off-loading work to dedicated uC to handle duch thingsas an SD card for datalogging and a tuny85 handling IR receive.
http://www.hackster.io/rayburne/sd-card-serial-logger
http://www.hackster.io/rayburne/infrare … ed-decoder

I’m just using serial comms from a Mega2560 host to drive these off-board devices.

There are a significant advantages to doing this; for example, the SD card breakout provides the 3.3V to run the atmeha328P @8MHz. The IR module based in the tiny85 performs flawless for the Sony protocol and does the decoding and serial transfer back to the Mega.

With those items off and away, the Mega2560 can manage the dual OLED cockpit display in thd Europa, the two EGT sensors, the battery charge-discharge, Oil pressure, and water temp, fuel gague, and RTC. All the I/O is easily implemented as a State Machine and no interrupts ard required. The IR is used seldom, but the purpose is to set ths RTC module.

Ray

As a generic solution, something fast is preferable. Looks like SWD can run at up to 3 MB/sec. SPI is probably similar. DMA would be a plus.

An interesting abstraction model would be to emulate a section of shared memory (as you typically have with multiple cores in a single MCU). Ie, both MCUs just read and write standard ram and some combination of hardware and library software transparently synchronize them.

A more sophisticated solution could be the use of a SPI SRAM like Microchip’s 23A256/23K256 (is very cheap IC) with two SPI masters ( two MCUs). Some connections between two MCU required for proper handling of SPI (there are many ways to share the SRAM depending on the application).

IMO, the evolution of an RTOS across multiple uC’s would be more efficient – the concept is more attune to SMP, Symmertic MultiProcessing, than multi-core.

But the there is a price to pay with multi-core or SMP. Allowing the “A” processor to access the “B” chip peripherials is problematic: where is the buffer, in “A” or in “B” or in that shared memory? Do we even care, does the magic compiler do the allication?

With RTOS, our tool sets stay the same, single-core, but we just play with simulated threads. In a multi-chip bridged design, thread assignment will always have a penalty if threads and peripherals I/O are in separate chips. Also, the RTOS must have a a peripheral understanding that I/O is dedicated in each separate uC chip external connection. The statement of work for a thread is no longer “blink the LED on pin 13” but now it becomes “on chip (0/1), blink the LED on pin 13.”

Too big of a headache, IMO. Might be fun to hack it out, but when faced with such requirements, my gut tells me to just go up the product line and buy the correct microcontroller for the requirements at hand. Or, like I have been doing, find the less demanding code and move the entire sub-system to a dedicated device.

Ray

I suppose that yes, when I think through when I have run into MCU limits, a faster single processor, RTOS and/or more of everything else (ram/flash/pins/etc) would have solved the problem. And the Raspberry Pi Zero proves (roughly) that such things are available for < $5.

In long run, it is often best to keep the solution as simple as possible. For that reason, the SWD is not proper tool. Personally, I would leave the SWD pins unused and fully dedicated for ST-Link usage.

With SPI, the challenge is in writing the slave code. In that sense an intermediate SPI device serving two masters is an improvement, but in practice it is just moving the problem around.

If your host controller has enough serial ports, then the UART connection is recommended. If there is a limit in available serial ports, you could consider a set of RS485 chips to share the lines. This is also a proper solution in case the distance between the host controller and peripheral controller is long.

Cheers, Ollie

Or you can use CAN. It has the same disadvantage as RS485 – transceivers, but the original bootloader is able to use it for sw update. AN3154 CAN protocol used in the STM32 bootloader
But sure. In a small device it is pretty overkill For few slaves is the simplest option serial, for high speed SPI and for slower devices i2c without need to have any additional ICs.

randybb wrote:Or you can use CAN. It has the same disadvantage as RS485 – transceivers, but the original bootloader is able to use it for sw update. AN3154 CAN protocol used in the STM32 bootloader
But sure. In a small device it is pretty overkill For few slaves is the simplest option serial, for high speed SPI and for slower devices i2c without need to have any additional ICs.

I’ve worked on a project that involved multiple “processing blocks” that communicate with each other using a modified SPI bus.
This requires 2 SPI’s per device, one for each side, on a ring configuration. On low end F103 this would use all of the SPI’s available.

That 9 bit UART mode is interesting! Frees up the SPI for another uses (ILI9341 ) A downside is that only one transaction can be made at a time (in a star configuration).

Making a “blue pill” MCU cluster…