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

[_lexa_]

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

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

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

[IgorKossak]

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

[x893]

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

[iosifk]

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

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

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

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

[jcxz]

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

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

[adnega]

поэтому хотелось бы задействовать их.

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

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

[jcxz]

Обычно железо под задачку выбирают.

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

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

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

[iosifk]

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

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

[_lexa_]

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

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

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

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

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

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

[scifi]

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

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

[x893]

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

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

[jcxz]

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

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

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

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

[Forger]

Не хотелось бы

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

Все это снижает скорость обмена информацией и усложняет алгоритм взаимодействия.

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

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

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

[jcxz]

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

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

[AlexandrY]

Идеальный вариант - 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 Гбита.

[_lexa_]

Требования по скорости не озвучены.

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

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

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

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

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

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

[Forger]

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

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

[AlexandrY]

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

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

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

[_lexa_]

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

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

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

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

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

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

[Forger]

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

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

[scifi]

Идея была в разделяемой памяти.

Плохая идея.

Можно написать что-то на подобии шлюза, который с внешними устройствами будет работать по SPI

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

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

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

[AlexandrY]

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

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

Подсмотрено во фреймворке SimpleLink от TI
Фишка в том, что хотя архитектура Master-Slave, но обмен идет Peer-to-Peer. А эт важно например для TCP протокола и всяких IoT.

[AVR]

Есть МАС - к ним можно добавить свитч напрямую без PHY... И реализовать сеть

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

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

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

[HardEgor]

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

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

[scifi]

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

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

[Forger]

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

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

[jcxz]

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

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

Я всегда стараюсь применять SPI для таких вещей. По схеме мастер-слэйв. Тактирует всегда мастер.
Его можно приспособить и для прямого отображения в память данных из одного контроллера в другой используя DMA.

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

[AlexandrY]

Это интерфейс SPIFI в LPC-ках.

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

[mantech]

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

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

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



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

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

Сообщение отредактировал mantech - Jan 18 2018, 12:25

[_lexa_]

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

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

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

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

[scifi]

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

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

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

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

[_lexa_]

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

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

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

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

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

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

[scifi]

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

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

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

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

[AlexandrY]

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

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

[blackfin]

Правда в RTOS вам придется погрузится по самые уши. Но другого пути в этой теме у вас нет.

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

Напр., AM5K2E04?

[AlexandrY]

...это уже не путь?
Напр., AM5K2E04?

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

[blackfin]

Это другая отрасль, не путайте.

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

[scifi]

Правда в RTOS вам придется погрузится по самые уши. Но другого пути в этой теме у вас нет.

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

[yuri.job]

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

[kolobok0]

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

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

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

[SasaVitebsk]

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

[AlexandrY]

а я тоже за эзернет. например, если хочется до 10 устройств иметь с неким общим, как бы расшареным, как бы дисковым пространством, и чтобы данные между модулями как то расшаривались, то самое простое это взять 11 портовый FE свич от того же марвела

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

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

[jcxz]

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

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

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

[AlexandrY]

Если не зацикливаться на топологии "звезда" и применяемые на слэйвах МК имеют по два каких-то интерфейса (SPI или Ethernet или ещё какие), то топология "кольцо" возможно будет выгоднее.

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

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

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

[AVR]

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

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

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

[_3m]

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

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

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

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

[jcxz]

Безнадежно - потому что отладить взаимодействие 100500 процессоров малореально.

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

[adnega]

Что такого сложного в задаче взаимодействия нескольких процессоров?

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

[AlexandrY]

Заметно упростить можно переформулировкой...

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

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

[Forger]

Он хочет масштабировать систему при минимальных программных изменениях.

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

[LWW]

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

Упс.. Случайно прочитал эту тему. Но про адресацию в АРМ - это зря. Не надо так!

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

А вот в AVR8 там относительная адресация всего +/- 2 килобайта... Всё остальное абсолютное и требует заморочек при перемещении программного кода.

Это так, на всякий случай, вдруг кому пригодится.....

Сообщение отредактировал LWW - Apr 21 2018, 22:41

[aaarrr]

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

Нет, не перемещаемый.

