Программируем Raspberry Pi на голом железе

[@BlackSwan]

Вот прямо следит за мной хабр, который раз уже убеждаюсь :)
Как раз на НГ подарил себе RaspberryPi, поганял немного и задумался: нужен ли мне для поделок линукс, може как и без него можно. Вот и ответ. Пишите еще, пожалуйста, буду изучать с удовольствием Ваши статьи.

[@isden]

Аналогично, посмотрел на линукс там, и задумался…
Начал было смотреть вот в эту сторону — www.stevebate.net/chibios-rpi/GettingStarted.html — но пока руки не дошли.

[@grikukan]

Я вот как раз собирался их библиотеку в следующих выпусках юзать.
Если же говорить об ОСРВ то, ИМХО, лучше FreeRTOS.

[@grikukan]

Хотелось бы написать еще, но пока времени мало. Но как только — так сразу.

[@mwizard]

А откуда взялось это правило, что после ARM9 — только линукс? И на чем компилируют линукс, если без него никак?

[@grikukan]

Видимо я не совсем правильно выразился. Конечно, stand-alone приложения есть и на cortex-a55, но, это довольно редко делают, и из-за этого по данному вопросу мало документации.

[@icoz]

Думаю, что логика такая: раз частота хорошая и ресурсов много, то зачем мучиться и писать на низком уровне? Это не столько правило, сколько «народ не заморачивается».

[@mwizard]

Ну да, сначала «не на хлеб же ее, эту {частоту, память, место} намазывать», а потом интерфейсы тормозят, как и 20 лет назад.

[@JIghtuse]

Мне кажется, с Linux можно многое на такой железке сделать. Железо всё подхвачено, используй-не хочу. Но как эксперимент здорово.
Отформатируйте код с помощью <source>, пожалуйста. Выглядит плоско.

[@grikukan]

Спасибо, отформатировал

[@enclis]

Все среды программирования(keil, IAR, Atolic) поддерживают максимум ARM9.

Для этих целей существует ARM DS-5 Development Studio.

[@grikukan]

Ладно, ладно, убедили.
Просто для меня (и не только меня), привыкшему к Кейлу, переход может быть довольно сложным.

[@uSasha]

IAR поддерживает все ARM ядра:
www.iar.com/Products/IAR-Embedded-Workbench/ARM/

ПС часть с отладкой осталась нераскрытой.

[@enclis]

Отладка по JTAG/SWD из списка «Hardware debugging support».

[@uSasha]

Я не спрашивал про IAR :)

Я говорю, что статья похоже на сферического коня:
да, лампочку мы зажгли, но только дальше уйти с помощь скомпилировал->залил->проверил не получится, да можно использовать printf и мигание диодами, но для сложной периферии, типа кодеров/декодеров видео, Ethernet, USB этого как то мало.

Я думаю можно было раскрыть хотя бы одну связку типа GDB + j-link.

Да и компилировать, доставать из платы карту, вставлять ее в комп, переписывать файл на карту, вынимать из компа, вставлять в плату — долго, не правда ли?

Можно было бы рассказать про NFS например.

[@KriegeR]

Огромное спасибо за статью. Вы не поверите, но я ее ждал давно. :)
Дело в том, что совершенно случайно и совершенно бесплатно мне попал в руки сей девайс. А ни в АРМах, ни в embedded технологиях я особо не знаток; и вообще, что сделать можно с этим «компьютером» — хз. Но и железо даром пылится на полочке. Благодаря Вашей статье — у меня есть отправная точка.

[@grikukan]

Это копия friendly arm mini 6410?

[@KriegeR]

Впервые услышал о Friendly Arm. Судя по всему, made-in-china-копия, при чем идентичная.

[@grikukan]

Можно, но довольно сложно

[@JIghtuse]

