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

[_lexa_]

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

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

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

[_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 ног подходили больше. И эзернета не было. Но столько воды с тех пор утекло. Может сейчас конечно все поменялось.

[scifi]

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

Плохая идея.

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

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

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

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

[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