[Motion 0]

Добрый день.

 

Более простые embedded системы строятся на базе uC + RTOS (или без нее), более сложные на базе SoC + Linux.

 

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

 

Сначала полностью перешел на своем ПК на Linux вместо Windows. Перепробовал несколько дистрибутивов.

 

Потом полностью прошел вот этот курс по основам работы с Linux. Разобрался.

 

Дальше углубился в книги по Linux Kernel (Linux Kernel Development(Роберт Лав) и Linux Device Drivers). Немного понял как устроено само ядро и немного как писать модули (драйверы) используя примитивы ядра.

 

Устал копаться в теории, захотелось что-то сделать на практике. Взял Raspberry Pi2, запустил на ней Raspberian и решил написать драйвер для управления светодиодом подключенным к GPIO. Сделал обзор книг по Raspberry Pi. Но по их содержанию понял что работа с GPIO реализована с помощью языка Python.

 

Ну и вопросы:

 

1) почему Python, а не С? В теоретических книгах по ядру используют Си для написания драйверов, а в практических книгах по RP везде Python. Если все-таки С используется - подскажите книги с примерами.

2) расскажите более подробно об embedded системах на базе Linux - примеры таких устройств в быту, как происходит разработка ПО для них (берут голое ядро, пишут к нему нужные драйвера, бросают их определенный папки и компилируют?). Расскажите о подобных проектах.

3) Какие книги порекомендуете читать дальше?

4) Какой результат мне нужно получить чтобы разобраться с такими системами? Например написать приложение для Linux (userspace) которое через написанный мною драйвер(kernel space) будет управлять светодиодом.

[jorikdima 0]

Прохожу этот же путь :) Чуть с другой бордой, но это не важно.

1. Просто потому что большинство пользователей РПИ пришли из того мира, а не из РТОС. Им привычнее питон.

2. Не отвечу точно, но вы познакомились с buildroot например? Это система постоения рутфс, куда можно подключить и свои приложения/настройки что угодно.

3. Книги напишу вечером, под рукой нет списка.

4. Светодиод это слишком просто. Но вопрос генерации задачи и для меня стоит остро. Что сделать такого, чтоб и не велик изобрести, и под силу было, и охватить многое...

[Tarbal 4]

Буквально в соседней теме обсуждали работу с GPIO. Поищите в интернете про /sys/class/gpio/export.

 

Это способ, предоставленный ядром Линукса. Там драйвер уже написан. Как я понимаю это не совсем то, что вам нужно.

Полагаю тот код что вы нашли на Питоне использует этот интерфейс.

 

Другой способ, который как я понимая вам и нужен:

На Распберри Пи есть документ периферийных устройств. Там вы найдете какие ругистры конфигурируют пины и какие регистры выводят на ножки свои значения.

Вот в своем драйвере это и воплотите точно так же как вы бы делали это без Линукса. Есть два способа (навскидку. может и больше) сделать интерфейс драйвера с пространством пользователя.

1. read/write driver ioctl для управления направлением

2. Писать цоманды через procfs.

 

Будут вопросы -- спрашивайте.

[psL 0]

скрипты питона не нужно компилировать, соответственно не нужен cross toolchain

[Jury093 2]

Устал копаться в теории, захотелось что-то сделать на практике. Взял Raspberry Pi2, запустил на ней Raspberian и решил написать драйвер для управления светодиодом подключенным к GPIO. Сделал обзор книг по Raspberry Pi. Но по их содержанию понял что работа с GPIO реализована с помощью языка Python.

всё зависит от ваших навыков и финансовых возможностей..

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

имхо, у малины не самый большой набор функционала и сеть через юсб не добавляет надежности

как ближайший вариант - посмотрите проект Kodi (exXBMC) https://kodi.tv/

https://kodi.tv/the-official-kodi-edition-raspberry-pi-case/

http://kodi.wiki/view/HOW-TO:Install_Kodi_on_Raspberry_Pi

 

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

 

4) Какой результат мне нужно получить чтобы разобраться с такими системами? Например написать приложение для Linux (userspace) которое через написанный мною драйвер(kernel space) будет управлять светодиодом.

если светодиод объявлен в userspace как устройство, то работать как с обычным файлом:

открыли led/brightness и пишите туда нужное значение

[Motion 0]

Будут вопросы -- спрашивайте.

 

