[dxp 34]

39 минут назад, Quantum1 сказал:

ля 400 МГц, 450 нс действительно это прямо совсем печаль-печальная....

Ну, так это ж application процессор. Он быстрый, но неповоротливый, прерывания для него -- дорогая штука. Основные задержки, полагаю, там в контроллере прерываний GIC: толстая штука с поддержкой 1000+ источников прерываний. С такими процами просто и подход исходно другой: они применяются обычно как управляющее ядро SoC, а SoC -- это система, состоящая из достаточно самостоятельных устройств, обладающих приличной "автономностью", т.е. способных без вмешательства процессора выполнять сложные цепочки операций.

Процессор там в основном участвует для настройки аппаратуры, мониторинга процесса работы и корректировки, ну, и конечно, для организации интерфейса пользователя (хоть CLI, хоть GUI, хоть веб-интерфейс). Ну, и поскольку системы сложные, устройства непростые, там потенциально возможно большое количество прерываний, что налагает требования на контроллер прерываний. С другой стороны, поскольку устройства достаточно "самостоятельные", метаться по прерываниям на каждый чих не нужно. Вот и причина, почему такой сдвиг акцента: количество разменивается на скорость.

Но при таких "неприятных" значениях задержки на практике всё не так печально -- абсолютное-то время всё равно получается вполне приемлемым за счёт высокой частоты. Я сам озабочен подобными описанным вами вопросами -- предсказуемость времени реакции. Поэтому тоже ковыряю Zynq-7000 на предмет baremetal. Моё намерение: разместить программу в OCM, которой там 256к (для моих задач достаточно, что-то не критичное можно и в SDRAM закинуть), и это уровень L2, т.е. при промахе кэша L1 дальше этого уровня запрос не пойдёт (в отличие от случая, когда программа в SDRAM -- там возможен промах L2 кэша, дальше задержка обращения в SDRAM, в которой пасётся много кто -- та же FPGA часть -- в общем, тут задержка вместо нескольких тактов до OCM может вырасти до пары тыщ (видел отчёт несколько лет назад в Сети).

Но baremetal на application процессорах -- это то ещё "удовольствие". В основном это касается, конечно, запуска, потом-то всё вполне обычно. Но старт весьма нетривиален.

[Quantum1 1]

On 3/28/2024 at 12:41 PM, dxp said:

Поэтому тоже ковыряю Zynq-7000 на предмет baremetal. Моё намерение: разместить программу в OCM, которой там 256к (для моих задач достаточно, что-то не критичное можно и в SDRAM закинуть)

Я вот дословно тоже самое но на Zynq Ultrscale для R5, стараюсь сделать - важный код в OCM/TCM. Обидно конечно, что при этом так сказать быстрая-RAM сокращается значительно. я тут пытаюсь делать bank-память. Т.е. допустим пока критичный код крутится из OCM/TCM. Другой процесс подготавливает там же допустим другой критичный код. И как только потребуется, проц переходит уже на новую область OCM/TCM с новым кодом.

Геммороя конечно не меряно, но даже предварительные результаты очень хороши.  Так можно уложится в маленький размер OCM/TCM.

Но тут выход только один  - то что грузим в OCM/TCM, только самописный ассемблер, никаких компиляторных дел. Вот тогда система реально раскрывается как по быстродействию, и по малому размеру кода.

 

 

 

 

 

Я тут всерьез, задумался об отечественной ОС Embox. Как заявляется она способна запускать линукс приложения написаны чисто под линукс даже на мелких МК. Для меня это идеальная тема для больших SoC систем пишем под полноценный линукс. А для мелких на Embox берем куски/части своего же линукс кода и запускаем, но конечно они должны быть не тяжелые ибо мелкий МК.  Вроде как просматривается замечательная экономия времени, универсализация и масштабируемость.

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

Изменено 28 марта пользователем Quantum1

[jcxz 184]

12 минут назад, Quantum1 сказал:

Я тут всерьез, задумался об отечественной ОС Embox. Как заявляется она способна запускать линукс приложения написаны чисто под линукс даже на мелких МК. Для меня это идеальная тема для больших SoC систем пишем под полноценный линукс.

полноценный линукс на "мелких МК" (типа Cortex-M) не возможен по определению. Меньше всяких "блохеров" читайте.

[Quantum1 1]

On 3/28/2024 at 1:07 PM, jcxz said:

полноценный линукс на "мелких МК" (типа Cortex-M) не возможен по определению. Меньше всяких "блохеров" читайте.

да хрен с ним с полноценным, меня и сильно ограниченный устроил бы. Главное что б ПО можно было сразу на всё писать и использовать, пусть и рядом особенностей и требований. 

Изменено 28 марта пользователем Quantum1

[Arlleex 131]

1 час назад, dxp сказал:

Но baremetal на application процессорах -- это то ещё "удовольствие". В основном это касается, конечно, запуска, потом-то всё вполне обычно. Но старт весьма нетривиален.

А в чем сложность? Не с позиции дартаньянизма спрашиваю - просто какое-то количество времени назад активно работал с цинком, как раз FreeRTOS-бареметал. SDK дает работающий BSP, не надо курить-настраивать DDR и кэш-регионы (самое сложное для стартапа) - все само "из коробки". При необходимости правится легко.

И кстати: раз на цинке меряли задержку: а как меряли? Я лично не проверял (ибо не было нужды), но задержка между активизацией FIQ до смены режима CPU с User на FIQ - мгновенная.
 

49 минут назад, Quantum1 сказал:

пишем под полноценный линукс

uCLinux.

[Quantum1 1]

On 3/28/2024 at 1:39 PM, Arlleex said:

uCLinux

Судя по состоянию, этот пациент уже давно метрв....

[sasamy 9]

On 3/28/2024 at 1:11 PM, Quantum1 said:

Главное что б ПО можно было сразу на всё писать и использовать, пусть и рядом особенностей и требований. 

а что делает ваше ПО ? я когда то смотрел embox у них там старая Qt4 была портирована и linphone кажется, у Qt свой порт есть на микроконтроллеры за  деньги

https://www.qt.io/product/develop-software-microcontrollers-mcu

и posix layer в embox не уникальный случай

https://github.com/eclipse-threadx/threadx/tree/master/utility/rtos_compatibility_layers/posix

https://nuttx.apache.org/docs/latest/

 

Изменено 28 марта пользователем sasamy

[mantech 34]

5 часов назад, dxp сказал:

Ну, так это ж application процессор. Он быстрый, но неповоротливый, прерывания для него -- дорогая штука.

Значит надо использовать разные ядра, например задачу ТС можно было решить на проце аллвиннер Т113, под стандартные задачи использовать одно или 2 ядра кортексА7, а под "жуткий реалтайм" его сопроцессор hifi4DSP 600МГц. Если ДСП жутко сложен, то можно взять разновидность T113-I или T113-S4 там разблокировано ядро riscV с независимым контроллером прерываний, вполне пригодно...

[Quantum1 1]

On 3/28/2024 at 6:14 PM, mantech said:

аллвиннер Т113

Я бы не стал с ними связываться, во первых свою линейку разной производительности хочу все таки на Cortex-R серий строить, как база для реал-тайм дел. Второе как я понимаю по разным отзывам на уровне железа эти китайцы не особо прозрачны. По крайней мере очень многие жаловались, что есть проблемы с полноценным описанием. DSP(DSP это вообще не совсем про реал-тайм(хотя он там обязателен, но он его "как бы" обслуживает, а не создает) это больше про монотонное числомолочение под всякие цифровые фильтры и т.д.) как таковые я не очень люблю, если нужно применить обширные числомолотилки, на ПЛИС обычно изящнее и проще выходит, без кучи проприетарности конкретного DSP.

  

Изменено 28 марта пользователем Quantum1

[mantech 34]

29 минут назад, Quantum1 сказал:

По крайней мере очень многие жаловались, что есть проблемы с полноценным описанием.

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

32 минуты назад, Quantum1 сказал:

на ПЛИС обычно изящнее и проще выходит, без кучи проприетарности конкретного DSP.

Ну это к.м.к. немного разные применения, если нужны расчеты, алгоритмы, то лучше процы, ДСП, если быстрая логика, то однозначно ПЛИСы...

[Quantum1 1]

On 3/28/2024 at 9:00 PM, mantech said:

Ну эт да, есть такое

ну так тогда на них вообще невозможно работать)) Из линуксовских исходников вытаскивать информацию о работе периферии и регистрах ??? Это ж каким мазахистом надо быть!)) А потом еще и пофигистом заявляя что твой прибор отказоустойчив, хотя ты сам про него и половину толком не знаешь)) ты иной раз с хорошим описанием днями сидишь какой-то заковыристый косяк выгрести не можешь, который в итоге в железе сидит, материшься, почему его нет в errata, плюешь и переделываешь такой прекрасный и готовый свой алгоритм дабы этот момент обойти. Я думаю проще извернуться и привезти нормальное железо, пусть даже за x3 цену, но оно будет работать, а ты будешь спокойно спать, и уверенно развивать свою компанию....

