[Metallist64 0]

Всем привет!

В связи с большим разнообразием мощных ARM контроллеров(ARM9 , A7, A9), есть идея применить их во встраиваемых решениях.

В связи с этим возникли вопросы: 

1. Программируют ли их люди их без операционной системы? 

2. Насколько трудно найти отладчик и IDE для данных контроллеров?

В частности интересуют, как программируют и отлажывают готовые одноплатные компьютеры вроде Raspberry PI, Orange PI. Или системы на ARM9 или A7.

Насколько я понял, что KEIL данные процы не поддерживает. С IAR вроде лучше, но что-то типа  Raspberry PI на ней тоже не поотлаживаешь.

 

[aaarrr 63]

Сейчас здесь начнется флуд на тему baremetal или не baremetal.

 

Осваивайте Linux, не усложняйте себе жизнь :)

[jcxz 184]

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

1. Программируют ли их люди их без операционной системы? 

да

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

2. Насколько трудно найти отладчик и IDE для данных контроллеров?

Нетрудно: J-Link, XDS510, ...

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

Насколько я понял, что KEIL данные процы не поддерживает. С IAR вроде лучше, но что-то типа  Raspberry PI на ней тоже не поотлаживаешь.

Ещё CCS от TI.

37 минут назад, aaarrr сказал:

Сейчас здесь начнется флуд на тему baremetal или не baremetal.

И Вы решили не уступать лидерство никому?  

[AlexandrY 2]

1 hour ago, Metallist64 said:

1. Программируют ли их люди их без операционной системы? 
2. Насколько трудно найти отладчик и IDE для данных контроллеров?

Есть такой проект u-boot . Это и есть проект под все ARM без операционной системы.
Компилер - GCC, IDE - Eclipse(последнее время модно Visual Studio Code) , отладчик  - OpenSDA и вперед. 

[haker_fox 60]

11 hours ago, Metallist64 said:

В связи с большим разнообразием мощных ARM контроллеров(ARM9 , A7, A9), есть идея применить их во встраиваемых решениях.

А вот меня интересует действительно разнообразие, указанное вами) Слишком широкий спектр архитектур указан. Слишком разные года выпуска. или это так, в общем вопрос?))

[haker_fox 60]

11 hours ago, Metallist64 said:

Программируют ли их люди их без операционной системы? 

А так, да - любой процессор можно запрограммировать без ОС, ибо ОС - это тоже программа. Вопрос в целесообразности. ИМХО, эти штуки (arm9, cortex-ax) созданы для использования чего-то типа linux, android, что значительно упрощает создание серьёзных (графика, аудио, видео, интерфейсы) приложений.

11 hours ago, Metallist64 said:

С IAR вроде лучше, но что-то типа  Raspberry PI

Тут. скорее всего, во всей красе предстанет GCC с его утилитами. Но у меня возникает подспутный вопрос: какое применение ваших изделий?

[dxp 32]

Тема подъёмная, но весьма непростая в силу изрядной сложности - в отличие от ординарного МК, где пользователь имеет дело с системой команд, контроллером прерываний и периферией, в системах с application processor (SoC - всё, что на Cortex-A, это системы на кристалле, т.к. сами по себе эти ядра смысла имеют мало) есть ещё низкоуровневый слой сложной аппаратуры, которую тоже приходится программировать пользователю - это кэши всех уровней, это MMU, это настройка развесистой периферийной инфраструктуры - опять же в отличие от тех же Cortex-M, где вся периферия висит на шине (AHB/APB) собственно процессорного ядра, тут присутствуют L3/L4 коммутаторы, включающие в себя кучу регистров для управления, как правило там же имеется один или несколько DMA, т.к. пересылка данных с помощью процессорного ядра в силу его удалённости от периферии получается дико неэффективной. 

 

В общем, всё это предъявляет требования в смысле достаточно высокого порога вхождения в тему на низком уровне, что резко отсекает массового пользователя от bare-metal. По этой причине вендоры и продвигают готовые "заготовки" на основе ебдеддед линуксов, где этот низкий уровень как-то реализован более-менее компетентными людьми, а пользователю остаётся только писать прикладной уровень и (самым продвинутым) драйвера (модули ядра). Производительность этих процессоров такова, что функциональность ядра линукса они вполне тянут на приемлемом для большинства задач уровне, а для задач, где требуется приличная производительность, предполагается использовать специализированную аппаратуру - аппаратные кодеки, графические ускорители и даже FPGA.

 

