периферийные шины

встраиваемые модели

Модераторы: Olej, vikos

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 24 фев 2019, 21:42

littlegene писал(а): В статье https://habr.com/en/post/123266/
я не нашел (и не понял) четкого разделения того момента, когда именно в Linux нужно писать протокольный драйвер уровня ядра. Те замечания (4 штуки), которые высказаны в адрес spidev, как мне кажется, совсем не критичны для нашего случая... (Но это может только кажется.)
Не могли бы пояснить, разрабатывали ли сами такой драйвер и в чем была его необходимость.
Я не вникал (пока!) в детали этой аргументации, но по многолетнему опыту разработки драйверов Linux в реальных промышленных проектах общие правила могу сформулировать так:
- дрейвер, модуль ядра в Linux нужно садится писать только тогда, когда перепробованы все варианты использования существующих вариантов в user space;
- чаще всего начинают активно писать модули ядра именно от отсутствия большого опыта использования разнообразных API Linux;

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 24 фев 2019, 21:46

littlegene писал(а): 2.2.Хороша ли практика с использованием циклического буфера внешних данных на стороне SPI-Slave (HEAD-пишет новые данные в буфер, TAIL - отдает имеющиеся данные на SPI шину).
По-моему это самый простой и надежный способ организовать "производитель-потребитель"?
Такая практика используется в 9-ти из 10-ти случаев взаимодействий с периферией, и, безусловно, имеет право на рассмотрение в первую очередь. Если в какой-то конкретной ситуации это "не стреляет", то только тогда нужно переходить к рассмотрению других вариантов.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 24 фев 2019, 21:50

littlegene писал(а): Вопрос 3.
Считаете ли вы целесообразным в такой простой схеме обмена использовать доставку какого-либо события (например о наличии все тех же данных на контроллере) - прямиком в Linux.
(по прерываниям на пинах "гребенки" (знаю, что в RaspberryPi это штатная возможность, а на апельсинках - проблемы) или другим доступным интерфейсам)
То есть в этом случае мы имеем гетерогенную среду (с большой долей инерционности Linux), где данная возможность, на мой вкус, более чем вычурная, грозит на больших скоростях пропуском данных и тд и тп.
А как думаете Вы?
Я думаю, как я понял вопрос, если я его понял, что использование каких-либо дополнительных механизмов сверх спецификаций протоколов (любых!) - это дурная практика.
Тем более, что в подавляющем большинстве плат всех производителей гребёнки GPIO + поддерживающий их механизм GPIO Linux появились относительно поздно - на большинстве аппаратных плат - 6-7 лет назад. Это привнесённый, новый механизм, для других целей.

Urry
Интересующийся
Сообщения: 7
Зарегистрирован: 09 мар 2019, 16:02
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Urry » 11 мар 2019, 11:44

Olej писал(а):
littlegene писал(а): Вопрос 3.
Считаете ли вы целесообразным в такой простой схеме обмена использовать доставку какого-либо события (например о наличии все тех же данных на контроллере) - прямиком в Linux.
(по прерываниям на пинах "гребенки" (знаю, что в RaspberryPi это штатная возможность, а на апельсинках - проблемы) или другим доступным интерфейсам)
То есть в этом случае мы имеем гетерогенную среду (с большой долей инерционности Linux), где данная возможность, на мой вкус, более чем вычурная, грозит на больших скоростях пропуском данных и тд и тп.
А как думаете Вы?
Я думаю, как я понял вопрос, если я его понял, что использование каких-либо дополнительных механизмов сверх спецификаций протоколов (любых!) - это дурная практика.
Тем более, что в подавляющем большинстве плат всех производителей гребёнки GPIO + поддерживающий их механизм GPIO Linux появились относительно поздно - на большинстве аппаратных плат - 6-7 лет назад. Это привнесённый, новый механизм, для других целей.
Хотел бы переспросить. Другие цели - это встраиваемая электроника?
По моему мнению, одноплатные компьютеры, а-ля Малинки-Апельсинки (дёшево и сердито), уже довольно плотно используют в автоматизации технологических процессов и ещё чаще во всякой исследовательской аппаратуре именно благодаря "гребёнке".

Раньше требовалось разработать плату с АЦП, микроконтроллером с дополнительным внешним ОЗУ (или ПЛИСиной), который бы обеспечивал обмен данными между устройством и ПК, например по USB.