Зачем вам эти картриджи? Есть куча проектов по созданию эмулятора приставок на Raspberry Pi, в систему грузятся ROM и все дела.
Вот пример: imgur.com/a/mZRWa
Вот ещё, здесь можно догружать игры через USB: www.igorkromin.net/index.php/2013/01/08/raspberry-pi-in-a-nes-case-part-1-wiring-up-the-front-panel-and-external-connectors/

[@KriegeR]

Дело в том, что мне досталось только «железо» и пара даташитов. Не осилил, в общем, с наскоку. Автор сейчас предположил, что девайс может быть копией Friendly Arm. Сейчас погуглил и, судя по всему, так оно и есть. Правда, к FA есть мануалы по установке ОС и прочие интересные штуки.

[@trenkinan]

www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/

[@1099511627776]

Извините за нубский вопрос но
#define GPIO_BASE 0x20200000UL
Смотрю даташит но не вижу этого адреса а сам GPIO начинается с 0x 7E20 0000 (страница 90 даташита)
Можете сказать куда именно смотреть?

[@JIghtuse]

Мда, не зря я автору минус сразу влепил. В оригинале и код человечески выглядит, и про exit объяснено, и расписано всё более подробно. В частности и конечная цель поставлена, и туториалы на ассемблере указаны, которые Brian транслировал на Си.

[@grossws]

Появился новый пост автора: habrahabr.ru/post/208780/. Тенденция не печальная. Не торт местами…

[@esinev]

Примеры (bare metal) для rasberry pi — github.com/dwelch67/raspberrypi

[@ivlis]

А можно объяснить зачем это вообще нужно? Вроде как операционные системы как раз придумали, чтобы не писать на голом железе. Все эти #define PIN42 0xDEADBEEF вгоняют в полную печаль…

[@shtirlitsus]

быстродействие, сэр

[@ivlis]

Ну например для чего? То есть какая должна быть задача, которая по вычислительной мощи требовала бы процессор уровня rPi и при это её были бы критичны задержки уровня ядра Linux?

[@eXod]

Управление двигателями? Да в общем-то многие задачи управления для быстротекущих процессов. Те же роботизированные машинки — управляющий сигнал должен быть сгенерирован гарантированно за определённое, достаточно малое, время. Хотя даже тут на голом железе не пишут, применяют всякие RTOS.

[@ivlis]

Вам для управления двигателем нужны процессор в 700MHz и 512MB оперативной памяти? Вашим роботом надо же как-то управлять. Ethernet стек сами будете реализовывать?

[@grossws]

Ethernet стек сами будете реализовывать?

Что есть Ethernet-стек? Ethernet MAC+PHY там в виде LAN9512, который по совместительству usb-hub. Вот реализация USB-стека — куда более страшное дело, чем настройка MAC+PHY.

А TCP/IP стек — дело не страшное: lwIP, например.

[@ivlis]

Но зачем это всё, если оно уже сто раз написано, отлажено и может быть использовано в готовом виде? Это ж не микроконтроллер!

[@grossws]

Я и не говорю, что это нужно на BCM2835. Это было замечание к вашему «Ethernet-стек».

Даже на простейших восьмибитных контроллерах можно написать элементарный драйвер для ethernet (я, например, использовал внешний MAC+PHY ENC28J60 совместно с AVR) и прикрутить минималистичный TCP/IP или UDP/IP стек. Это не говоря уже про какой-нибудь STM32 (F105/F107, F207/F217, F407/F417, F427/F437, F429/F439), где есть Ethernet MAC из коробки, с готовыми к употреблению DMA-каналами для сети. Так что ethernet+tcp/ip — это не rocket science, даже если самому реализовывать весь стек. Читаешь RFC и пишешь =)

[@ivlis]

Ну всё вообще не Rocket Science, зачем только. На микроконтроллер вы OS общего назначения не поставите, поэтому приходится всё ручками. Именно приходится, ничего хорошего в этом нет. Для того чтобы программировать на Bare metal нужна какая-то очень веская причина. В век интернета причина «не можем найти программиста» выглядит как-то не особо.

[@grossws]