Сами вендоры (в частности Altera прямо писала) говорят, что де, не майтесь дурью, берите наш линукс и радуйтесь жизни. Тут тоже дали такой совет, он точно подойдёт для 90% (а то и до 99%) случаев.

 

У меня был небольшой опыт ковыряния SoC Zynq7000 от Xilinx на тему bare-metal. В принципе, всё оказалось подъёмно, но времени и сил отняло прилично. Могу поделиться, до чего докопал, а там сами решайте, стоит вам ввязываться в это или нет. Если интересно, скажите.

[haker_fox 60]

48 minutes ago, dxp said:

т.к. пересылка данных с помощью процессорного ядра в силу его удалённости от периферии получается дико неэффективной. 

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

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

Я не в теме, поэтому действительно интересно узнать чуть больше)))

[dxp 32]

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

 

Вот этот Zynq7000 и его QSPI контроллер. Схема тактирования 4:2:1 (а ещё она может быть 6:2:1, что ещё хуже в нашем контексте), что означает соотношения тактовых частот L1 (процессорные ядра), L2 (кэш второго уровня и примыкающая к процессорным ядрам аппаратура типа On-chip Memory (OCM)) и L3 (уровень периферии). Т.е. например, у меня процессорные ядра тут щёлкают на 400 МГц, кэш второго уровня и OCM на 200 МГц, а тот же QSPI - на 100 МГц. Вот пишем/читаем регистры QSPI контроллера - быстрое процессорное ядро мечет на шину AXI запросы, которые переходят в другие тактовые домены, проходят через коммутаторы, арбитры шины (там же разветвлённая "паутина дорог" - "перекрёстки", "семафоры")... В итоге время записи в регистр этого контроллера (как и любой другой периферии) получается по длителности что-то порядка (по памяти пишу) 8 тактов ядра, а чтение - 14 тактов. Обращение 32-разрядное. Вот и посчитайте, какой поток будет, если работать (писать/читать) с периферией сугубо программно.

 

По этой описанной причине правильный подход заключается в том, чтобы сама периферия была достаточно "умной" и выполняла пересылки как-то более-менее самостоятельно. Для этого там есть DMA контроллеры, а быстрая периферия типа гигабитных изернет MAC так имеет прямо внутри себя DMA мастер - это к вашему вопросу про "сеть-память". К сожалению, упомянутый QSPI в этой СнК сделан совсем по-тупому, и всё общение с ним осуществляется только через его MMR, что ограничивает скорость потока на уровне 200 Мбит/с, хотя сама микросхема памяти QSPI позволяет достигать потока в 800 Мбит/c (100 МГц тактовой на 4 линии на DDR). Правильный подход был бы в том, чтобы процессор только настроил QSPI контроллер - откуда читать, куда писать, - запустил процесс и дальше ждал бы прерывания о завершении задания. Кстати, у Altera Cyclone V SoC, вроде, так и сделано, но его я не копал. У Zynq неплохая периферия и почти вся она - купленные у Synopsis, Cadence IP ядра, а вот для QSPI Xilinx решила сама сделать... и вот зря (Altera, вроде, этот модуль купила, но точно уже не помню). 

 

В общем, тут есть объективные причины - чем сложнее и навороченнее (иерахически и количественно) система, тем безальтернативнее она будет иметь бОльшую латентность от процессора до периферии, и это требует более "умной", программируемой периферии, если хочется эффективности. Вы можете даже сравнить ногодрыг (в тактах) в AVR и у Cortex-M. Или латентность входа в прерывание - у AVR единицы тактов, у Cortex-M уже больше десятка, а у Cortex-A - это сотни (хотя я не понимаю, почему всё-таки так много!). Поэтому прыгать в прерывание на каждый чих очень расточительно и неэффективно. А значит периферия должна уметь делать много сама, чтобы не беспокоить "главного в бараке" по пустякам.

 