Сейчас достаточно легко к Малинке-Апельсинке аппаратно "прикрутить" через "гребенку" аналоговую измерительную часть - микросхемы АЦП, ЦАП. Процессор достаточно мощный. Можно делать математическую обработку на борту. Однако, если подключать к одноплатникам микросхемы, нужны и выводы GPIO. Одного интерфейса SPI недостаточно. Думаю, что в этом случае использование выводов GPIO, а тем более прерываний не "вычурность", а просто необходимость.

Жаль, что под Linux возникают проблемы работы с GPIO. Начинающим программистам проще идти по пройденному пути разработки и использовать готовые результаты.
А если для конкретного одноплатного компьютера не написано драйвера, свободного в интернете?..
Скорее всего, именно из-за этого возник к вам вопрос по использованию GPIO выводов.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 11 мар 2019, 17:55

Urry писал(а):
Olej писал(а): Тем более, что в подавляющем большинстве плат всех производителей гребёнки GPIO + поддерживающий их механизм GPIO Linux появились относительно поздно - на большинстве аппаратных плат - 6-7 лет назад. Это привнесённый, новый механизм, для других целей.
Хотел бы переспросить. Другие цели - это встраиваемая электроника?
Можно и так сказать ... только дело не в названиях, а в том, что под ними понимать, договариваться.
Глядя на то, для каких целей народ, в большинстве, пользует GPIO - это, в основном, отдельные, бинарные исполнительные линии, например: включить реле...
Вообще то, GPIO и в Linux, и в одноплатных SBC, это, как мне кажется - эксплуатация оказавшихся успешными идей Arduino и перенос их в универсальный компьютер - отдельные дискретные сигнальные линии. Почему я думаю, что именно "в следствии" - потому что и по времени: до бурного всплеска Arduino в универсальных компьютерах не было GPIO ни в железе, ни в Linux.
Urry писал(а): По моему мнению, одноплатные компьютеры, а-ля Малинки-Апельсинки (дёшево и сердито), уже довольно плотно используют в автоматизации технологических процессов и ещё чаще во всякой исследовательской аппаратуре именно благодаря "гребёнке".
Вообще то говоря, в "автоматизации технологических процессов", в АСУТП то-есть, там где это серьёзно, используют до сих пор программируемые логические контроллеры, PLC (Siemens, Schneider Electric etc.) ... т.е. может даже и универсальные компьютерные архитектуры в этом качестве, но запущенные по принципу исключительно программного опроса, циклического пулинга ... ну и уж никак аппаратно (пока) SBC, все эти Pi :lol: .
И в этом смысле для целей a'la АСУТП ближе Arduino и его идеи, чем SBC.
Urry писал(а): Раньше требовалось разработать плату с АЦП, микроконтроллером с дополнительным внешним ОЗУ (или ПЛИСиной), который бы обеспечивал обмен данными между устройством и ПК, например по USB.

Сейчас достаточно легко к Малинке-Апельсинке аппаратно "прикрутить" через "гребенку" аналоговую измерительную часть - микросхемы АЦП, ЦАП. Процессор достаточно мощный. Можно делать математическую обработку на борту. Однако, если подключать к одноплатникам микросхемы, нужны и выводы GPIO. Одного интерфейса SPI недостаточно. Думаю, что в этом случае использование выводов GPIO, а тем более прерываний не "вычурность", а просто необходимость.
Всё это так.
Только более-менее "понятные" устройства, типовые (АЦП, ЦАП, дисплеи, индикаторы и др.) - лучше и проще (!) подключать через стандартизованные шины (CPI, I2C) и в большинстве случаев (глядя кто и как) так и делают. Это то же самое, что периферийные устройства всегда считалось лучше подключать черех стандартизованные интерфейсы: RS-232, RS-485, Modbus, CAN, USB ... - выбирай не хочу, чем городить к ним собственный TTL или не TTL интерфейс с собственными протоколами.
А GPIO - это из области отдельных дискретных входов-выходов.
Тем более, что для объединения линий GPIO в группы (для создания цифрового выхода или входа) у вас то там и не так много свободных, потому что большинство из них стандартно уже задействовано под какие-то цели и устройства.
Urry писал(а): Жаль, что под Linux возникают проблемы работы с GPIO. Начинающим программистам проще идти по пройденному пути разработки и использовать готовые результаты.
А если для конкретного одноплатного компьютера не написано драйвера, свободного в интернете?..
Скорее всего, именно из-за этого возник к вам вопрос по использованию GPIO выводов.
А почему вы решили, что с программным использованием GPIO есть какие-то трудности? ... даже у самых начинающих!
В Linux как-раз существует а). цельная, б). простая, в). исчерпывающая поддержка GPIO на уровне ядра. Тут вот рядом тема даже была отдельно: GPIO в Linux. И там не нужно ничего дописывать, это нужно просто брать и использовать.
Одних только конфигурационных параметров ядра Linux относительно деталей функционирования подсистемы GPIO:

