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

Может быть, я что-то не понимаю, но все эти A7 и A9 работают под линуксом, и в этом плане разницы нет.

Смотря на каком уровне писать. Если прикладные программы под Линух/Андроид, то разницы нет. А вот если драйверы железа, физически находящегося на кристалле процессора, то разница, конечно, вполне может быть. Ну и, наконец, у каждого ядра -- свои собственные аппаратные глюки. Прикладные программисты с этим сталкиваются редко, но системщикам необходимо учитывать и обходить их тем или иным способом.

Спасибо! А что бы посоветовали, Cortex A7 как я понял с большим кол-вом мануалов из за использования в Rospberri Pi или все же Cortex А9, так как с ним в ближайшем будущем придется работать.

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

Для начала ответьте на разумно заданный здесь вопрос: http://electronix.ru/forum/index.php?showt...t&p=1365523
По уровню вопроса, полагаю, что прикладные. Посему начинайте писать, хоть на PC, под более-менее совместимую операционку.

Драйверы чего вы хотите писать? Контроллера прерываний, кэш памяти, SMP, или системы критических исключений?? Сомневаюсь. В лучшем случае будете дорабатывать или напишите драйвер какого-либо периферийного устройства, в этом случае вам хоть А5, А7 или 9 без разницы.

В основном работа с портами, UART, I2C, SPi, USB, SPort, Ethernet и другие, можно сказать общение с периферией, другими процессорами, использование GPIO под свои нужды. В общем все что раньше проделывалось на DSP BlackFin.

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

Пустые слова. С "портами" можно работать по разному, например, открываете сокет и работаете с Ethernet/IP/UDP/TCP... Чем не работа? И ни какой связи с железом. Чистая приладуха.

А тут кто-то должен знать, что Вы проделывали с BlackFin? Например, тот-же линукс на нем и вперед.

Должно же быть общение, чтобы выдать команду по SPI например или принять. Или по флагу, включить светодиод. Разве такие действия будет трудно выполнить на таком "звере"?

Трудно.

Хорошо, как я понял, если А9 в дальнейшем, значит А9 и надо брать. Так как все действия будут происходить на голом железе. И переход с А7 на А9 может натолкнуть на различного рода трудности?

Ну что же, удачи. Потом не говорите, что вас не предупреждали.


Если вы справитесь с титаническим трудом запуска A7 на голом железе, то вам не составит труда проделать всё то же самое снова с A9. Так что не волнуйтесь.

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

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

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


Более того даже при переходе с одного А9 на другой А9, у вас будут теже трудности. Ну попробуйте в STM любом передать что-то по SPI не заглядывая в документацию...

Даа.. не обнадеживающе все как-то звучит.. Запись в память, чтение из памяти. Согласен, без документации нормальной где нет временных диаграмм ничего не получится. Присматриваюсь к RK3066 может кто имел дело?

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

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

manch или как-то так, под все общее неодобрение запускал что-то на голом железе из тяжелых. Вроде хвастал что запустил

Ну титанический или нет, это от задачи зависит, а вот то, что потом "то вам не составит труда проделать всё то же самое снова с A9. Так что не волнуйтесь" это в общем именно так.

Да как раз его сейчас изучаю.. По документации у них все норм, есть клоки на каждый интерфейс, надеюсь документация полная. Если брать такую шляпу Marsboard RK3066 я не прогадаю?

Не спешите. Есть ещё документация на процессор Cortex-A9. Вроде бы там нужно настраивать MMU и кэши, что довольно весело. С контроллером прерываний нужно бодаться. Ну и так далее.


Ага. Вот тут.

Если Вы собираетесь работать на голом железе, то надо не просто А9 брать, а именно тот, на котором и собираетесь работать, поскольку один А9 от другого А9 (другой фирмы) может отличаться кардинально. У них будет совпадать только собственно процессорная часть (грубо говоря, система команд, MMU и кэши), вся периферия может быть абсолютно иной.

Если это меня имеют ввиду, то запустил, причем уже давно

Если хотите пройти мой путь, то начните с самого простого и главного - выберите чип с максимальной документацией и САМОЕ главное - чтоб для него был хоть самый минимальный SDK. Как тот, кто все это осиливал скажу, без этого чип вам не поднять!

