Доброе время суток!

Возникла необходимость сделать многопроцессорную систему, причем расширяемую. Также для всех процессоров в системе необходима разделяемая память. Есть запасы STM32f4 STM32f7, поэтому хотелось бы задействовать их.

Подскажите, пожалуйста, как можно выполнить поставленные задачи (если возможно имеющимися средствами)?

Прошу участников обсуждать тему, а не причину.
Модератор

Участники остались - телепаты уехали.

Есть LIN - можно на них сделать сеть.
Есть МАС - к ним можно добавить свитч напрямую без PHY... И реализовать сеть. А можно свитч сделать на ПЛИС, у Ксайлинкса был выложен проект "меш-коммутатора"...

А вот "разделяемая память" - тут сложнее. На сколько абонентов? Какого объема, разрядности и с какой скоростью доступа. Ведь можно сделать Память+(ПЛИС и из нее много SPI). И на эти SPI посадить микропроцессоры. Или скажем квадро-SPI...

Без знания причины обсуждать тут нечего. От знания причины зависят пути решения. Иначе это будет просто обсуждение коня в вакууме.
Если перед автором стоит реальная задача, то он её не озвучил, а озвучил один из частных путей решения. Это типично для начинающих.

Обычно железо под задачку выбирают. По-моему, вам больше подходит Parallax Propeller.
Там и железно более приспособлено к многоядерности, а главное софт.
STM не самый лучший выбор, т.к. невозможно запускать код с произвольного адреса (нет MMU), хотя можно писать оверлеи, не зависящие от абсолютных адресов и/или править таблицу адресов во время загрузки оверлея. В итоге много сил уйдет не только на железо, но и на написание софта, и борьбу с компилятором. В практическом смысле результат малозначим, но в академическом - очень интересен. Все же советую Пропеллер.

Или сделать интерпретатор байт-кода, и запускать задачки из байт-кода на любых узлах передавая информацию по любым доступным каналам.

