Jump to content

    

Embedded Linux

Добрый день.

 

Более простые 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) будет управлять светодиодом.

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Устал копаться в теории, захотелось что-то сделать на практике. Взял 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 и пишите туда нужное значение

Share this post


Link to post
Share on other sites
Будут вопросы -- спрашивайте.

 

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

 

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

 

 

 

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

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites
У меня вопрос - имел ли кто опыт работы с buildroot?

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now