На микроконтроллер вы OS общего назначения не поставите, поэтому приходится всё ручками. Именно приходится, ничего хорошего в этом нет.

Зачем так категорично? Если вам не нужна вытесняющая многозадачность, разграничение ресурсов и высокоуровневые абстракции — то ОС не нужна. Те же драйвера без уровней абстракции ядра ОС часто пишутся проще и требуют меньше держать в голове (в силу дырявых абстракций, как минимум). Так что не приходится, а выбираем инструмент в соответствии с задачами.

На том же ARM7 (не говоря уже про ARM9, ARM11 и ARM Cortex-A) вполне можно запускать Linux. Вопрос в том, надо ли это: требуется установка внешней RAM и ROM, что повышает требования к железу на порядки (в частности, уже невозможно уместиться на двухслойной плате, требуется куда более тщательное проектирование железа, т. к. используются высокочастотные параллельные интерфейсы и т. п.). Зачем всё это для программы, которая умещается в десяток-другой килобайт?

[@uSasha]

Вы имели ввиду uСLinux, без MMU линукс не запустить.

[@grossws]

Да, точно, в ARM7 же только MPU, там только uCLinux можно.

[@eXod]

Собственно поэтому я и говорю про RTOS.

[@grossws]

Операционные системы придумали, чтобы добавить слой абстракции (в т. ч. процессы, например). Но где-то обращение к железу всё равно будет: в драйвере или сервисе, например. И там работа с железом всё равно будет. Другое дело, что эти драйвера уже, вероятно, давно написаны.

Проблема Linux, как системы с элементами мягкого реального времени — в негарантированном времени отклика.

Если хочется разумных сроков разработки и необходимо RT, то наиболее простым будет взять RTLinux: сочетание RT-ядра и обычного ядра Linux в качестве процесса. Или QNX Neutrino, например, но не факт, что драйвера под неё есть.

[@ivlis]

Ну правильно, надо поставить операционную систему реального времени если очень нужно. Под rPi их даже больше чем одна.

[@enclis]

В некоторых задачах аудио и видео обработки пишут под bare metal.

[@ivlis]

В задачах обработки аудио и видео используются DSP. В некоторые ARM процессоры они даже встроены. Зачем использовать для это процессор общего назначения?

[@enclis]

Я не говорю, что нужно использовать процессоры общего назначения для реализации любых задач аудио и видео обработки. Я знаю, что так изредка но делают. Как и зачем я не могу сказать точно.

[@grossws]

Может потому, что специалиста, знающего ARM найти проще, чем такового, знающего какой-нибудь Blackfin или SHARC?

[@davinchi]

> Это связано с негласным правилом, что на голом железе пишут до ARM9, а после на Линуксе.

Это прямо скажем неправда. Даже для Cortex-A5/Cortex-M0 пар вида Vybrid есть специальные RTOS: MQX.

> 2) Даташит на процессор
Это не datasheet на процессор, это datasheet на периферию.

После того как мой RPi сдох я как-то понял, что проект целиком и наглухо проприетарный и ничего глубже, чем datasheet на периферию, на него не найти. В отличии от кучи других процессоров: lpc, stm, vybrid.

[@davinchi]

В том, что оно вообще грузится проприетарным загрузчиком и драйвер для GPU — тоже blob.

А сдох непонятно по какой причине, и весь форум дружно ответил «ну хз». Не выходит из ресета.

[@davinchi]

Во-первых, мимо.

Во-вторых, я присмотрел себе Beagle Bone Black или сразу PandaBoard ES. Вообще, я вполне мог бы взять доски той компании, в которой работаю, но к несчастью, мне это запрещено NDA. У BBB есть PRU, что некоторый плюс.

[@mwizard]

А в какой компании работаете? И почему такое странное ограничение, что нельзя пользоваться продукцией компании, в которой работаешь?

[@davinchi]

Ограничение вполне разумное: потому-что багаж знаний разработчика — собственность компании.

Название не скажу, извините.