[_3m 4]

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

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

 

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

Но это опять же если надо сделать продукт.

 

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

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

 

[jcxz 184]

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

Что такого сложного в задаче взаимодействия нескольких процессоров? Сейчас практически в каждом устройстве их по несколько штук. И как-то взаимодействуют.

В моём прошлом устройстве процессоров было 5 шт. Все разные, с разным ПО. И ничего - как-то вполне себе успешно взаимодействовали. :)

И это уж не говоря о том что эти устройства сами могли создавать сеть размером под сотню участников. И взаимодействовать внутри неё, довольно сложно, но успешно.

[adnega 10]

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

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

то очень сложно. Заметно упростить можно переформулировкой: есть какие-то блоки, они могут получать данные и их обрабатывать,

результатом работы блоки могут делиться с другими. Если данных много, то легче сделать на Ethernet; если очень мало, то на CAN.

[AlexandrY 3]

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

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

Ethernet-ы, CAN-ы, любые сети - это кардинальное изменение программной архитектуры.

Полоса должна быть не просто широкой, а кратно превосходить поток данных всей вычислительной системы, чтобы освободить от протоколов, RTOS-ов и проч. беспокойств.

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

 

Поэтому надо сказать TC твердое нет его идее.

Это сделать на STM32 невозможно.

А то бы я сам себе такое сделал.

[Forger 17]

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

Это не проблема, когда менять нечего - ведь нету никакого кода

А если код был бы, то не возникла бы эта тема, вообще...

[LWW 0]

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

 

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

 

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

 

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

 

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

Изменено 21 апреля, 2018 пользователем LWW

[aaarrr 63]

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

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

 

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

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

[AVI-crak 0]

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

Для arm можно собирать независимый от адреса код, но для одного проекта это будет две независимых настройки компиляции - и целый океан боли.

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

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

 

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

[LWW 0]

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

 

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

 

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

 

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

 

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

 

Пардон за off

[Forger 17]

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

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

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

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

 

 

 

 

 

 

[adnega 10]

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

Типичный код: в начале много команд, а в конце таблица значений.

Дык, в таблице значений полно абсолютных адресов.

Да, переносимым его можно сделать, если в нужных местах вписать нужные данные типа base+offset,

но из коробки никакой переносимости нет.

 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 63]

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

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

 

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

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

 

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

[khach 33]

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

Стандартные решения типа 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 184]

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

Может стоит хотя бы один раз открыть описание системы команд, чтобы не писать галиматью?

И читаем описание команд BX, BLX, POP PC, ADD PC, ... и т.п.

 

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

Ну-ну... Плиз в студию - описание задачи требующей кода "в сотни килобайт". Да ещё на ассемблере.

Да ещё написанного без знания системы команд (как выясняется) :laughing:

Хотя.... если так же не знать и про циклы, то запросто и мегабайты можно набыдлокодить.

 

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

Не очень ясно про какой такой "огромный стандартный стек протоколов" в ETHERNET идёт речь?

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

Колхоз на трёх (!) шинах, там где можно обойтись одной - тоже странное решение.