Код: Выделить всё

[olej@xenix ~]$ cat /boot/config-`uname -r` | grep GPIO | wc -l
80
Во! Аж 80 штук! :lol:
Но и этого ещё мало ... как-раз в сообществах Rapsberry/Orange появилась идея и проекты совсем уж "на коленке" - поддержка GPIO в пространстве пользователя, проекты WiringPi / WiringOP, см. GPIO.

Urry
Интересующийся
Сообщения: 7
Зарегистрирован: 09 мар 2019, 16:02
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Urry » 12 мар 2019, 15:47

Спасибо за ответы.
Хотел только отметить следующее:
1. АЦП - именно микросхемы, а не законченные устройства со стандартными интерфейсами. Скорость передачи данных были до 3 МБайт/сек. Для законченных устройств, наверное, уже потребуется USB.
Если микросхему АЦП "совокупить" с процессором, то достаточно и SPI.
2. Сигналы квитирования микросхем АЦП можно подвести через GPIO, используя встроенные в процессоре таймеры (DMA). Это позволяет также минимизировать аналоговую измерительную часть.
3. Я не программист linux, но похоже нужно немного самообразовываться в этом направлении. Вашу информацию по GPIO передам по назначению.

Ещё раз спасибо.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 12 мар 2019, 20:07

Urry писал(а): 2. Сигналы квитирования микросхем АЦП можно подвести через GPIO, используя встроенные в процессоре таймеры (DMA). Это позволяет также минимизировать аналоговую измерительную часть.
Да, сигнал синхронизации через GPIO для считывания данных с АЦП, или синхронизации любого внешнего устройства, или инициирования какого-то события на периферии - это как-раз хорошие примеры того где и как используется подсистема GPIO Linux.

Но тут нужно всегда иметь в виду одно обстоятельство, которое всегда упускают из виду разработчики аппаратных вещей, привыкшие к hard-реализациям:
- Linux - многозадачная/многопоточная система, в которой постоянно выполняются, конкурируя между собой, достаточно много параллельных ветвей (потоков) ... даже в то время, когда вам кажется что система простаивает и ничего вообще не делает;
- и многие из этих потоков имеют достаточно высокий приоритет, с которым они всегда вытеснят, прервут и отложат выполнение любого вашего пользовательского приложения;
- в результате ваши синхроимпульсы (как и всякие и любые действия в системе) будут "плавать" по временной шкале, то что аппаратчики часто называют джитер: если вы заказываете повторяющееся событие с периодом, скажем, в 1 мс, то реально интервалы будут носить случайное распределение, некоторые (редкие) отсчёты будут "затягиваться" на 2 мс, ещё некоторые (ещё более редкие) - на 5 мс., а некоторые (особо редкие, 1:1000000) - на 10 мс.

Эта особенность приводит к тому, что это требует иногда просто пересмотреть архитектуру проекта, а не бороться упорно за жёсткую детерминированность во времени событий.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 12 мар 2019, 20:20

Olej писал(а): Но тут нужно всегда иметь в виду одно обстоятельство, которое всегда упускают из виду разработчики аппаратных вещей, привыкшие к hard-реализациям:
- Linux - многозадачная/многопоточная система, в которой постоянно выполняются, конкурируя между собой, достаточно много параллельных ветвей (потоков) ... даже в то время, когда вам кажется что система простаивает и ничего вообще не делает;
Вот в одной, наугад выбранной, инсталляции Linux - посмотрите:

Код: Выделить всё