А вот в AVR8 там относительная адресация всего +/- 2 килобайта... Всё остальное абсолютное и требует заморочек при перемещении программного кода.

Ровным счетом все то же самое относится и к ARM. Данные, переходы - все потребует "заморочек".

[AVI-crak]

Нет, не перемещаемый.

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

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

[LWW]

Перемещаемый. Хотя может это на СИ так получается, фиксированный. А на ассемблере абсолютный адрес можно получить, только если "руками" загрузить его в регистр и перейти по адресу в регистре. Но так никто не делает.

Вся адресация в АРМ является PC-relative. Такие инструкции как В (аналог JMP). А так же BL (call). Далее идут инструкции условных переходов. А так же адресация и обращения к таблицам в памяти - всё делается относительно счётчика PC.

Таким образом, код может быть расположен по любому адресу, выровненным по слову (4 байта). Что я и проделывал без проблем, на ассемблере. В том числе, с довольно сложным кодом в сотни килобайт. Как правило, первая инструкция в бинарнике, это JMP на начало исполняемого участка кода. А если нет таблицы прерываний, то и JMP не нужен.

Но это так, к слову! Вдруг кому пригодится!

Тренируйтесь!

Пардон за off

[Forger]

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

Что я и проделывал без проблем, на ассемблере. В том числе, с довольно сложным кодом в сотни килобайт.

Но так никто не делает.

К счастью, что так никто не делает....

[adnega]

Перемещаемый.

Типичный код: в начале много команд, а в конце таблица значений.
Дык, в таблице значений полно абсолютных адресов.
Да, переносимым его можно сделать, если в нужных местах вписать нужные данные типа base+offset,
но из коробки никакой переносимости нет.

CODE

