One large microcontroller or several small ones?

[obiwanjacobi]

So you would specifically choose async UART - most MCU also support sync UART. But the clock signal can be viewed as a single point of failure. Speed may suffer, though. Is there any trick to speed things up?

[JPortici]

CAN can be simpler than UART, as well. Often it solves the framing problem way easier than UART. Often, the ID is data type directly (i.e., it tells you where to assign the data), and 8 bytes of payload is quite usable! Now you don't need headers, delimiters, or parser code either. Many CAN-based systems are complex as hell, but it's not because they are using CAN. CAN seems to be trendy among "let's do everything the complex way" folks, but you can still use it in a sane way if you want to. I have replaced a complex UART horror (my earlier revision) with a simple and robust CAN solution. It's always nice when you can just delete a few hundred lines of message parsers and just do the underlying thing "directly" by using signaling that's more suitable for the task.

In a synthesizer project of mine, many voices share a single control. I'm contemplating the use of CAN instead of multiple UARTs because the "front panel" SHOUTS the knobs potision to all the voice cards. Then implementing some sort of MIDI-Over-Can for notes on and off. The voices basically have to just listen for the main module

[MT]

In a synthesizer project of mine, many voices share a single control. I'm contemplating the use of CAN instead of multiple UARTs because the "front panel" SHOUTS the knobs potision to all the voice cards. Then implementing some sort of MIDI-Over-Can for notes on and off. The voices basically have to just listen for the main module

Dont complicate things, just use the MIDI protocol as is even a simplified handler will do (with higher baudrate if needed) from master to voice cards. And/or an extension of it , UART simplex onewire 9bit auto address mode,
all open collector for back and forth talking.

The front panel dont shout any control parameters, the master MCU does and your code allow it to send parameters
only when changed not continuously so no need for CAN. Baudrate only need to be sufficiently high to swamp out any noticeable audiodelays when a 10(or more) note chord and multiple parameter changes is made at the same time.

3 wire SPI is also an good candidate.

[mikeselectricstuff]

Dont complicate things, just use the MIDI protocol as is even a simplified handler will do (with higher baudrate if needed) from master to voice cards. And/or an extension of it , UART simplex onewire 9bit auto address mode,
all open collector for back and forth talking.

