Перейти к содержанию

    

Cortex A7, программирование и отладка.

Всем привет!

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

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
39 минут назад, Metallist64 сказал:

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

да

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

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

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

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

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

Ещё CCS от TI.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, Metallist64 said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
11 hours ago, Metallist64 said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
11 hours ago, Metallist64 said:

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

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

11 hours ago, Metallist64 said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
48 minutes ago, dxp said:

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Вот этот 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 - в разы медленнее, чем обеспечивают аппаратные интерфейсы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
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 в каком либо виде должна будет быть в любом случае, иначе опять будет выброс денег.  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
3 hours ago, dxp said:

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

 

Цитата

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
15 minutes ago, Arlleex said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

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

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти