ARM Cortex A7 = A9 при программировании? Опции

[4uLABEK]

Доброго всем дня!
Возник такой вопрос.
Выбираю Китовскую плату, вообще будет использоваться в дальнейшем Cortex a9, можно ли практиковаться на cortex a7? Например написав программу на А7, зашить ее в А9? Или возникнут многие сложности и лучше сразу купить Китовскую плату на А9. например marsboard RK3066?

[scifi]

Вроде бы тут кто-то OMAP от техасских инструментов запускал на голом железе. Или это был i.MX от фрискейла... В общем, что-то такое.
Кстати, гугл говорит, что для этого рокчипа есть мануал. Скачайте, полистайте, чтобы получить какое-то представление о масштабе бедствия.

[jcxz]

Вроде бы тут кто-то OMAP от техасских инструментов запускал на голом железе. Или это был i.MX от фрискейла... В общем, что-то такое.
Кстати, гугл говорит, что для этого рокчипа есть мануал. Скачайте, полистайте, чтобы получить какое-то представление о масштабе бедствия.

Я запускал OMAP L-137
Сперва запустил на голом, потом ещё портировал на него uCOS. И портировал USB-стек.
Всё - ручками, внимательно вчитываясь в доки: и запуск ядер (через PRU-ядро), и инит кучи периферии, и взаимодействие ядер, и MPU и даже MMU (хотелось кеш данных включить) на ARM9-ядре - всё сам по pdf-кам.
Никакими UBoot-ами не пользовался, даже не глядел в них. Раз только попытался глянул в реализацию USB-стека в линухе для этого МК (в примерах для L-137 к сожалению не было примера stand-alone стека, предлагалось только пользоваться какой-то закрытой операционкой в бинарниках или линухом), но понял что в этом лесу я буду разбираться дольше, чем портирую готовый USB-стек из примеров для LPC17xx переписав уровень абстрагирования от периферии (HAL).
И библиотеками никакими не пользовался - брал даташит на периферию, описывал структурами регистры периферии и писал драйвер.
Ничего сверхъестественного или невозможного нет, первый старт с поддержкой минимальной периферии, GPIO, тактирования, отладочного вывода в UART - примерно через месяц-полтора насколько помню.
Самое титаническое, что там есть - это объём доков, раз в несколько больше чем на среднем Cortex-M. Особенно на всякую сложную периферию типа USB, EDMA, MMU. Как правило она там навороченная, так что и описания объёмные.
Всякие UART, SPI, I2C, ... - по сложности мало отличаются от МК класса на ядре Cortex-M. Ну McASP правда посложнее немного.
Да - и более-менее глубокая оптимизация под ядро C674x тоже время заняла порядочно.
Всё остальное - ерунда, если есть опыт в освоении многих других МК. Месяца 2-3 - и будете хорошо ориентироваться в этом МК.

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

PS: Скоро кажись в LPC4370 буду вползать Думаю на первоначальное освоение хватит месяца.

[AlexandrY]

Всё остальное - ерунда, если есть опыт в освоении многих других МК. Месяца 2-3 - и будете хорошо ориентироваться в этом МК.

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

PS: Скоро кажись в LPC4370 буду вползать Думаю на первоначальное освоение хватит месяца.

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

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

[jcxz]

Вот что-то не верю.
Покажите плату, дивайс или что вы там сделали с фоткой и доказательствами что это заработало.
Цикл освоения SoC-а такого уровня не менее года по моим прикидкам. Если вы действительно разрабатываете весь дивайс сами.