А обсуждать задачу нам тут запретили. ((


А причём тут многоядерность? С чего Вы решили, что на этих МК автор собирается одинаковые задачи решать? Из какой строки его сообщения это проистекает?
Я думаю что он планирует каждому МК свою прошивку. Хотя это всё конечно - гадание на кофейной гуще....

Ну а тут все по-нашему.
Это у них, сначала считают деньги, потом выбирают под задачу микроконтроллеры. Вот скажем Шарки, те специально сделаны для многопроцессорности. И для объединения в кластер там все есть...
А у наших сначала выбирают самую дешевую гайку, просто потому что "знаем и любим", а потом к ней приходится делать сверху столько наворотов, что и смысл в самой этой гайке теряется. Да вот только отступать уже поздно. Сил и времени потрачено много...

Уточняю задачу.
Необходимо сделать устройство состоящее из объединяющей платы с набором слотов, в которые устанавливются платы различного назначения (связь, оцифровка аналоговых сигналов, математические вычисления и др.). Добавление плат хотелось бы выполнять без перенастроек других плат (ну или выполнение минимума настроек). Идеальный вариант - SRAM объемом 64 кБ на объединяющей плате. Микроконтроллеры на платах в слотах получают доступ к SRAM и через нее взаимодействуют между собой. В SRAM выделены области для данных определенного назначения, в соответствии с заранее оговоренными правилами. Каждый Контроллер в системе мог бы обращаться к любой области по необходимости. Получается какая-то параллельная шина. Вопрос - какими средствами ее организовать?

Есть документ armv7-m architecture reference manual, в котором предусмотрены средства синхронизации доступа к разделяемой памяти в многопроцессорной системе. Непонятно как и кем это реализовывалось физически (контроллеры с поддержкой разделяемой памяти).

А аналог дивайсес этот вопрос неплохо проработан на АДСП, но его не применяем, не устраивает переферия.



Можно конечно сделать сеть на базе свича эзернет, можно даже на USART или по CAN шине. Придется использовать какой-то протокол передачи данных. Все это снижает скорость обмена информацией и усложняет алгоритм взаимодействия. Не хотелось бы

Требования по скорости не озвучены. Можно вообще сделать полудуплексный UART на одном проводе, на скорости 100 кбит можно много плат подключить.
А если таки нужна скорость, то обогнать Ethernet вам вряд ли удастся. И не надо придумывать про сложность взаимодействия, сетевые штуки будут попроще, чем общая память.

Вот и пора свою шину придумывать.

Всё это уже придумано лет 30-40 назад.
Вместо чтения вики, давайте придумывать всё заново.
Только с меньшими знаниями и худшими результатами.

Это и будет как раз сделать проще, чем реализовывать разделяемую внешнюю память, которая не имеет средств аппаратной поддержки в ваших МК.
Для любого разделяемого ресурса нужно организовать арбитраж доступа к нему, захват/освобождение и т.п. На чём это всё делать? Логике? Или ставить отдельный МК?
Тогда на этот МК (он будет мастером) и следует возложить все обязанности. Создаёте протокол работы по какому-либо интерфейсу(-ам) между мастером и слэйвами.
На прикладном уровне этот протокол может даже реализовывать доступ к общей памяти в адресном пространстве мастера.


Обогнать Ethernet вполне реально применив в качестве шины подключения кучи слэйвов к одному мастеру например quad-SPI.
Уже хотя бы за счёт уменьшения лишних (в данном случае) заголовков кадров и обрамлений пакетов Ethernet.
PS: Хотя конечно не на STM32F4...

Теперь все встало на свои места: простые неоднократно обсосанные и готовые решения вам не годятся, а хочется "достать пяткой до затылка" - нагородить огород из кучи линий (разделяемая память требует как минимум параллельную шину адреса/данных)....

Профессионалами принято сначала проектировать проект (железо и софт), а потом рисовать схемотехнику, плодить платы и кодировать коды.
Или у вас там принято делать все наоборот?

Посчитайте для начала пропускную способность межплатной связи.
А то может оказаться, что I2C хватит за глаза

Если реально нужна большая скорость, то я бы ограничился SPI (с DMA ессно). ...
upd с SPI опередили ))

Это реализовано в существующих многоядерных МК.

Не, это архаичный и устаревший подход. В гетерогенных мультиконтроллерных структурах его не применяют.
Откуда эта сомнительная цифра в 64Кб. Параллельная шина тоже не вызывает энтузиазма.
Речь же не о мультиядерных кристаллах.

Вам нужно что типа Greybus и RTOS с поддержкой мультипроцессорности.
Главная фишка такой шины - хардварная маршрутизация.

Из доступныйх RTOS с поддержкой мультипроцессорности и софтварной маршрутизацией будет MQX, какие-то потуги для отдельного железа были у FreeRTOS.
В MQX вы можете посылать ивенты и сообщения любым задачам на другие микроконтроллеры. Запускать и останавливать задачи на любых микроконтроллерах.
При этом шина связи может быть любая: I2C, SPI, UART, CAN, Ethernet...
Думаю аппаратную быструю маршрутизацию можно сделать в i.MX RT на базе их периферии Flexible I/O и eDMA.
Да, там еще есть HyperBus. Можно до 333 MB/s развить. Но роутер придется делать самому для нее.

Кстати в логических контроллерах где там в линейку можно ставить по десятку модулей со всякими разными функциями и с довольно медленным циклом выполнения в 1 мс на соединительной шине стоят ASIC-и со скоростью в 3 Гбита.

скорость порядка 40 Мбит/с



Мне нравится идея, что контроллеры могут работать с разделяемой областью памяти. Считаю, что такие системы обладают максимальной гибкостью. Здесь уже упоминались шарки. Чем плоха их идея построения кластеров?



Это уже интереснее, хотя куча вопросов, надо изучать. Кроме того RTOS. Честно говоря никогда с ними не работал, возможно в силу предвзятого отношения. Иногда буквально приходится считать такты процессора