Процессорное ядро тут должно уметь быстро работать с памятью, и это достигается за счёт кэширования. Это нужно для обработки данных. Поэтому ядро не "курит в сторонке", оно занято своей работой. Но пересылка по одному слову между периферией и ядром программно - это плохо, это годится только для настройки периферии через MMR, но не для пересылки данных. Когда этот принцип нарушается, получается как у QSPI Zynq7000 - в разы медленнее, чем обеспечивают аппаратные интерфейсы.

[haker_fox 60]

@dxp, спасибо за очень подробный ответ!!! Стало понятнее для чего они (СнК) вообще нужны и как примерно с ними работают!

[AlexandrY 2]

1 hour ago, dxp said:

 я сказал, что пересылка данных процессором (т.е. программно) через эту инфраструктуру неэффективна. 

Странное открытие америки.
Вот уже десяток лет программисты на ARM знают о разделении шин на AHB и APB. 
И о том, что скорость доступа к периферии надо тестировать и профилировать, как здесь например - https://habr.com/post/394407/
И есть таки периферия доступная за такт ядра. 
Также все знают, что в FPGA стоят отстойные представители SoC ARM ибо они полагаются на собственно ресурсы FPGA, там нечего делать хорошим универсальным архитектурам.
Главное отличие Cortex-M от A в том что последние - это архитектура для приложений. Т.е. архитектура которая должна принимать и выполнять сторонние приложения или другими словами  глючные, тормозные, ненадежные приложения написанные неизвестно кем и по дешевке (образно говоря). И соответственно там MMU и OS играют главную роль.
Не использовать MMU и OS в Cortex-A означает просто выкинуть на ветер половину чипа. Это не по капиталистически. 
Для bareboard есть чипы типа i.MX RT на Cortex-M7  которые в 10 раз быстрее справляются с реактивными задачами по сравнению с Cortex-A с линуксом.  С периферией доступной за такт и гораздо более изощренным DMA, сетью ивентов и прерываний чем у Cortex-A от того же NXP. 
Хотя с появление Cortex-M33 чистый bareboard  уйдет в прошлое. Там борьба идет уже не с глючностью, а с агресивной зловредностью и RTOS в каком либо виде должна будет быть в любом случае, иначе опять будет выброс денег.  

[Metallist64 0]

3 hours ago, dxp said:

У меня был небольшой опыт ковыряния SoC Zynq7000 от Xilinx на тему bare-metal. В принципе, всё оказалось подъёмно, но времени и сил отняло прилично.

Очень интересно.  Поделитесь пожалуйста каким софтом и железом пользовались? Какие трудозатраты получились? 

Интрересует, как в случае с А9 выглядит клацанье портами и к примеру, работа с Ethernet.

Еще интересно, как можно поработать с HDMI на низком уровне.

И самый страшный вопрос: как запускается/записывается и отлажывается программа ? В этих процах нет же встроенной флэши и SRAM ...

[haker_fox 60]

Ну если так, то присоединяюсь к вопросу @Metallist64)))

[Arlleex 131]

У меня Zynq7000 под управлением FreeRTOS, по сути голое железо.

Подняты Ethernet, SD, GTX, UART/SPI/I2C и прочая требуха (кроме USB, наверное).

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

Когда был написан Ethernet-драйвер, накрутили поверх LwIP. Подняли SD-драйвера - прикрутили FATFS.

Это такой, можно сказать, чуть более сложный микроконтроллер

 

Цитата

И самый страшный вопрос: как запускается/записывается и отлажывается программа ? В этих процах нет же встроенной флэши и SRAM ...

Из камня торчит полноценный JTAG - цепляемся к нему и вперед. Насчет SRAM ошибаетесь - внутри чипа есть накристальная память OCM. Другое дело, что ее достаточно мало.

У нас рядом стоит QSPI-Flash, с которой грузится SoC, ровно как на многих других подобных камнях (всякие FPGA, например).

[AlexandrY 2]

15 minutes ago, Arlleex said:

Это такой, можно сказать, чуть более сложный микроконтроллер

Лучше расскажите почему не осилили линукс на нем и застряли на достаточно убогой FreeRTOS.
Почему уже двое здесь не могут осилить линукс на Zynq.
Что там с ним не так?