[Olej 0]

On 8/8/2016 at 11:46 PM, Motion said:

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

1. Python - потому что он более гибкий + "язык быстрой разработки". Скорость разработки приложений на Python в 10 и более раз выше (скорее), чем на C.

2. По RP везде Python - потому что RP это радиолюбительство и самоделкины, с начала до конца...

3. Книги по Linux & C:  Разработка программных проектов в Linux, Сетевое программирование в Linux, Драйверы и модули ядра Linux

[mantech 35]

В 28.08.2019 в 19:15, Arlleex сказал:

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

Подключить-то можете, только что вы там отладите? Там куча всего крутится, причем больше половины того, о чем вы даже не догадываетесь, тут не baremetal, как-то тоже решил сунуться туда... Вообщем там тяжко, одно слово. Походу в таких системах отладка идет другими принципами... Скорей банальным printk() получится отладить лучше... С прерываниями там тоже не все так просто - это как РТОС, только сложнее...

2 часа назад, Olej сказал:

1. Python - потому что он более гибкий + "язык быстрой разработки".

А что там можно "быстро разработать"? Особенно, если дело касается периферии? Не потому-ли все эти самоделкины поголовно используют только связки RPI+Arduino?

Изменено 8 сентября, 2019 пользователем mantech

[Arlleex 131]

1 час назад, mantech сказал:

Подключить-то можете, только что вы там отладите?

Мне элементарно нужно было отладить работу драйвера простого интерфейса. Но, поскольку для меня Linux - темная лошадка, хотел отладить аппаратно.

В моем случае "там куча всего крутится" меня не пугало нисколько - отладить я хотел всего ничего и далеко не в коде самой ОС...

Но то, что там все мудрено: тут, пожалуй, согласен. Я туда залез, вылез и больше не хочу

[aaarrr 63]

32 minutes ago, Arlleex said:

Мне элементарно нужно было отладить работу драйвера простого интерфейса.

Тогда printk, debugfs...

 

33 minutes ago, Arlleex said:

Но то, что там все мудрено: тут, пожалуй, согласен. Я туда залез, вылез и больше не хочу

Ничего сверхестественного, особенно, если в гугле не забанили - наверное, на 90% возникающих поначалу вопросов

ответ лежит в первых строках выдачи.

[mantech 35]

1 час назад, Arlleex сказал:

В моем случае "там куча всего крутится" меня не пугало нисколько - отладить я хотел всего ничего и далеко не в коде самой ОС...

Да меня тоже не пугало, да и сейчас не пугает это дело, но, как вы отладите свой драйвер без кода ОС?? Вы написали драйвер, потом должны пересобрать ядро, это для меня было что-то с чем-то но это наверно потому, что я не придерживаюсь опенсорс философии, потом его загружаете и запускаете, и вот тут и надо отлаживать, только все вместе, когда идет взаимодействие ядра и вашего драйвера... Плюс еще кто-то должен запустить ваш драйвер, хотя можно просто для теста сделать probe. 

Изменено 8 сентября, 2019 пользователем mantech

[Arlleex 131]

10 часов назад, mantech сказал:

Вы написали драйвер, потом должны пересобрать ядро...

Цитата

Плюс еще кто-то должен запустить ваш драйвер, хотя можно просто для теста сделать probe.

Проект почти рабочий, все настроено и готово к употреблению. Но был трудноуловимый глюк драйвера. Запускать драйвер без ОС (в составе одного проекта) не видел смысла; интерес был как раз в том, чтобы наставить аппаратно точек останова в нужных местах, пройтись в обработчиках прерываний по шагам... Linux, как я понял, можно оттяпать по самое не хочу и оставить только самое нужное. Вот такая и крутится на платке. Но я же не преследую цель изучения этой ОС, поэтому хотел как можно проще и быстрее разобраться в проблеме, и только лишь.

 

 

Цитата

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

+1. Возможно, я тупо не хочу с этим разбираться, из без этого хватает проблем порой. Я люблю "скачал-установил-запустил" и заниматься уже непосредственно прикладной задачей. Недавно ставил и настраивал Eclipse с отладчиком OpenOCD - так, в сравнении с установкой Keil или IAR это было зло в программном воплощении.

 

Возможно, для знающих Linux и отладку под него как таковую я несу пургу. Мне так и не удалось прикрутить отладчик к этой плате в связи с тем, что проблему я нашел другим путем. Кстати говоря, если бы я и не запустил этот проект под отладчиком, то создал бы чистый baremetal-проект только с этим драйвером. И отлаживал бы уже так.

 

Интересно, конечно. Если запустить эту ОС под отладчиком, остановить CPU точкой останова... я что, сломаю всю логику ОС? Вроде как, нет. Разве что какие-нибудь сетевые устройства отвалятся по timeout-ам, ну и да фиг с ними

[AlexandrY 3]

33 minutes ago, Arlleex said:

Интересно, конечно. Если запустить эту ОС под отладчиком, остановить CPU точкой останова... я что, сломаю всю логику ОС? Вроде как, нет. Разве что какие-нибудь сетевые устройства отвалятся по timeout-ам, ну и да фиг с ними

Я подключался к линуксу отладчиком из Keil-а, отлично все останавливает и дальше запускает, но адресное пространство не идентифицирется, символьная отладка не работает.
Уже не помню были ли доступны регистры периферии. 
 

[mantech 35]

46 минут назад, Arlleex сказал:

Недавно ставил и настраивал Eclipse с отладчиком OpenOCD - так, в сравнении с установкой Keil или IAR это было зло в программном воплощении.