STM32F4: "Up to 4 SPIs (45 Mbits/s)"
STM32F7: "Up to 6 SPIs (up to 54 Mbit/s)"
Есть еще QuadSPI - там еще больше получается.

А не путаетесь ли вы в предмете обсуждения?
У SHARC-ов есть специальный Link Port для взаимодействия между чипами.
Разделяемую память они нигде не предлагают для таких целей.
Коммуникации внутри самих SHARC - совсем другая тема.

Но SHARC-и то всего до 500 МГц работают. Слабовато, однако, по современным меркам.

Со скоростями вроде как проблем нет. Идея была в разделяемой памяти. Не спорю,что можно использовать и SPI. Можно написать что-то на подобии шлюза, который с внешними устройствами будет работать по SPI, а для внутренней программы будут функции читающие и пишущие в виртуальные области памяти, которые могут быть собраны из разделов памяти контроллеров. Ну или что-то на подобии. Однако здесь не обойтись без какого-то протокола, кадры которого будут иметь служебные данные. Может случится, что при передаче небольшого куска информации, накладные расходы сожрут всю скорость.



С шарками не имел дела года с 2005, но сейчас посмотрел наискосок документацию на ADSP-2106x, у них не только линк-порт, их также можно подключать на общую параллельную шину, на которой также может висеть и память. При этом не только внешняя память, но и части памяти всех процессоров на шине будут отображаться в общую область. Чем это не разделяемая память по сути?

500 МГц это конечно круто. Не стали с ним работать из-за его громоздкости, микросхемы на 100 ног подходили больше. И эзернета не было. Но столько воды с тех пор утекло. Может сейчас конечно все поменялось.

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

Плохая идея.


Ага, изобретаем велосипед Ethernet switch.


Как будто разделяемая память не требует протокола. Вы просто не понимаете, о чём говорите. Ethernet, проще него трудно что-либо придумать.

Я всегда стараюсь применять SPI для таких вещей. По схеме мастер-слэйв. Тактирует всегда мастер.
Его можно приспособить и для прямого отображения в память данных из одного контроллера в другой используя DMA.
Но возникает проблема со скоростью передачи быстрых сообщений от слэйвов и быстрых команд от мастера.
Если отображаемая память большого размера, скажем больше килобайта, то передача события затягивается на время передачи этого килобайта.
Т.е. уже нельзя сделать общение с контроллерами посылающими короткие и быстрые данные, типа выносных сенсоров пространственной ориентации в роботах или с сервами.
Вот один из вариантов физического интерфйса на SPI:
Нажмите для просмотра прикрепленного файла
Подсмотрено во фреймворке SimpleLink от TI
Фишка в том, что хотя архитектура Master-Slave, но обмен идет Peer-to-Peer. А эт важно например для TCP протокола и всяких IoT.

А реально ли без свитча? RMII<->RMII напрямую? Или такое недопустимо и требуется некоторая логика, буферная память?


Каково же число этих самых процессоров в пределе? Максимум каков?

Как пример можно посмотреть компьютерную шину ISA, сейчас она используется на MicroPC.
На STM32 есть интерфейс Flexible static memory controller (FSMC) через который можно её организовать.
Скорость будет ограничена количеством устройств - чем больше устройст, тем больше емкость на шине.

Чем PHY не угодил? Он почти ничего не стОит, и сигналы от него можно тянуть сколь угодно далеко. А вы попробуйте протянуть MII/RMII между платами - удовольствие будет сомнительное.
И вот этот свич на ПЛИС - это очередной велосипед. Мелкосхем свичей в продаже достаточно, зачем их изобретать?

Свичи, ISA, параллельная шина.... но что-то подсказывает, что 40Мбит взяты ТС "с потолка" и в реале может оказаться, что нужно просто собирать данные с внешних относительно медленных датчиков.
А вот общая память для совершенно разношерстных устройств и возмножно разных производителей - вот что может оказаться серьезной проблемой для всего устройства.
Достаточно лишь зависнуть и сдохнуть одной из плат, как все устройство встанет колом!
При проектировании подобных "монстроподобных решений" нужно учитывать практически все возможные неприятности при эксплуатации изделия, в институтах этому не учат, но этому учит жисть