[mantech 34]

1 минуту назад, Quantum1 сказал:

Я думаю проще извернуться и привезти нормальное железо, пусть даже за x3 цену, но оно будет работать, а ты будешь спокойно спать, и уверенно развивать свою компанию....

Да нормально спим, работает, как положено, при разработке нюансы есть... Ну и на систему управления ядерным реактором или автопилотом самолета я аллвиннер бы не поставил, конечно по неск причинам сразу))))

4 минуты назад, Quantum1 сказал:

привезти нормальное железо

А на счет описания, так его даже техас на свои PRUSSы не дает, и как тут быть уверенным тогда?))) По мне тут больше паранойи у разработчиков, чем реальных проблем. Ну и много чего просто решается тестированием с пристрастием...

[Quantum1 1]

On 3/28/2024 at 9:14 PM, mantech said:

А на счет описания, так его даже техас на свои PRUSSы не дает, и как тут быть уверенным тогда?)))

Да никак не быть, никак под него не писать и все! А зачем мне они вообще нужны? Очередная глубокая проприетарщина какая-то, хочет Тексас скрывать - пожалуйста! Я просто использовать не буду, так как не вижу прозрачных явно описанных преимуществ. В моем случае когда тебе нужно более 2 ядер, то там уже и без ПЛИСа тяжеловато, поэтому эти PRUSSы вообще никакого интереса не вызывают. Кстати у того же Тексаса из новых серий хватает хороших многоядерников на Cortex-R5, с нормальными описаниями и плюшками. (Хотя если уж настолько нужно описание Тексасов, я думаю через знакомых в иностранных компаниях спокойно можно их поиметь, им то их дадут по запросу, самое главное, что у Тексаса они точно физически есть! А вот у китайцев нет)))))

 