For a multi-master UART bus, open-collector/drain is rather limiting on baurate due to pullup time, and slow pullups can cause data flakiness. Better to use tri-state enabling of the transmitter during transmission. this can usually be done with no extra hardware (assuming the UART allows disabling of the transmitter output without also disabling the receiver - there are a few that don't) , using a TX-complete interrupt to disable the UART TX  after the transmission.

[JPortici]

Nah, i don't think i'm overcomplicating things. I have one shouting master and essentially 1-to-16 silent slaves and the master is talking to all of them, sometimes at the same time.
I actually thought of a solution using UART. Daisy chain all the boards, frames with header "zero" are broadcast messages that always get retransmitted.
headers "1" to "16" stop at the addressed slave. that should be easy to automate.

yes, i never used UART in a star topology

[nctnico]

Nah, i don't think i'm overcomplicating things. I have one shouting master and essentially 1-to-16 silent slaves and the master is talking to all of them, sometimes at the same time.
I actually thought of a solution using UART. Daisy chain all the boards, frames with header "zero" are broadcast messages that always get retransmitted.
headers "1" to "16" stop at the addressed slave. that should be easy to automate.

yes, i never used UART in a star topology

Daisy chaining UARTs is a bad idea. The first device gets flooded with all the messages. Better use an RS485 half duplex bus structure.

[MT]

Nah, i don't think i'm overcomplicating things. I have one shouting master and essentially 1-to-16 silent slaves and the master is talking to all of them, sometimes at the same time. I actually thought of a solution using UART. Daisy chain all the boards, frames with header "zero" are broadcast messages that always get retransmitted.

"Dont shout" be silent and efficient like mailman, yes you are complicating things by daisy chain in non auto address mode, dont garbage up your serial. just "channel access" each board. Auto addressing reduces interrupts, UART only interrupts on address match no software and buffering to decode channel/massage for slave MCU.

yes, i never used UART in a star topology

Time is now!

[MT]

For a multi-master UART bus, open-collector/drain is rather limiting on baurate due to pullup time, and slow pullups can cause data flakiness. Better to use tri-state enabling of the transmitter during transmission. this can usually be done with no extra hardware (assuming the UART allows disabling of the transmitter output without also disabling the receiver - there are a few that don't) , using a TX-complete interrupt to disable the UART TX  after the transmission.

Concur for higher speeds tristate/buffer whatever, but star uses only one pullup, i dont know how many voice cards he intend to use. STM32 USART junks RX/TX internally in single-wire half-duplex mode. RX or TX can be turned off in normal USART mode.

[JPortici]

Full duplex! I intend to update the firmware in the voice cards  the card has at least to say all ok, or error on frame XX
Still, i can't see the advantage of RS485 over CAN, the MCU price difference is like 0.15 in a 5-6€ figure, the can controller does a lot of things for you like framing, priorities, detecting transmission error and retransmitting on error..

[langwadt]

Yeah, UART is often simple and great and everything, but....

The fact that SPI provides reliable hardware framing signal with no restrictions to packet length makes it really easier to use than UART for many purposes. Some microcontrollers even support managing the chip select signal, for example, by DMA.

Extra complexity added by framing seems to sometimes surprise young players. How do you do that with UART? Often by actually designing a protocol and writing a parser for it, easily 100 lines of code even for a rather simple task + specification you need to keep up to date. Bugs can easily sneak in as you need parser state.

With SPI, synchronous data swaps of two memory areas (simple self-documenting structs, for example), arbitrary length, even tens of kilobytes if necessary, between two CPUs can happen almost 100% automatically and very robustly, often with a few lines of code, and you have the job done. With UART, you are building and specifying message formats and messages and designing how to frame them, i.e., at what character does the previous message end and the next start?

But of course, it depends. Sometimes the UART solution is way simpler than SPI. Sometimes you want to give a simple command. And sometimes 8 bits [for a complete message] is enough, and UART can frame that for you!

CAN can be simpler than UART, as well. Often it solves the framing problem way easier than UART. Often, the ID is data type directly (i.e., it tells you where to assign the data), and 8 bytes of payload is quite usable! Now you don't need headers, delimiters, or parser code either. Many CAN-based systems are complex as hell, but it's not because they are using CAN. CAN seems to be trendy among "let's do everything the complex way" folks, but you can still use it in a sane way if you want to. I have replaced a complex UART horror (my earlier revision) with a simple and robust CAN solution. It's always nice when you can just delete a few hundred lines of message parsers and just do the underlying thing "directly" by using signaling that's more suitable for the task.

and implementing (some subset of) https://en.wikipedia.org/wiki/ISO_15765-2 if you needed more than 8 byte payloads
on CAN is very simple

[Siwastaja]

Full duplex! I intend to update the firmware in the voice cards  the card has at least to say all ok, or error on frame XX
Still, i can't see the advantage of RS485 over CAN, the MCU price difference is like 0.15 in a 5-6€ figure, the can controller does a lot of things for you like framing, priorities, detecting transmission error and retransmitting on error..

Agree with CAN. Most MCUs use the same outsourced bxCAN peripheral IP, which is of fairly usable quality. You can easily configure hardware filters to only read specific CAN IDs (or masked ranges) you are interested about. You have hardware checksumming, and extremely simple framing up to 64 bits of payload, which is fairly good for synthesizer commands, I think. When 8 bytes is insufficient as is, you can dedicate part of the ID space to map certain settings or commands within the same unit, especially if you use the extended 29-bit IDs. Then, for example, just map the lowest 8 bits of the ID to denote actual "command" or "variable address" within one unit.

This is all very simple - again it's basically sharing memory, instead of developing "communication protocols" and "writing parsers".

Retransmission on CRC error, by the way, is very nontrivial in a UART message parser. CAN does this for you. You may still want to look at some statistics for error numbers and latency, though. Luckily, the CAN peripheral almost always provides easy ways to assist this, for example, error counters and message timestamping.