Маленькие MCU стали настолько недорогими, что они часто дешевле, чем выделенный периферический чип, который делает гораздо меньше. Но кроме программных погрузчиков, я не вижу много мульти-MCU для маленьких досок компьютеров. Часть задачи заключается в том, что такой дизайн требует протокола связи между процессорами. Возможно, главный процессор должен просто использовать SWD для общения с периферийными MCUS. Затем основной MCU может достичь периферической MCU и чтения/записи памяти, настраивать интерфейсы и т. Д.

Любые мысли об общем дизайне систем с несколькими MCU?

Если скорость не проблема, я бы предпочел использовать протокол I2C Master-Slave.

Для скорости SPI или UART быстрее i2c. Для кабеля I2C - самый простой.

Прямо на.
Я делал это годами... Работа с разгрузкой для посвященного UC для обработки Duch Things As SD-карты для данных для данных и TUNY85 Обработка IR-получения.
http: // www.хакерс.io/rayburne/sd-card-serial-logger
http: // www.хакерс.IO/Rayburne/Infrare ... Эд-Декодер

Я просто использую серийные коммунальные компании от хоста Mega2560, чтобы управлять этими вне бортовыми устройствами.

Есть значительные преимущества для этого; Например, прорыв SD -карты предоставляет 3.3V, чтобы запустить ATMEHA328P при 8 МГц. ИК -модуль, базирующийся в Tiny85.

С этими предметами и в гостях, MEGA2560 может управлять двумя OLED-дисплеем в Европе, двум датчикам EGT, зарядом батареи, давлением масла и температурой воды, топливным кляпом и RTC. Весь ввод/вывод легко реализуется как государственная машина, и не требуется прерывания и не требуется. ИК используется редко, но цель состоит в том, чтобы установить модуль RTC.

Луча

Как общее решение, что -то быстрое предпочтительнее. Похоже, SWD может работать со скоростью до 3 МБ/с. SPI, вероятно, похож. DMA будет плюсом.

Интересной моделью абстракции будет эмулировать раздел общей памяти (как вы обычно имеете с несколькими ядрами в одном MCU). Т.е. оба MCU просто читают и пишут стандартную оперативную память и некоторую комбинацию аппаратного и библиотечного программного обеспечения Прозрачно их синхронизируют их.

Более сложным решением может быть использование SPI SRAM, такого как Microchip 23A256/23K256 (очень дешевый IC) с двумя мастерами SPI (два MCU). Некоторые связи между двумя MCU, необходимыми для правильной обработки SPI (есть много способов поделиться SRAM в зависимости от приложения).

ИМО, эволюция RTO в разных UC была бы более эффективной - концепция больше настраивается на SMP, симмертную многопроцессную, чем многоядерную.

Но есть цена, чтобы заплатить с помощью многоядерного или SMP. Разрешение «А» процессора доступа к перифериям чипа «B» проблематично: где буфер, в «A» или в «B» или в этой общей памяти? Мы даже заботимся, делает ли Magic Compiler Allycation?

С RTO, наши наборы инструментов остаются прежними, одноядными, но мы просто играем с моделируемыми потоками. В дизайне с несколькими чипсами, назначение потоков всегда будет иметь штраф, если потоки и периферийные вводы/вывод находятся в отдельных чипах. Кроме того, у RTO должно быть периферийное понимание того, что ввод -вывод посвящен каждому отдельному внешнему соединению чипа UC. Заявление о работе для потока больше не является «мигающим светодиодом на выводе 13», но теперь оно становится «на чипе (0/1), мигает светодиод на штифте 13."

Слишком большая головная боль, ИМО. Может быть интересно, но при столкновении с такими требованиями моя кишка говорит мне просто подняться на линейку продуктов и купить правильный микроконтроллер для требований под рукой. Или, как я делал, найдите менее требовательный код и перенесите всю подсистему на специальное устройство.

Луча

Я полагаю, что да, когда я думаю, когда я столкнулся с ограничениями MCU, более быстрым отдельным процессором, RTOS и/или больше всего всего (RAM/Flash/Pins/и т. Д.) Решили бы проблему. И Raspberry Pi Zero доказывает (примерно), что такие вещи доступны для < 5 долларов.

В долгосрочной перспективе часто лучше сделать решение как можно проще. По этой причине SWD не является подходящим инструментом. Лично я бы оставил булавки SWD неиспользованными и полностью посвященными для использования ST Link.

С SPI задача в написании кода раба. В этом смысле среднее устройство SPI, обслуживающее двух хозяев, является улучшением, но на практике оно просто перемещает проблему.

Если у вашего контроллера хоста достаточно последовательных портов, то рекомендуется соединение UART. Если в доступных последовательных портах есть предел, вы можете рассмотреть набор чипов RS485, чтобы поделиться строками. Это также правильное решение в случае, если расстояние между контроллером хоста и периферическим контроллером является длинным.

Ура, Олли

Или вы можете использовать банку. Он имеет тот же недостаток, что и RS485 - приемопередатчики, но оригинальный загрузчик может использовать его для обновления SW. AN3154 CAN CAN, используемый в загрузчике STM32
Но конечно. На небольшом устройстве это довольно излишнее Для нескольких рабов - самый простой вариант серийного, для высокоскоростного SPI и для более медленных устройств I2C без необходимости иметь дополнительные ICS.

randybb написал:Или вы можете использовать банку. Он имеет тот же недостаток, что и RS485 - приемопередатчики, но оригинальный загрузчик может использовать его для обновления SW. AN3154 CAN CAN, используемый в загрузчике STM32
Но конечно. На небольшом устройстве это довольно излишнее Для нескольких рабов - самый простой вариант серийного, для высокоскоростного SPI и для более медленных устройств I2C без необходимости иметь дополнительные ICS.

Я работал над проектом, который включал несколько «блоков обработки», которые общаются друг с другом, используя модифицированную шину SPI.
Это требует 2 SPI на устройство, по одному для каждой стороны, на конфигурации кольца. На низком уровне F103 это будет использовать все доступные SPI.

Этот 9 -битный режим UART интересен! Освобождает SPI для другого использования (ILI9341 ) Недостатком является то, что только одна транзакция может быть сделана за раз (в звездной конфигурации).

Создание кластера MCU "синей таблетки"...