Так и есть, причем, почти во всем. Особенно командная строка - это что-то, удивляюсь, как гуру там в ней разбираются

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

7 минут назад, AlexandrY сказал:

Я подключался к линуксу отладчиком из Keil-а, отлично все останавливает и дальше запускает, но адресное пространство не идентифицирется, символьная отладка не работает.

Ну так там же виртуальные адреса и блокировки доступа куда не следует...  А регистры, должны быть доступны..

[AlexandrY 3]

10 minutes ago, mantech said:

Ну так там же виртуальные адреса и блокировки доступа куда не следует...  А регистры, должны быть доступны..

Надо же, а я не знал. 
Проблема не в виртуализации, в ядре виртуализации нет. И отладчик ходит мимо MMU. Проблема в отсутствии файлов с совместимой  отладочной информацией. 
А скомпилировать тем же Keil-ом нельзя, поскольку движок построения ядра это государство в государстве. 

[Arlleex 131]

1 час назад, AlexandrY сказал:

Я подключался к линуксу отладчиком из Keil-а, отлично все останавливает и дальше запускает, но адресное пространство не идентифицирется, символьная отладка не работает.
Уже не помню были ли доступны регистры периферии.

Понял, спасибо за инфу.

 

Цитата

А скомпилировать тем же Keil-ом нельзя, поскольку движок построения ядра это государство в государстве

То есть, как я понимаю, даже урезанный Linux для Embedded-систем, это какое-то магическое приложение? Как я понимаю, там сначала запускается загрузчик, он инициализирует железо и разворачивает файловую систему. Мне казалось, все это, в общем итоге, выглядит как одно большущее приложение, также прошиваемое в контроллер... Почему нельзя скомпилить в том же Keil? Чисто спортивный интерес, надеюсь, до прикладного разбирательства с этой ОС у меня никогда дела не дойдет

[AlexandrY 3]

29 minutes ago, Arlleex said:

Почему нельзя скомпилить в том же Keil? Чисто спортивный интерес, надеюсь, до прикладного разбирательства с этой ОС у меня никогда дела не дойдет

Потому что они при сборке генеририруют тулсы, которые генерируют другие тулсы (скрипты), которые генерируют кучу дополнительных исходников.
А исходники в свою очередь полагаются на сложную систему взаимодействия через скрипты линкера GCC. 
Там также применяются особенности файловой системы линукса для символьных ссылок, поскольку в линуксе туча разных файлов с одинаковыми именами. 
Короче, Keil не сможет собрать линукс даже если удасться выхватить окончательный снимок полной структуры исходников, просто потому что файловая Windows не потянет такую структуру.  

[mantech 35]

2 часа назад, Arlleex сказал:

То есть, как я понимаю, даже урезанный Linux для Embedded-систем, это какое-то магическое приложение?

Если это про UcLinux - это совсем не линух в классическом понимании, это скорее более навороченная фриРТОС

А все остальное - это обычное ядро Линукса, в Embedded версии может просто поменьше драйверов туда интегрировано и все, остальное как у нормальной системы. Соотв. и работать с ним нужно как с обычным ядром. По мне, дак printk - это лучший выбор для отладки там...

1 час назад, AlexandrY сказал:

Короче, Keil не сможет собрать линукс даже если удасться выхватить окончательный снимок полной структуры исходников, просто потому что файловая Windows не потянет такую структуру.

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

[sasamy 9]

8 minutes ago, mantech said:

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

дело не в энтузиазме - это просто не нужно. Насчёт опенсорса у вас очень старые понятия - многие корпорации ведут разработку с отрытыми исходниками. IBM планировала вложить в разработку экосистемы Linux для своих процессоров Power 6 млрд долларов - энтузиазмом там давно не пахнет, это бизнес.

[juvf 10]

 

В 09.08.2016 в 01:46, Motion сказал:

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

Ни разу не встречал ни одного упоминания (книги/web) где бы давалось практическое или теоретическое руководство по написанию драйвера для linux (для любого ПК, в том числе и RP) на языке Phyton. Везде СИ. Можно пруфлинк на такие книги, плиз.

В 09.08.2016 в 01:46, Motion сказал:

Взял Raspberry Pi2, запустил на ней Raspberian и решил написать драйвер для управления светодиодом подключенным к GPIO.

Драйвер - это ПО взаимодействия с GPIO на уровне ядра/перефирии(МК/CPU), а управление светодиодом через GPIO - это скорее всего прикладная программа, а не драйвер. Прикладное ПО пишут на чем угодно, питон/с/ява.... а вот драйвер - всё таки си.

 

В 09.08.2016 в 01:46, Motion сказал:

Но по их содержанию понял что работа с GPIO реализована с помощью языка Python.

Wiring PI в помощь

Цитата

WiringPi is a PIN based GPIO access library written in C for the BCM2835, BCM2836 and BCM2837 SoC devices used in all Raspberry Pi.

[_3m 4]

В 09.09.2019 в 10:31, AlexandrY сказал:

Я подключался к линуксу отладчиком из Keil-а, отлично все останавливает и дальше запускает, но адресное пространство не идентифицирется, символьная отладка не работает.
Уже не помню были ли доступны регистры периферии.

В Openocd символьная отладка ядра linux по jtag работает, но при запуске надо сделать пару магических действий вручную (надо поставить аппаратный брекпойнт и потом сказать openocd куда переместилось ядро после старта). Все документировано и работает если повторять по букварям.

В J-link commander похоже нет поддержки mmu и он виртуальные адреса не понимает.