з.ы. Глядя на все "это", тоже прихожу к самому первому прозвучавшему тут мнению - курсач

Для описанной ТС-ом задачи (расширяемый набор плат вставляемых в кросс-плату) реализация на базе Ethernet потребует как минимум пары линий от каждого разъёма кросс-платы и switch-а с кол-вом соединителей равным кол-ву разъёмов. Их может получиться достаточно много (не знаю сколько он там планирует максимально слэйвов).
А при реализации на базе какой-либо шины (I2C, SPI, CAN, etc) количество проводов не зависит (или почти не зависит) от числа слэйвов.


Существуют контроллеры имеющие аппаратное отображение областей памяти на SPI-шину.
Это интерфейс SPIFI в LPC-ках.
Программа просто читает данные по адресу в своём адресном пространстве, а это чтение преобразуется в транзакцию чтения по SPI.
Там конечно работа этого механизма заточена в основном на работу с SPI-флешками (при инициализации насколько помню в регистры конфигурации нужно записать формат команды чтения посылаемой микросхеме SPI-флешь), но если вместо такой SPI-флешки в качестве мастера подключить другой МК, который разберёт такую команду и выполнить её, то так - обращаясь к адресу в своём адресном пространстве, можно читать память другого МК.
Но для решения задачи ТС этого конечно маловато.

Эт старо, теперь в NXP переходят на HyperBus.
Такое есть даже в Kinetis K8X которые на Cortex-M4

Вам память-то эта разделяемая , что даст в конечном результате, какое-то мифическое удобство программирования?? А так задача решается на стандартном модульном контроллере типа ИСА шины, или PCI в виде корзины с БП и платой процессора, все остальное периферийные модули. Все просто и прозрачно

Эзернет свич тут причем? Будь вместо SPI Ethernet, вопрос с протоколом не уйдет

О каком протоколе речь - синхронизация доступа, арбитраж шины? Синхронизация доступа к памяти часто нужна и в одноядерном процессоре при работе с внутренней памятью. Про арбитраж шины был приведен пример АДСП-шарк, там он выполнен аппаратно, программно городить ничего не надо. Вы что-то из этого называете протоколом?

Вас что, в детстве протоколами пугали? Дескать, придёт ночью протокол и скушает.
Протокол может быть текстом в три строчки. Всё зависит от задачи.


Предположим, что вы решили все эти заморочки с арбитражем и синхронизацией. Но у данных в этой общей памяти должен быть какой-то формат? Так же, как у кадра Ethernet должен быть формат. Где тут какое-то волшебное преимущество общей памяти - в упор не вижу.

На текущий момент 4, в планах - до 10


А вам похоже езернет деньги платит, раз он вам так нравится. Я просто хочу определить наиболее простой и эффективный вариант решения задачи. Что здесь такого?

Вот пишите вы программу, работаете с какими-то данными в памяти и в каком формате они хранятся? Просто данные по определенному адресу, никакой дополнительной служебной информации

Задача описана, скажем так, оч. широкими мазками. За неимением подробностей приходится додумывать. Каждый додумывает так, как ему нравится. Телепаты, конечно, всё знают, но они обычно в отпуске.


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

Оу! Так вам даже SHARC не подойдет.
Там же только 6-ть чипов можно посадить на общую параллельную шину.
И там кстати творится нечто довольно подозрительное с точки зрения надежности, поскольку у каждого чипа своя копия общей виртуальной памяти.
Контроля целостности данных нет.
Арбитраж тоже гибкостью не отличается.
Как и говорил - это устаревшее архаичное решение.
Берите пример с организации обмена в USB.
Правда в RTOS вам придется погрузится по самые уши. Но другого пути в этой теме у вас нет.

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

Напр., AM5K2E04?