olej@ACER:~/2019_WORK/own.BOOKs/Kernel$ ps -ALf | grep ^root | egrep '\['
root         2     0     2  0    1 фев27 ?     00:00:00 [kthreadd]
root         3     2     3  0    1 фев27 ?     00:00:00 [rcu_gp]
root         4     2     4  0    1 фев27 ?     00:00:00 [rcu_par_gp]
root         6     2     6  0    1 фев27 ?     00:00:00 [kworker/0:0H-kblockd]
root         8     2     8  0    1 фев27 ?     00:00:00 [mm_percpu_wq]
root         9     2     9  0    1 фев27 ?     00:00:05 [ksoftirqd/0]
root        10     2    10  0    1 фев27 ?     00:04:56 [rcu_sched]
root        11     2    11  0    1 фев27 ?     00:00:00 [rcu_bh]
root        12     2    12  0    1 фев27 ?     00:00:02 [migration/0]
root        14     2    14  0    1 фев27 ?     00:00:00 [cpuhp/0]
root        15     2    15  0    1 фев27 ?     00:00:00 [cpuhp/1]
root        16     2    16  0    1 фев27 ?     00:00:02 [migration/1]
root        17     2    17  0    1 фев27 ?     00:00:04 [ksoftirqd/1]
root        19     2    19  0    1 фев27 ?     00:00:00 [kworker/1:0H-kblockd]
root        20     2    20  0    1 фев27 ?     00:00:00 [kdevtmpfs]
root        21     2    21  0    1 фев27 ?     00:00:00 [netns]
root        22     2    22  0    1 фев27 ?     00:00:00 [kauditd]
root        23     2    23  0    1 фев27 ?     00:00:01 [khungtaskd]
root        24     2    24  0    1 фев27 ?     00:00:00 [oom_reaper]
root        25     2    25  0    1 фев27 ?     00:00:00 [writeback]
root        26     2    26  0    1 фев27 ?     00:00:00 [kcompactd0]
root        27     2    27  0    1 фев27 ?     00:00:00 [ksmd]
root        28     2    28  0    1 фев27 ?     00:01:46 [khugepaged]
root        29     2    29  0    1 фев27 ?     00:00:00 [crypto]
root        30     2    30  0    1 фев27 ?     00:00:00 [kintegrityd]
root        31     2    31  0    1 фев27 ?     00:00:00 [kblockd]
root        32     2    32  0    1 фев27 ?     00:00:00 [edac-poller]
root        34     2    34  0    1 фев27 ?     00:00:00 [devfreq_wq]
root        35     2    35  0    1 фев27 ?     00:00:00 [watchdogd]
root        37     2    37  0    1 фев27 ?     00:00:07 [kswapd0]
root        55     2    55  0    1 фев27 ?     00:00:00 [kthrotld]
root        56     2    56  0    1 фев27 ?     00:00:00 [irq/24-pciehp]
root        57     2    57  0    1 фев27 ?     00:00:00 [ipv6_addrconf]
root       116     2   116  0    1 фев27 ?     00:00:00 [acpi_thermal_pm]
root       119     2   119  0    1 фев27 ?     00:00:00 [ata_sff]
root       120     2   120  0    1 фев27 ?     00:00:00 [scsi_eh_0]
root       121     2   121  0    1 фев27 ?     00:00:00 [scsi_tmf_0]
root       122     2   122  0    1 фев27 ?     00:00:00 [scsi_eh_1]
root       123     2   123  0    1 фев27 ?     00:00:00 [scsi_tmf_1]
root       124     2   124  0    1 фев27 ?     00:00:00 [scsi_eh_2]
root       125     2   125  0    1 фев27 ?     00:00:00 [scsi_tmf_2]
root       126     2   126  0    1 фев27 ?     00:00:00 [scsi_eh_3]
root       127     2   127  0    1 фев27 ?     00:00:00 [scsi_tmf_3]
root       132     2   132  0    1 фев27 ?     00:00:09 [kworker/1:1H-kblockd]
root       133     2   133  0    1 фев27 ?     00:00:08 [kworker/0:1H-kblockd]
root       170     2   170  0    1 фев27 ?     00:00:00 [kworker/u5:0]
root       171     2   171  0    1 фев27 ?     00:00:02 [jbd2/sda2-8]
root       172     2   172  0    1 фев27 ?     00:00:00 [ext4-rsv-conver]
root       292     2   292  0    1 фев27 ?     00:03:45 [i915/signal:0]
root       295     2   295  0    1 фев27 ?     00:00:00 [i915/signal:1]
root       296     2   296  0    1 фев27 ?     00:00:00 [i915/signal:2]
root       297     2   297  0    1 фев27 ?     00:00:00 [i915/signal:6]
root       366     2   366  0    1 фев27 ?     00:00:42 [jbd2/sda4-8]
root       367     2   367  0    1 фев27 ?     00:00:00 [ext4-rsv-conver]
root     13964     2 13964  0    1 мар04 ?     00:00:00 [irq/30-mei_me]
root     19893     2 19893  0    1 18:24 ?        00:00:03 [kworker/0:2-events]
root     20045     2 20045  0    1 18:34 ?        00:00:01 [kworker/u4:3-events_unbound]
root     20527     2 20527  0    1 19:04 ?        00:00:00 [kworker/u4:0+events_unbound]
root     20545     2 20545  0    1 19:06 ?        00:00:00 [kworker/1:2-events]
root     20565     2 20565  0    1 19:07 ?        00:00:00 [kworker/0:1-events_power_efficient]
root     20839     2 20839  0    1 19:12 ?        00:00:00 [kworker/1:0-events]
root     20858     2 20858  0    1 19:13 ?        00:00:00 [kworker/u4:1-events_unbound]
root     20892     2 20892  0    1 06:54 ?        00:00:00 [xfsalloc]
root     20893     2 20893  0    1 06:54 ?        00:00:00 [xfs_mru_cache]
root     20897     2 20897  0    1 06:54 ?        00:00:00 [jfsIO]
root     20898     2 20898  0    1 06:54 ?        00:00:00 [jfsCommit]
root     20899     2 20899  0    1 06:54 ?        00:00:00 [jfsCommit]
root     20900     2 20900  0    1 06:54 ?        00:00:00 [jfsSync]
root     20903     2 20903  0    1 19:14 ?        00:00:00 [kworker/0:0-events_power_efficient]
Это всё внутренние потоки ядра, даже без учёта выполняющихся приложений, серверов, сервисов...
Или по их числу:

