Комментарии 62
Вот прямо следит за мной хабр, который раз уже убеждаюсь :)
Как раз на НГ подарил себе RaspberryPi, поганял немного и задумался: нужен ли мне для поделок линукс, може как и без него можно. Вот и ответ. Пишите еще, пожалуйста, буду изучать с удовольствием Ваши статьи.
Как раз на НГ подарил себе RaspberryPi, поганял немного и задумался: нужен ли мне для поделок линукс, може как и без него можно. Вот и ответ. Пишите еще, пожалуйста, буду изучать с удовольствием Ваши статьи.
Аналогично, посмотрел на линукс там, и задумался…
Начал было смотреть вот в эту сторону — www.stevebate.net/chibios-rpi/GettingStarted.html — но пока руки не дошли.
Начал было смотреть вот в эту сторону — www.stevebate.net/chibios-rpi/GettingStarted.html — но пока руки не дошли.
Хотелось бы написать еще, но пока времени мало. Но как только — так сразу.
А откуда взялось это правило, что после ARM9 — только линукс? И на чем компилируют линукс, если без него никак?
Видимо я не совсем правильно выразился. Конечно, stand-alone приложения есть и на cortex-a55, но, это довольно редко делают, и из-за этого по данному вопросу мало документации.
Думаю, что логика такая: раз частота хорошая и ресурсов много, то зачем мучиться и писать на низком уровне? Это не столько правило, сколько «народ не заморачивается».
Мне кажется, с Linux можно многое на такой железке сделать. Железо всё подхвачено, используй-не хочу. Но как эксперимент здорово.
Отформатируйте код с помощью <source>, пожалуйста. Выглядит плоско.
Отформатируйте код с помощью <source>, пожалуйста. Выглядит плоско.
Все среды программирования(keil, IAR, Atolic) поддерживают максимум ARM9.
Для этих целей существует ARM DS-5 Development Studio.
Ладно, ладно, убедили.
Просто для меня (и не только меня), привыкшему к Кейлу, переход может быть довольно сложным.
Просто для меня (и не только меня), привыкшему к Кейлу, переход может быть довольно сложным.
IAR поддерживает все ARM ядра:
www.iar.com/Products/IAR-Embedded-Workbench/ARM/
ПС часть с отладкой осталась нераскрытой.
www.iar.com/Products/IAR-Embedded-Workbench/ARM/
ПС часть с отладкой осталась нераскрытой.
Отладка по JTAG/SWD из списка «Hardware debugging support».
Я не спрашивал про IAR :)
Я говорю, что статья похоже на сферического коня:
да, лампочку мы зажгли, но только дальше уйти с помощь скомпилировал->залил->проверил не получится, да можно использовать printf и мигание диодами, но для сложной периферии, типа кодеров/декодеров видео, Ethernet, USB этого как то мало.
Я думаю можно было раскрыть хотя бы одну связку типа GDB + j-link.
Да и компилировать, доставать из платы карту, вставлять ее в комп, переписывать файл на карту, вынимать из компа, вставлять в плату — долго, не правда ли?
Можно было бы рассказать про NFS например.
Я говорю, что статья похоже на сферического коня:
да, лампочку мы зажгли, но только дальше уйти с помощь скомпилировал->залил->проверил не получится, да можно использовать printf и мигание диодами, но для сложной периферии, типа кодеров/декодеров видео, Ethernet, USB этого как то мало.
Я думаю можно было раскрыть хотя бы одну связку типа GDB + j-link.
Да и компилировать, доставать из платы карту, вставлять ее в комп, переписывать файл на карту, вынимать из компа, вставлять в плату — долго, не правда ли?
Можно было бы рассказать про NFS например.
Огромное спасибо за статью. Вы не поверите, но я ее ждал давно. :)
Дело в том, что совершенно случайно и совершенно бесплатно мне попал в руки сей девайс. А ни в АРМах, ни в embedded технологиях я особо не знаток; и вообще, что сделать можно с этим «компьютером» — хз. Но и железо даром пылится на полочке. Благодаря Вашей статье — у меня есть отправная точка.
Дело в том, что совершенно случайно и совершенно бесплатно мне попал в руки сей девайс. А ни в АРМах, ни в embedded технологиях я особо не знаток; и вообще, что сделать можно с этим «компьютером» — хз. Но и железо даром пылится на полочке. Благодаря Вашей статье — у меня есть отправная точка.
НЛО прилетело и опубликовало эту надпись здесь
Можно, но довольно сложно
НЛО прилетело и опубликовало эту надпись здесь
Зачем вам эти картриджи? Есть куча проектов по созданию эмулятора приставок на 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/
Вот пример: 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/
НЛО прилетело и опубликовало эту надпись здесь
Извините за нубский вопрос но
Смотрю даташит но не вижу этого адреса а сам GPIO начинается с 0x 7E20 0000 (страница 90 даташита)
Можете сказать куда именно смотреть?
#define GPIO_BASE 0x20200000ULСмотрю даташит но не вижу этого адреса а сам GPIO начинается с 0x 7E20 0000 (страница 90 даташита)
Можете сказать куда именно смотреть?
НЛО прилетело и опубликовало эту надпись здесь
Мда, не зря я автору минус сразу влепил. В оригинале и код человечески выглядит, и про exit объяснено, и расписано всё более подробно. В частности и конечная цель поставлена, и туториалы на ассемблере указаны, которые Brian транслировал на Си.
Появился новый пост автора: habrahabr.ru/post/208780/. Тенденция не печальная. Не торт местами…
Примеры (bare metal) для rasberry pi — github.com/dwelch67/raspberrypi
А можно объяснить зачем это вообще нужно? Вроде как операционные системы как раз придумали, чтобы не писать на голом железе. Все эти #define PIN42 0xDEADBEEF вгоняют в полную печаль…
быстродействие, сэр
Ну например для чего? То есть какая должна быть задача, которая по вычислительной мощи требовала бы процессор уровня rPi и при это её были бы критичны задержки уровня ядра Linux?
Управление двигателями? Да в общем-то многие задачи управления для быстротекущих процессов. Те же роботизированные машинки — управляющий сигнал должен быть сгенерирован гарантированно за определённое, достаточно малое, время. Хотя даже тут на голом железе не пишут, применяют всякие RTOS.
Вам для управления двигателем нужны процессор в 700MHz и 512MB оперативной памяти? Вашим роботом надо же как-то управлять. Ethernet стек сами будете реализовывать?
Ethernet стек сами будете реализовывать?Что есть Ethernet-стек? Ethernet MAC+PHY там в виде LAN9512, который по совместительству usb-hub. Вот реализация USB-стека — куда более страшное дело, чем настройка MAC+PHY.
А TCP/IP стек — дело не страшное: lwIP, например.
Но зачем это всё, если оно уже сто раз написано, отлажено и может быть использовано в готовом виде? Это ж не микроконтроллер!
Я и не говорю, что это нужно на 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 и пишешь =)
Даже на простейших восьмибитных контроллерах можно написать элементарный драйвер для 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 и пишешь =)
Ну всё вообще не Rocket Science, зачем только. На микроконтроллер вы OS общего назначения не поставите, поэтому приходится всё ручками. Именно приходится, ничего хорошего в этом нет. Для того чтобы программировать на Bare metal нужна какая-то очень веская причина. В век интернета причина «не можем найти программиста» выглядит как-то не особо.
На микроконтроллер вы OS общего назначения не поставите, поэтому приходится всё ручками. Именно приходится, ничего хорошего в этом нет.Зачем так категорично? Если вам не нужна вытесняющая многозадачность, разграничение ресурсов и высокоуровневые абстракции — то ОС не нужна. Те же драйвера без уровней абстракции ядра ОС часто пишутся проще и требуют меньше держать в голове (в силу дырявых абстракций, как минимум). Так что не приходится, а выбираем инструмент в соответствии с задачами.
На том же ARM7 (не говоря уже про ARM9, ARM11 и ARM Cortex-A) вполне можно запускать Linux. Вопрос в том, надо ли это: требуется установка внешней RAM и ROM, что повышает требования к железу на порядки (в частности, уже невозможно уместиться на двухслойной плате, требуется куда более тщательное проектирование железа, т. к. используются высокочастотные параллельные интерфейсы и т. п.). Зачем всё это для программы, которая умещается в десяток-другой килобайт?
Собственно поэтому я и говорю про RTOS.
Операционные системы придумали, чтобы добавить слой абстракции (в т. ч. процессы, например). Но где-то обращение к железу всё равно будет: в драйвере или сервисе, например. И там работа с железом всё равно будет. Другое дело, что эти драйвера уже, вероятно, давно написаны.
Проблема Linux, как системы с элементами мягкого реального времени — в негарантированном времени отклика.
Если хочется разумных сроков разработки и необходимо RT, то наиболее простым будет взять RTLinux: сочетание RT-ядра и обычного ядра Linux в качестве процесса. Или QNX Neutrino, например, но не факт, что драйвера под неё есть.
Проблема Linux, как системы с элементами мягкого реального времени — в негарантированном времени отклика.
Если хочется разумных сроков разработки и необходимо RT, то наиболее простым будет взять RTLinux: сочетание RT-ядра и обычного ядра Linux в качестве процесса. Или QNX Neutrino, например, но не факт, что драйвера под неё есть.
В некоторых задачах аудио и видео обработки пишут под bare metal.
В задачах обработки аудио и видео используются DSP. В некоторые ARM процессоры они даже встроены. Зачем использовать для это процессор общего назначения?
> Это связано с негласным правилом, что на голом железе пишут до ARM9, а после на Линуксе.
Это прямо скажем неправда. Даже для Cortex-A5/Cortex-M0 пар вида Vybrid есть специальные RTOS: MQX.
> 2) Даташит на процессор
Это не datasheet на процессор, это datasheet на периферию.
После того как мой RPi сдох я как-то понял, что проект целиком и наглухо проприетарный и ничего глубже, чем datasheet на периферию, на него не найти. В отличии от кучи других процессоров: lpc, stm, vybrid.
Это прямо скажем неправда. Даже для Cortex-A5/Cortex-M0 пар вида Vybrid есть специальные RTOS: MQX.
> 2) Даташит на процессор
Это не datasheet на процессор, это datasheet на периферию.
После того как мой RPi сдох я как-то понял, что проект целиком и наглухо проприетарный и ничего глубже, чем datasheet на периферию, на него не найти. В отличии от кучи других процессоров: lpc, stm, vybrid.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Программируем Raspberry Pi на голом железе