какой из типовых последовательных выбрать ?
SPI
I2S
I2C
USART
CAN
USB
SWD
другой ?
быстрый, дешёвый, простой, как минимум с одним мастером, но лучше мульти

SPI

Зависит от многих факторов, включая помеховую обстановку. Вы озвучте задачу и условия заботы.
SPI, к слову, не отличается высокой помехоустойчивостью.

а вообще-то интересный может получиться вариант, если замкнуть miso и mosi

Я однажды видел в телефонной станции I2C, только линий данных было 8 и работали они одновременно...

связать несколько мк для быстрого обмена информацией


внутри платы не всё ли равно, у всех будет одинаково

Поставьте один USB-хаб, и все процессоры соедините через него.

и оказывается, в st уже об этом подумали - bidimode

А смысл? Из полнодуплекса сделать полудуплекс, и в 2 раза уменьшить скорость... Тут наоборот весь смак в том, что сразу пишешь в мейлбокс другого проца и читаешь оттуда одновременно, а если замкнуть - то это уже какой-то и2с получается

SPI - быстрый и простой.

spi только кажется, что дуплексный, а на самом деле ещё более извращённый, чем симплексный
например, передаёте вы слейву адрес и команду, а в это время получаете ненужные и непонятный данные
а чтобы считать ответ, что-то ненужное и непонятное отправляете
имеем оверхед в два раза
так что симплекс - даже плюс
а с мультимастером вообще имеем возможность от запросов отказаться и работать как взрослые, не по опросу, а по событиям
единственный недостаток - лишние провода синхронизации и арбитра
я вот думаю, может симплексный uart на принципах can решит задачу ещё лучше, чем spi ?

Приветствую!

Прежде чем выбирать тип интерфейса определитесь с топологией сети ваших МК, требованием к протоколам/трафику в сети.
Поскольку сделать сеть можно с использование любого из приведенных интерфесов но вот оптимален выбор или нет зависит от требований к системе/сети в целом.

Успехов! Rob.

P.S. я в далеких 90 годах прошлого века делал сеть на компьютерный класс собранный на "Специалист". Топология однопроводная общаяя шина, один мастер, в качестве интерфейса UART на 65к bit/s. Загрузка/сохранение програм на флоп мастера, обмен сообщениями межу слейвами, удаленное подключение мастера к слейву, очередь на принтер мастера, еще куча мелкого (ну разве что блекджека не было со шлю.. ) и все это в 2Kbyte ROM для слейва и 4Kbyte мастера

нечего думать: логическая топология - общая шина
физически может быть шиной, звездой или кольцом
трафик - больше - лучше

напишу, что не нравится:
SPI - лишние провода
I2C - по дефолту медленный и сложный, с dma там вообще не понятно, как
USART - требует наличие кварца, в общем случае
CAN - не быстрый, нет на дешёвых камнях
USB - сложный, ненадёжный, но быстрый и удобный на столе
SWD - интересная загадка, вроде бы можно прямо из мозгов получать нужную информацию, но не быстрый
ETHERNET - довольно шустрый, в пакетном режиме, уже решён вопрос с коллизиями, скорее всего не позволит снизить стоимость за счёт увеличения количества процессоров на плате

SPI в каскадном подключении (кольцом). Или I2C, многие контроллеры поддерживают до 3,4 Мбит/с. В первом случае - всегда есть мастер, во втором случае любой узел может быть мастером (поддерживается арбитраж).

Вариант - мультимастер spi на передачу и uart на прием, всего два провода

Ну вы блин даете!!

ЗЫ. Еще синхронизация по УСБ!



все зависит от протокола, первый байт, да, как правило бесполезные данные, но следующие уже что нужно. Я вообще делал по принципу мейлбоксов, т.е. есть блоки по 32 байта скажем в обоих процах, один на прием другой на передачу. Через ДМА идет постоянная синхронизация между МК, поэтому данные из одного МК сразу попадают в другой, в последнем байте старший "триггерный" синхробит, который позволяет определить, что весь кадр обновлен. Просто и не тормозит процы.

Я на прошлой неделе стоял перед похожим выбором, отказался от SPI в пользу UART. Полная асинхронность потоков, мало проводов, достаточная(для меня) скорость, простота отладки: возможность подключить PC для контроля (подслушка) или вообще использовать PC как вторую сторону обмена

Это если соединение точка-точка. Для сети на каждую пару корреспондентов свой UART надо лепить.

А можно соединить кольцом: tx первого к rx второго, tx второго к rx третьего и т.д. В узле проверяем что прилетело в rx - если адресовано не нам - отправляем по кольцу дальше без изменений. Если нам - отправляем по кольцу ответ. Но медленно всё это будет.

Мне 25 мегабит нужно было, сами понимаете - уарт так не могет Да и уартов мало не бывает, спи мало, где используют, да и было их аж 3!

arhiv6: медленно
Конечно, поэтому мой вариант наоборот - общие rx- tx и отбрасываем все пакеты кроме своих

9 мбит помнится на уарте
За дма нужно подумать, вот если бы заставить его писать с нуля автоматом, скажем по фрейм-еррор, тогда можно и на пакеты постоянной длины раззориться