Эта друга отрасль, не путайте.
А то я ща приплету "INTEL® CORE™ i7-8700K".

Кстати, а сколько FLOPS'ов у распиаренного STM32F7? Сходу почему-то не нашел..

Один из телепатов вышел из отпуска. Александр что-то знает про эту задачу, но нам не говорит. Скрытный телепат

а я тоже за эзернет. например, если хочется до 10 устройств иметь с неким общим, как бы расшареным, как бы дисковым пространством, и чтобы данные между модулями как то расшаривались, то самое простое это взять 11 портовый FE свич от того же марвела что нибудь из серии link street, и вкорячить в него 10 равноправных модулей. а 11й модуть будет тем самым управляемым свичом и расшаривателем данных(агрегатором). если мы говорим о сотке, то это всего 2 диф.пары от каждого модуля, т.е, чисто теоретически, если изобрерается велосипед нестандартный(не в 19 стойку) то я еще предложил бы пользовать готовые сАТА кабели для межблочной связи, как раз 2 дифпары. и стоят копейки.

Если Вы опытный человечик и такие вопросы как задача=эффективность решения уже порыли носом (и остались при своих), то если коротко - можно. и разделять и состыковывать энное кол-во мк и куча плюшек получать,
но там тема глубока, чтоб просто пилить на кухне на коленке - тянет на не хилый НИОКР и не в одно рыло.
И кстати в этом векторе - присмотритесь к публикуемым материалам тут в треде, у выступающего человечка - scifi. У него есть интересные проекты на мой взгляд в этом направлении.
Но возможно он этого не думал

с уважением
(круглый)

По моему, даже при наличии аппаратного порта (параллельного) с реализацией доступа из нескольких источников, при условии, что источников будет 10.... Ну и учитывая, что хотя бы один из них плотно сидит, то возникнут задержки на арбитраж, которые всю картину попортят.
Поэтому напрашивается какой-то аппаратный арбитр с высокоскоростным последовательным интерфейсом на N каналов источников. Он должен обеспечить обмен и арбитраж. Я имею ввиду потратить один камень на разруливание и обмен... ))

USB HS гораздо презентабельней смотрится.
Он и быстрее и физика на борту STM32 уже есть.
И QoS там делается проще. Т.е. можно реально гарантировать риалтайм для определенных потоков.
И хабы его проще.
И всегда есть еще один USB для обычных нужд.

Но все это будет просто обычной сетью.
Это не межпроцессорное взаимодействие.
И не изоляция функциональности.

Если не зацикливаться на топологии "звезда" и применяемые на слэйвах МК имеют по два каких-то интерфейса (SPI или Ethernet или ещё какие), то топология "кольцо" возможно будет выгоднее.
Каждый слэйв, если пакет адресован не ему, пропускает его с одного своего порта на 2-й насквозь, если адресован ему - обрабатывает и формирует ответный пакет.
Если слот пуст, то конструкция разъёма должна обеспечивать замыкание контактов принадлежащих этим двум портам, чтобы сохранялась целостность кольца.
Такая топология:
а) экономична (нет никаких дополнительных МК, свичей и т.п.);
б) обеспечивает высокую скорость (нет "бутылочного горлышка" куда лезут все слэйвы);
в) программная реализация проще (есть только одно ПО, не нужно писать отдельное ПО для центрального МК);
г) арбитраж прост до безобразия.
Если автору так уж хочется именно разделяемой памяти, он может считать что в заголовке пакета (в поле адреса) передаётся стартовый адрес памяти, причём - старшие скажем 4 бита - это номер слэйва, младшие биты - адрес памяти внутри слэйва. Т.е. - вся "разделяемая память" - это набор одинаковых блоков памяти в каждом слэйве.
Тогда арбитраж получается сам собой: так как каждый кусок памяти находится в своём МК, а этот МК получает запросы на доступ к нему строго последовательно, то собственно и арбитража никакого более не нужно. И требования к памяти скромнее получаются - блок "разделяемой памяти" размазан по всем слэйвам.
Скорость передачи в такой топологии может быть очень высокой, сигнальных линий - минимум. Ну задержка доступа конечно будет побольше, но и в топологии "звезда" задержка доступа при одновременной работе всех слэйвов может быть ещё больше.
Конечно есть и недостатки: при вставленном в слот неисправном слэйве - всё кольцо рушится. Чтобы восстановить связь, достаточно выдернуть слэйв из слота.
Хотя данная проблема решается дополнительным мультиплексором возле каждого слота.

Я бы конечно такую топологию строил на двух quad-SPI-портах (в любом МК есть SPI и не один), но если хочется можно и на 2-х Etherтуе, если они есть в МК.
При реализации на SPI можно обойтись без CS, сэкономив таким образом на пинах.

А не плагиат ли это EtherCat-а?
Только надо добавить, что система будет time-triggered.

И мы придем к старой доброй архитектуре традиционных PLC с самым коротким циклом в 100 мкс и отображением всех I/O на память.
Но тут даже поток сэмплов с частотой 10 кГц не передать.
Будет такая очень медленная реалтайм система.

Если нужна некая логическая mesh сеть, где каждый может передать что хочет каждому без вовлечения координатора, то в STM32 еще есть CAN FD, 4 мбит. Аппаратный контроль целостности данных.

В таком случае, меня тоже можно рассматривать как эзернет-агента, потому что такую задачу я бы решил именно на Ethernet. К тому же, switch обеспечит естественную "арбитрацию" доступа - ведь к МК с ОЗУ-общаком идет только один порт. Иными словами - приняли посылку, обработали, приняли, обработали.

И да, делать все на STM32 потому что их как гуталина, не есть поиск наиболее эффективного варианта задачи, а наоборот - поиск пути задействовать запасы, решив при этом задачу.

Постановка задачи в изложении ТС это какой то сон разума.

Если надо надежно работающее решение и чтобы уложиться в срок и бюджет берите многоядерный SOC который тянет сразу максимальную конфигурацию а в модулях расширения только IO.
Но это опять же если надо сделать продукт.

Тут похоже идет поиск оснований для создания отдела или темы чтобы ее долго и безнадежно пилить N лет.
Безнадежно - потому что отладить взаимодействие 100500 процессоров малореально.

Что такого сложного в задаче взаимодействия нескольких процессоров? Сейчас практически в каждом устройстве их по несколько штук. И как-то взаимодействуют.
В моём прошлом устройстве процессоров было 5 шт. Все разные, с разным ПО. И ничего - как-то вполне себе успешно взаимодействовали.
И это уж не говоря о том что эти устройства сами могли создавать сеть размером под сотню участников. И взаимодействовать внутри неё, довольно сложно, но успешно.

Если в системе координат, заданных ТС (хочу многопроцессорную систему с разделяемой памятью и широкой полосой; масштабируемую),
то очень сложно. Заметно упростить можно переформулировкой: есть какие-то блоки, они могут получать данные и их обрабатывать,
результатом работы блоки могут делиться с другими. Если данных много, то легче сделать на Ethernet; если очень мало, то на CAN.

Я так улавливаю несколько иное желание ТС. Он хочет масштабировать систему при минимальных программных изменениях.
Ethernet-ы, CAN-ы, любые сети - это кардинальное изменение программной архитектуры.
Полоса должна быть не просто широкой, а кратно превосходить поток данных всей вычислительной системы, чтобы освободить от протоколов, RTOS-ов и проч. беспокойств.
А иначе помимо протоколов надо будет еще ваять тулсы по планированию и конфигурации сети как в CAN-е , или схемы маршрутизации и тулсы Network Management как в Ethernet.

Поэтому надо сказать TC твердое нет его идее.
Это сделать на STM32 невозможно.
А то бы я сам себе такое сделал.

Это не проблема, когда менять нечего - ведь нету никакого кода
А если код был бы, то не возникла бы эта тема, вообще...