Затем выберите среду разработки. В моем случае - это был ИАР, мне нравится его иде и компилятор, поэтому и сижу на нем уже лет 10, но это добавило мне порцию геморроя в виде портирования того, что нарыл в инете, писанного под гцц, на иар...

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

Затем попробуйте сделать пробный проект - помигать диодом, если получится, вы прошли 30 % пути...

Да, да про вас простите не помнил всех букв.
Зря вы это сделали линукс ставить надо было.... теперь вы нам немой укор.

Поделились бы с товарищем что вы запустили, может ему тоже самое подойдет, и будет хоть с кем посоветоваться

Я прощаю

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

ЗЫ. Сначала пусть хоть камень правильно выберет, а там посмотрим...



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

Я запускал 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 буду вползать Думаю на первоначальное освоение хватит месяца.

Удалено.

Мсье знает толк в извращениях
Зачем, когда есть готовые процедуры инициализации, только немного поискать...



В принципе, базовые сведения есть, хотя скудноваты. Усб, похоже, несовместимый с ehci, да и sdk нет, придется выколупывать из bsp линухи... Вообщем, я б не взялся - долго и муторно. По мне все-равно лучше мх или ситары нет...

Насчет "лучше" утверждение спорное. По качеству документации и поддержки - да.
По степени интеграции тот же A20 рвет imx как тузик грелку. И ценовой фактор в нынешнее кризисное время со счета не сбросить. imx весьма небюджетен.

Зачем искать и разбираться в них, если есть мануал?

В камушках allwinner или rockchip в мануале описаны крохи. Даже в imx процентов 30 не документировано (не считая gpu и vpu). А в BSP используется.

К моему удивлению наткнулся на довольно таки дешевую.. нужную вещь.. DE0-Nano-SoC. По альтере явно будет вся документация. Просто изначально цена отпугивала. Может кто знает где купить в России без особой наценки? а то через терасик 99$ + доставка 50$) за доставку жалко отдавать)

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

Ещё и ПЛИС в эту кучу? Будете сами на верилоге ваять uart, spi, gpio и всё такое прочее?
Я вас умоляю, хватит потешать честной народ.

Да, сами) я сам думаю.. во что я ввязался..

А вообще что надо-то? Задача из области ЦОС, которую перестал осиливать Blackfin?

MMU в ARM9 входит в состав ядра, которое хорошо описано в своём мануале (я про L-137).

Если вы про мануалы от АРМ - то это полная фуфлень, использовал только, как справочник по регистрам, про ММУ и кэш хорошо описано у атмела.

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

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

Да ладно, нормальный там стиль, уж точно не "фуфлень". По крайней мере, даже мыслей не возникало читать такие же описания у атмела и прочих после изучения родной документации.

Под "нормальным" я понимаю тогда, когда есть не просто перечисление регистров с кучей параметров, а еще и наличие примеров инициализации для самых распространенных применений, например, инициализация кэша или контроллера прерываний с объяснением команд. Вот такой докой будет приятно пользоваться

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

Вообще конечно странно вы проц выбираете, по названию, а не по необходимым свойствам. Но СОКи эти прятная штука, вообще проц + ПЛИС супер связка, а тут еще и шина проца в ПЛИС выведена, хорошая штука. Нам арм А не нужен, потому ставим внешние Мки к ПЛИС, а так я бы точно такие собирал, правда от ксалинкса, но это уже детали...

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

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

перепилить под себя вендорский BSP? долго ли умеючи...

Ну все знают, что ARM описывает ядро в вакууме.
Эта дока имеет смысл только после ознакомления с окружением этого ядра в каждом конкретном SoC-е и ограничениями.
В обязаловку читать надо и доку от ARM-а и все ограничения накладываемые реализацией.

Год - то конечно многовато, я думаю, у меня ушло 8 месяцев, примерно, да и то, первые 2 сам тупил сильно, т.к. было непонятно, как в камень залить свой бинарник, потом пошло гораздо веселее



Так говорит тот, кто ни разу этого не делал. Ибо не надо путать BSP и SDK, в первом только настройка девайсов на базовый режим работы и их клоков...

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

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

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

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