800338c: 6b2b ldr r3, [r5, #48] ; 0x30
800338e: 4807 ldr r0, [pc, #28] ; (80033ac <command_mainloop+0x178>)
8003390: 2108 movs r1, #8
8003392: 4798 blx r3
con_start();
8003394: 6ceb ldr r3, [r5, #76] ; 0x4c
8003396: 4805 ldr r0, [pc, #20] ; (80033ac <command_mainloop+0x178>)
8003398: 4798 blx r3
console_command_pos--;
800339a: 6823 ldr r3, [r4, #0]
800339c: 3b01 subs r3, #1
800339e: 6023 str r3, [r4, #0]
80033a0: e7f1 b.n 8003386 <command_mainloop+0x152>
80033a2: e8bd 87f0 ldmia.w sp!, {r4, r5, r6, r7, r8, r9, sl, pc}
80033a6: bf00 nop
80033a8: 08001f00 .word 0x08001f00
80033ac: 20000548 .word 0x20000548
80033b0: 2000003c .word 0x2000003c
80033b4: 20000034 .word 0x20000034
80033b8: 20000038 .word 0x20000038
80033bc: 20000008 .word 0x20000008
80033c0: 40007400 .word 0x40007400
80033c4: 20000050 .word 0x20000050
80033c8: 08004b9a .word 0x08004b9a
80033cc: 08004af8 .word 0x08004af8
80033d0: 20000488 .word 0x20000488
80033d4: 08004b18 .word 0x08004b18
80033d8: 08004b9d .word 0x08004b9d
80033dc: 200004c8 .word 0x200004c8

[aaarrr]

Вся адресация в АРМ является PC-relative.

Вот прям вся? Нет, к счастью.

Такие инструкции как В (аналог JMP). А так же BL (call). Далее идут инструкции условных переходов. А так же адресация и обращения к таблицам в памяти - всё делается относительно счётчика PC.

Ну так расскажите нам, как будет работать код, который через B вызывает какую-нибудь библиотечную функцию, если его загрузить по чужому адресу.

Тренируйтесь!

[khach]

Тоже столкнулся с проблемой межмодульного взаимодействия для системы сбора-обработки данных.
Стандартные решения типа CAMAC, VME, VXI, CERN LHC, PXI не подходят по многим параметрам. Задача похожа на задачу ТС - взаимодействие нескольких ( нескольких десятков) интеллектуальным модулей с главным модулем и между собой.
Реализация в основном на STM32 но возможны и другие варианты.
Система управления видится двухинтерфейсная. CAN bus в качестве медленной шины управления и арбитража, и быстрая шина для доступа к общей памяти- почтовому ящику для данных или для передачи данных модуль-модуль.
Предидущее решение было на базе RS-485, но там бывали проблемы с арбитражем и зависанием отдельных модулей. CAN в этом смысле гораздо надежнее и не требует таких ресурсов процессора как Эзернет.
По последовательной шине производилась инициализация модулей, синхронизация их RTC, медленный обмен данными по принципу почтовых ящиков итд. Также по CAN организовывался менеджмент событиями на высоскоростной обмен- запрос блока данных, готовность блока данных, запрос на захват высокоскороnсной шины, арбитраж мастеров шины.
А вот теперь вопрос по собственно высокоскоростной шине.

Были несколько вариантов- 8 или 16 битная параллельная шина ( безадресная, пакетная) со своим контроллером на FPGA который подключался к FSMC шине STM32, по архитектуре похожа на GPIB. Т.е talker и listner ( в терминах GPIB) выбирались заранее с помощью CAN шины, задавалась длина блока данных. До 10 кб можно было прокачать непосредственно в одной транзакции (лимитировала внутрення память ПЛИС контроллера параллельной шины). Для более длинных блоков данных был отдельный модуль общей памяти, он же флеш память типа raid для долговременного хранения данных.


USB HS c внешним PHY который общался с хост- контроллером на мастер-модуле в системе, но при числе HS USB более 4 начинались проблемы в USB хабе. Был рассмотрен так же вариант с Эзернетом с обрезанным протоколами до минимума, чтобы не реализовывать огромный стандартный стек протоколов в STM32. Потому что иначе для надежной работы надо было выделять под Эзернет коммуникацию отдельный процессор.
Варианты с SPI шинами оказались мало работоспособными, особенно в режиме мультимастера.

Были идеи использовать контроллеры SATA высокоскоростного обмена, но тогда лучше предусмотреть отдельную коммутацию точка- точка для такого обмена.

ЗЫ. Старая RS-485 шина тоже осталась. По ней можно было включить- выключить внутренне питание каждого модуля, срезетить процессор модуля, включить- выключить CAN трансивер модуля, измерить напряжения и токи внутреннего источник питания модуля, в перспективе по этой же шине идет апгрейд фирмвари модулей, если это необходимо или доступ к внутренней флеш памяти- хранилищу запасной фирмвари, с которой процессор модуля сам апгрейдится в случае необходимости.
А теперь вопрос- существует ли industrial standart на архитектуру шины подобной описанному?

[jcxz]

Вся адресация в АРМ является PC-relative. Такие инструкции как В (аналог JMP). А так же BL (call). Далее идут инструкции условных переходов. А так же адресация и обращения к таблицам в памяти - всё делается относительно счётчика PC.

Может стоит хотя бы один раз открыть описание системы команд, чтобы не писать галиматью?
И читаем описание команд BX, BLX, POP PC, ADD PC, ... и т.п.

Что я и проделывал без проблем, на ассемблере. В том числе, с довольно сложным кодом в сотни килобайт.

Ну-ну... Плиз в студию - описание задачи требующей кода "в сотни килобайт". Да ещё на ассемблере.
Да ещё написанного без знания системы команд (как выясняется)
Хотя.... если так же не знать и про циклы, то запросто и мегабайты можно набыдлокодить.

Был рассмотрен так же вариант с Эзернетом с обрезанным протоколами до минимума, чтобы не реализовывать огромный стандартный стек протоколов в STM32. Потому что иначе для надежной работы надо было выделять под Эзернет коммуникацию отдельный процессор.

Не очень ясно про какой такой "огромный стандартный стек протоколов" в ETHERNET идёт речь?
Обычно у всех получается использовать обычный Ethernet-контроллер встроенный в МК. Он очень хорошо разгружает ядро от рутинных операций.
Колхоз на трёх (!) шинах, там где можно обойтись одной - тоже странное решение.