Вы достаточно конкретно ответили с чем разбираться для работы с GPIO.

 

А можно так же по моим вопросам (1-4).

 

 

 

Есть такой документ от Linux Foundation - 10 ways to get started in embedded linux development. Там есть список рекомендуемых книг. Посмотрю их. Может как-то больше проясниться.

 

Еще нашел хорошую книгу по Raspberry Pi. Там есть примеры как на С/C++ так и на Python. Единственная такая книга, совсем свежая (June 2016).

[Lagman 1]

Еще нашел хорошую книгу по Raspberry Pi. Там есть примеры как на С/C++ так и на Python. Единственная такая книга, совсем свежая (June 2016).

На примерах этой книги, https://github.com/derekmolloy/exploringrpi...ee/master/chp05 , можно посмотреть как разными скриптами и языками программирования можно помигать светодиодами. Очень интересно сравнить как это можно сделать на функциональных языках и ООП, например на С и на С++ с ООП.

[x893 34]

Можно читать MagPi там и коды и схемы. Правда 99% фигня типа лампочек, но для изучения самое то, что надо.

[Motion 0]

Вот сегодня общался по телефону с рекрутером на вакансию Embedded Developer.

 

Один из первых вопросов - есть ли опыт разработки под Linux. Ответ отрицательный. Это было одно из ключевых требований.

 

Главные вопросы остаются открытыми - подскажите конкретные книги по изучению данного вопроса и примеры задач после решения которых я "буду в теме".

[jorikdima 0]

Уже наверно не в тему, но пусть будут для кого-то книги, что я использую:

Embedded Linux Primer - A Practical, Real-World Approach (2006)

Prentice.Hall.Embedded.Linux.Primer.2nd.Edition.Oct.2010

OReilly.Building.Embedded.Linux.Systems.Aug.2008

ну и очевидно J.Corbet - Linux Device Drivers 3rd Edition - 2005

[MIKS 0]

Embedded Linux System Design and Development - хоть и относительно старая но до сих пор актуальна

Отличный ресурс с кучей полезнейших материалов в pdf http://free-electrons.com/docs/

[Ananas 0]

вот еще книга для разработки модулей под линукс, да еще и на русском, да еще и с примерами!

http://rus-linux.net/MyLDP/BOOKS/Linux-too...mmers-3.159.pdf

 

У меня вопрос - имел ли кто опыт работы с buildroot?

У меня есть пара вопросов, которые до сих пор в моей голове не укладываются. Есть спецы по buildroot тут?

[jorikdima 0]

У меня вопрос - имел ли кто опыт работы с buildroot?

У меня есть пара вопросов, которые до сих пор в моей голове не укладываются. Есть спецы по buildroot тут?

Не спец, а скорее начинающий :) Но спрашивайте.

[becopt 0]

Нашёл вот такое дело:

Курс на stepik

[Arlleex 131]

Подниму тему, поскольку вопросы примерно похожего характера. Я никогда не имел дела с Linux, сильно не пинайте

 

1. Есть, допустим, плата с Embedded Linux. Я знаю, что там стоит ARM-процессор с известной регистровой моделью. Могу ли я собрать весь проект, например, в Keil и запустить этот проект на выполнение под аппаратным отладчиком? Допустим, пишу я драйвер UART и мне нужно использовать аппаратное прерывание процессора. Теперь цена ошибки не сброшенного pending-бита прерывания, например, обернется зависанием всей системы. А я хотел бы под отладчиком пошагать-поглазеть, где и что сейчас делает процессор. Возможно?

2. В Embedded Linux есть понятие приоритетов прерываний и их вложенности? Допустим, есть Cortex-A9 с GIC-контроллером. На нем крутится Linux с драйвером того же UART-а. По идее обработка прерывания не должна отличаться от bare-metal: при возникновении прерывания считывается источник прерывания с GIC-контроллера и вызывается нужный обработчик. Затем прерывание помечается как обслуженное и происходит возврат к прерванной программе. В Linux также? Или ей нужно из обработчика как-то сказать, что я его обработал? Если так, то зачем? Ведь если система вызвала мой обработчик, то я априори его обработал (смог или нет - это уже мои проблемы, разве нет?). Вопрос не спроста - в одном из драйверов проекта, с которым пришлось разбираться, видел нечто подобное - функция обработчика прерывания возвращает результат "обработано или нет".