Вопрос веры и религии - это личное дело каждого.
SoC-и я не осваивал, могу говорить только про то, что делал.
Конечно под "освоением" я понимаю не то, что сел и N-месяцев изучаешь МК от корки до корки целиком. Это глупость, имхо. Изучение всегда веду по мере необходимости.
Первый этап: освоение базы (ядро (если нужно и только нужные изначально его возможности), система тактирования, GPIO, управление питанием (если нужно), системная конфигурация, контроллер прерываний), таймеры, внешняя память (если надо), натягивание ОС (если нужно) и т.д. По завершению этого этапа, получаю базис ПО, позволяющий управлять тактированием ядра и отдельных частей, управлять пинами GPIO (мой API), имеющий отладочный вывод в UART (со всем API). Всё это стараюсь сделать (насколько возможно) под свой стиль API, который у меня примерно одинаков во всех проектах на МК от MSP430 до M4 и L-137.
На этом считаю базовое освоение оконченным и приступаю к реализации функционала необходимого по проекту. В процессе этого конечно тоже продолжаю осваивать необходимую периферию. Ненужную периферию не изучаю. Постоянно в процессе доизучиваю более глубоко то что было по-быстрому пройдено на первом этапе и переписываю. MMU кстати вообще я изучил уже в конце всего проекта, через два года после начала, когда уже весь прикладной функционал был давно реализован и отлажен.
Первый этап на L137 у меня длился примерно 1.5месяца. Довольно долго. На МК на M-ядрах обычно меньше: 2-3 недели.

[AlexandrY]

Вопрос веры и религии - это личное дело каждого.

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

А пока даже упомянутая вами последовательность изучения вызывает вопросы.
Если MMU отложили на конец, то значит все время до этого неправильно инициализировали DMA и работали не на максимальной производительности.
Так зачем вообще тогда выбрали производительную архитектуру. Все то же можно было сделать и на Arduino.

Вопрос не в религии, а в репутации. Вы ж понимаете.

[jcxz]

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

Я уже тут вроде где-то описывал - повторяться неохота.
Кратко говоря: кардиограф на 24 канала по 8кГц каждый (ADS1298) (только не надо меня спрашивать - зачем так много каналов и так много кГц - это было требование заказчика, в прикладную область я не вникал, для этого в проекте были профессора медицины) с кучей разной ЦОС (разные фильтры, FFT и спец.алгоритмы). Причём ЦОС предполагалось перетащить с готовой работающей на PC модели, соответственно - не оптимизированной под DSP и вся в double.
Приём потока с 3-х 8-канальных АЦП висящих на McASP+EDMA (с передачей одного из каналов на аудио-ЦАП на этом-же McASP), обработка, передача потока обработанных данных, а также вычисленных характеристик на USB клиенту.

А пока даже упомянутая вами последовательность изучения вызывает вопросы.
Если MMU отложили на конец, то значит все время до этого неправильно инициализировали DMA и работали не на максимальной производительности.
Так зачем вообще тогда выбрали производительную архитектуру. Все то же можно было сделать и на Arduino.

Ну-ну на дуине поток в > 192kS/s с кучей ЦОС на double??? Такое думаю даже ни один M4F, гордо называемый маркетологами "DSP", не потянет.
Если Вы про EDMA3, то он работает независимо от MMU. Если про другие DMA - я их не использовал.
Да, работал не на максимальной производительности. После утаптывания PC-шного алгоритма под DSP, оказалось, что DSP и ARM-ядра каждое загружены не более чем на 10% на 300МГц тактовой.
Так что оно особо и не нужно было.
Но потом заказчик озвучил, что хочет продолжить проект и добавить кое-какой обработки, вот под это дело я авансом решил ещё немного разгрузить ARM9-ядро и включить кеш данных (что давно хотел, но руки не доходили). Вот и прописал инит MMU.

А DMA в этих процах без MMU не обходится?

Конечно обходится. Если речь про EDMA3, так это вообще там часть периферии не относящейся к конкретному ядру. С ним может хоть DSP хоть ARM работать, а можно вообще - одним каналом рулить ARM, другим - DSP. А вот MMU - относится только к ARM-ядру. У DSP своё кеширование, а виртуализации памяти вообще нет (насколько я помню).
Есть правда ещё какое-то IDMA, но это только уже в DSP-ядре и его я не использовал и не разбирался.

[AlexandrY]

Я уже тут вроде где-то описывал - повторяться неохота.

Да, наш форум с короткой памятью. Приходится повторяться.
За ответ спасибо.