Jump to content

    
Sign in to follow this  
_lexa_

Многопроцессорность на STM32f4 STM32f7

Recommended Posts

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

 

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

 

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

Share this post


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

 

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

Есть LIN - можно на них сделать сеть.

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

 

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

Share this post


Link to post
Share on other sites
Прошу участников обсуждать тему, а не причину.

Без знания причины обсуждать тут нечего. От знания причины зависят пути решения. Иначе это будет просто обсуждение коня в вакууме.

Если перед автором стоит реальная задача, то он её не озвучил, а озвучил один из частных путей решения. Это типично для начинающих.

Share this post


Link to post
Share on other sites
поэтому хотелось бы задействовать их.

Обычно железо под задачку выбирают. По-моему, вам больше подходит Parallax Propeller.

Там и железно более приспособлено к многоядерности, а главное софт.

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

 

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

Share this post


Link to post
Share on other sites
Обычно железо под задачку выбирают.

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

 

STM не самый лучший выбор, т.к. невозможно запускать код с произвольного адреса (нет MMU), хотя можно писать оверлеи, не зависящие от абсолютных адресов

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

Я думаю что он планирует каждому МК свою прошивку. Хотя это всё конечно - гадание на кофейной гуще....

Share this post


Link to post
Share on other sites
Есть запасы STM32f4 STM32f7, поэтому хотелось бы задействовать их.

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

Ну а тут все по-нашему.

Это у них, сначала считают деньги, потом выбирают под задачу микроконтроллеры. Вот скажем Шарки, те специально сделаны для многопроцессорности. И для объединения в кластер там все есть...

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

 

Share this post


Link to post
Share on other sites

Уточняю задачу.

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

 

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

 

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

 

Есть LIN - можно на них сделать сеть.

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

 

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

 

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

 

Всё это уже придумано лет 30-40 назад.

Вместо чтения вики, давайте придумывать всё заново.

Только с меньшими знаниями и худшими результатами.

Share this post


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

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

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

Тогда на этот МК (он будет мастером) и следует возложить все обязанности. Создаёте протокол работы по какому-либо интерфейсу(-ам) между мастером и слэйвами.

На прикладном уровне этот протокол может даже реализовывать доступ к общей памяти в адресном пространстве мастера.

 

А если таки нужна скорость, то обогнать Ethernet вам вряд ли удастся.

Обогнать Ethernet вполне реально применив в качестве шины подключения кучи слэйвов к одному мастеру например quad-SPI.

Уже хотя бы за счёт уменьшения лишних (в данном случае) заголовков кадров и обрамлений пакетов Ethernet.

PS: Хотя конечно не на STM32F4... :(

Share this post


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

 

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

Или у вас там принято делать все наоборот? ;)

 

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

А то может оказаться, что I2C хватит за глаза :)

 

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

upd с SPI опередили ))

Share this post


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

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

Share this post


Link to post
Share on other sites
Идеальный вариант - SRAM объемом 64 кБ на объединяющей плате.

Не, это архаичный и устаревший подход. В гетерогенных мультиконтроллерных структурах его не применяют.

Откуда эта сомнительная цифра в 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 Гбита.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this