Код: Выделить всё

olej@ACER:~/2019_WORK/own.BOOKs/Kernel$ ps -ALf | grep ^root | egrep '\[' | wc -l
71
Вот сколько штук ;-) . И они все там шевелятся не синхронизировано, случайным образом...

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение Olej » 12 мар 2019, 20:44

Olej писал(а): - в результате ваши синхроимпульсы (как и всякие и любые действия в системе) будут "плавать" по временной шкале, то что аппаратчики часто называют джитер: если вы заказываете повторяющееся событие с периодом, скажем, в 1 мс, то реально интервалы будут носить случайное распределение, некоторые (редкие) отсчёты будут "затягиваться" на 2 мс, ещё некоторые (ещё более редкие) - на 5 мс., а некоторые (особо редкие, 1:1000000) - на 10 мс.

Эта особенность приводит к тому, что это требует иногда просто пересмотреть архитектуру проекта, а не бороться упорно за жёсткую детерминированность во времени событий.
Я тут совсем недавно (все предыдущие весну и лето, 2018) работал с крупным производством, у которых целая лаборатория занята в разработках промышленных роботов. Главным образом они аппаратчики (не софтверы) и разработчики на микроконтроллерах (AVR и т.п.).

Так вот они сосредоточились, главным образом и упорно, на привязке событий (обменов управляющих данных) к сетке 1мс. + снижении всеми силами джитера, отложенных событий за 2-3 мс. И влезли с этой проблематикой в такие экзотические проекты как hard realtime Linux, проект Xenomai... Очень интересная работа была, можете посмотреть: Xenomai и real-time Linux и Raspberry Pi: hard realtime Linux/Xenomai.

P.S. В конечном итоге, они отказались от использования таких сложных вещей как Xenomai, и перешли к использованию синхросерии 3 мс. Но сама по себе работа сильно интересная, и публикации и картинки относительно Xenomai про джитер - очень показательные (все ссылки есть в теме).

littlegene
Интересующийся
Сообщения: 5
Зарегистрирован: 24 ноя 2012, 20:49
Контактная информация:

Re: периферийные шины

Непрочитанное сообщение littlegene » 12 мар 2019, 23:39

olej, спасибо за информацию и советы.

Просто в копилку данной ветки сети: видео о том, в чем проблематика работы SPI в режиме slave на Linux.
https://youtu.be/tCa_ydVwKhM
Там хотя и упоминается SPIDEV при обзоре различных подходов, "эмулирующих" slave (или, даже, готовых slave-драйверов в mainline для конкретных 2-3 spi-модулей), мне лично совсем не понятно: как и чем в этом случая конфигурировались бы (при всем готовом в среде Linux) spi-модули на популярных SBC... По-моему, не скоро в DT будет такая ветка)

В общем, тема конечно интересная!

Ответить

Вернуться в «Одноплатные компьютеры»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 5 гостей