On 3/28/2024 at 9:14 PM, mantech said:

Ну и много чего просто решается тестированием с пристрастием

При чем тут тестирование! До него еще доехать бы! Ты идешь по минному полю, не зная где сейчас рванет. Допустим разработал алгоритм, какой-то код накидал, и тут начинается - это место не так работает, тут задержки рушат всю концепцию, а это он оказывается только в урезанном виде поддерживает, а тут он флаги неожиданным образом ставит, тут прерывание не срабатывает. Это не разработка это треш какой то. Или вы предлагаете для каждого регистра свой тест писать, что бы просто догадаться что это он вдруг тут стал неожиданно делать? Ну или классический путь кодописа - накинуть Линукс и радоваться каким то там трем примерам из сети, радостно крича: IoT, IoT!!!   

 

Вы вот щас на полном серьезе предлагаете многоядерную, сложную систему, пытатся освоить на bare-metal, не имея нормальной документации, просто на шару? Вы либо какой-то сверх оптимист, или вы просто стебетесь)

 

 

On 3/28/2024 at 9:14 PM, mantech said:

Ну и на систему управления ядерным реактором или автопилотом самолета я аллвиннер бы не поставил, конечно по неск причинам сразу))))

А в допустим промышленные установки по микроэлектронным процессам с к примеру, опасной химией, поставили бы? ))) бытовым IoT-ом я как бы не занимаюсь))) о чем и писал в самой теме))) 

Изменено 28 марта пользователем Quantum1

[dxp 34]

7 часов назад, mantech сказал:

алгоритмы, то лучше процы, ДСП, если быстрая логика, то однозначно ПЛИСы...

Как сказать. Пара-тройка сотен DSP блоков в FPGA на типовых ЦОС операциях типа свёртки уделают практически любой DSP процессор влёт. Тут как обычно вопросы разумной достаточности и цены вопроса.

[Arlleex 131]

К аббревиатурам DSP/FPGA/SoC/Real-Time обычно в придачу идет солидная финансовая составляющая и вопрос цены комплектации вторичен.