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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Пардон за off

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

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

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


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

Тоже столкнулся с проблемой межмодульного взаимодействия для системы сбора-обработки данных.
Стандартные решения типа 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 на архитектуру шины подобной описанному?

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


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


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