LINUX.ORG.RU

Как сделать в Linux'е предсказуемые тайминги протокола для GPIO+SPI?

 , ,


2

2

Добрый день! Я пишу под Linux демона для «базы», который собирает данные с радиодатчиков LoRa. Хочется сделать двухсторонний обмен по подобию устройств LoRaWAN класс А, т.е. датчик посылает пакет и оставляет включённым на небольшое время приёмник. В это окно демон на «базе» должен успеть ответить датчику.

Модуль LoRa подключен к «базе» по SPI, плюс у него есть программируемые на события GPIO ноги, в.ч. флаг приёма пакета. Я сейчас умею общаться с железом через /dev/spidevX.X и экспорт ног SoC'а в /sys/class/gpio. События на GPIO ловлю через poll(). И вот у меня есть сомнения, что таким образом я за предсказуемое время успею послать ответный пакет с «базы». И как это «предсказуемое время» определить? Тут в голову лезут слова типа RTOS, но может есть способ проще для такой задачи?

Чукча вообще не писатель, делаю систему для себя и пытаюсь разобраться, так что если фигню написал, сильно не ругайте :)

SPI ... демон

вы плодитесь как мухи :)

Драйвер или демон?

потом когда становится понятно что так не работает

в голову лезут слова типа RTOS

Ваша задача решается написанием драйвера

Модуль LoRa подключен к «базе» по SPI, плюс у него есть программируемые на события GPIO ноги, в.ч. флаг приёма пакета. Я сейчас умею общаться с железом через /dev/spidevX.X и экспорт ног SoC'а в /sys/class/gpio. События на GPIO ловлю через poll().

события от GPIO ловить через прерывания - у SoC любая нога GPIO может быть источником запроса на прерывание от внешнего устройства

anonymous ()
Ответ на: комментарий от tailgunner

«Окно» для ожидания ответа датчиком можно сделать «какое угодно». Это же самоделка, мне не надо к какому-то стандарту привязываться. Но, допустим, «база» отключилась, тогда все датчики начинают усиленно есть батарейки ожидая ответа максимально долго. Это не хорошо. Я вот и подумал, может есть, «исходя из имеющейся практики», какая-то типичная величина максимальной задержки переключения на задачу. С учётом, что систему никто специально жёстко грузить не будет. Или это всё настолько не предсказуемо, что нормальные люди так не делают? И идти мне сразу изучать сборку ядра с RT опциями и как этим всем пользоваться?

DmitryVS ()
Ответ на: комментарий от anonymous

вы плодитесь как мухи :) Драйвер или демон? потом когда становится понятно что так не работает в голову лезут слова типа RTOS Ваша задача решается написанием драйвера

Да, я читал эту ветку. В принципе, с написанием драйверов я знаком так же как и с RT опциями ядра, т.е. никак :) Всё равно надо садиться и въезжать. Но у меня есть вопрос по драйверу. Хорошо, он быстро отработает входящий пакет по прерыванию, но что делать с задержкой исходящего? Логика всё равно вся находится в юзер спейс, если я правильно пользуюсь термином, т.е. неконтролируемую задержку ответа никто не отменял. Не пихать же всю логику демона в драйвер?

DmitryVS ()
Ответ на: комментарий от tailgunner

Если у тебя нет требований ко времени задержки, то и ожидание можно делать как угодно.

Требование - энергоэффективность. Я вариант жора батареек в датчиках при молчащей «базе» привёл.

DmitryVS ()
Ответ на: комментарий от DmitryVS

Не пихать же всю логику демона в драйвер?

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

anonymous ()
Ответ на: комментарий от DmitryVS

Я вариант жора батареек в датчиках при молчащей «базе» привёл.

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

anonymous ()
Ответ на: комментарий от anonymous

насколько понимаю датчик передает измеренные параметры - что ему может сказать в ответ «база» ?

Как минимум, что я хотел уже сейчас сделать в ответах, запросы на перешивку в EEPROM настроек. Для этого придётся в драйвере создавать таблицы, чтобы он знал заранее, какому датчику что отвечать. А если я добавлю новый тип пакета или датчика, то надо драйвер переставлять. По-моему, не очень кузяво... хотя могу и ошибаться.

DmitryVS ()
Ответ на: комментарий от DmitryVS

Если у тебя нет требований ко времени задержки, то и ожидание можно делать как угодно.

Требование - энергоэффективность.

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

tailgunner ★★★★★ ()

Пиши свой модуль ядра. Возможно, получится на прерываниях EXTI реализовать.

Но надежней таки сделать отдельного посредника на STM32. F030 тебе за глаза!

anonymous ()
Ответ на: комментарий от DmitryVS

Как минимум, что я хотел уже сейчас сделать в ответах, запросы на перешивку в EEPROM настроек. Для этого придётся в драйвере создавать таблицы, чтобы он знал заранее, какому датчику что отвечать

сделать обычный char device с read и write - остальное в юзерспейс, в юзерспейс поллить готовность данных для чтения. Что-то мне подсказывает что существует возможность передать в датчик типа NOP чтобы он оставался активным пока юзерспейс не прочитал данные и не ответил.

anonymous ()
Ответ на: комментарий от anonymous

сделать обычный char device с read и write

кстати можно вообще как последовательный порт сделать драйвер - очень похоже на rs485 в режиме полудуплекса.

anonymous ()

Может проще наколхозить avr-ку или stm32, передавать данные по uart или по usb через виртуальный сом-порт, правда тут нужна уже Stm32f103 за 100 руб с алишки.

AUX ★★★ ()
Ответ на: комментарий от I-Love-Microsoft

А то ТС режим SPI на GPIO замутить, и еще на какие-то тайминги надеется...

вы невнимательно читаете - он поллит GPIO к которому подключен сигнал готовности данных от приемопередатчика, обмен данными через аппаратный SPI

тут нужна уже Stm32f103
так и надо делать

и этот абсолюно ненужный прыщеконтроллер должен будет знать всех существующих датчика и их протоколы

Для этого придётся в драйвере создавать таблицы, чтобы он знал заранее, какому датчику что отвечать

anonymous ()
Ответ на: комментарий от AUX

Очередной мамкин инноватор

по сути что-то скажешь - зачем в данном случае промежуточный микроконтроллер ? кроме того что ты знаешь про существование stm32 и видимо уже поморгал светодиодиками

Каникулы начались?

да, можешь начинать бухать

anonymous ()
Ответ на: комментарий от anonymous

Интересно, мамкин инноватор, как ты запилишь какую-нибудь железяку без микроконтроллера? Скажем, нужно тебе опрашивать датчики по I2C, SPI и UART одновременно; работать с CAN-шиной и USB одновременно; опрашивать с десяток концевиков; управлять пятью-семью шаговиками и всякими ТЭНами и т.п. фигней (которой ШИМ нужен)? Нет таких одноплатников, которые бы это умели! Да и тупо как только тебе нужен рилтайм, одноплатники с линуксом сливаются, т.к. нельзя им доверить такие задачи!!!

anonymous ()
Ответ на: комментарий от anonymous

Скажем, нужно тебе опрашивать датчики по I2C, SPI и UART одновременно; работать с CAN-шиной и USB одновременно; опрашивать с десяток концевиков; управлять пятью-семью шаговиками и всякими Нет таких одноплатников

стандартный набор периферии рядового SoC с ядром ARM и MMU

Да и тупо как только тебе нужен рилтайм

накатываешь PREEMT_RT, вопрос - зачем он нужен в данном случае ?

одноплатники с линуксом сливаются, т.к. нельзя им доверить такие задачи!!!

тебе я даже кобылой управлять не доверю

anonymous ()
Ответ на: комментарий от anonymous

SoC с ядром ARM и MMU
тебе я даже кобылой управлять не доверю

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

Ну, что сказать?..

anonymous ()

Ну вот смотри: если у тебя драйвер GPIO получает события от ног через прерывания то это подразумевает задержку порядка 50 мкс от события на ноге до запуска обработчика прерывания являющегося частью драйвера GPIO. Далее драйвер сообщает шедуллеру что конкретное приложение получило событие и должно быть поставлено в очередь для исполнения для обработки этого события. А дальше все зависит от шедуллера. Я бы оценил задержку от драйвера до приложения в 10 мс. Дальше у тебя есть база. Скорее всего обращение к ней занимает порядка 50 мс. А дальше путь ответа назад.

Если связатся с фишками относящимися к риал-тайму то эти времянки можно посадить гдето на порядок. Но в любом случае не стоит надеятся что вся эта цепочка будет короче 10 мс.

cvv ★★★★★ ()
Последнее исправление: cvv (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

для меня микроконтроллеры потеряли актуальность лет 10 назад

anonymous ()
Ответ на: комментарий от anonymous

Надо тебя из своего кармана оплачивать безделушки, которые ты делаешь. Сразу по-другому бы завыл, когда вместо 1000 рублей пришлось бы 100000 отдать!

anonymous ()
Ответ на: комментарий от cvv

Если связатся с фишками относящимися к риал-тайму то эти времянки можно посадить гдето на порядок. Но в любом случае не стоит надеятся что вся эта цепочка будет короче 10 мс.

да о чем вы, какие милисекунды ?

https://habr.com/company/efo/blog/316954/

Класс А (обязательный для всех)

Устройства класса А после каждой передачи открывают два коротких временных окна на прием (обозначаются как RX1 и RX2) Интервалы от конца передачи до открытия первого и второго временных окон могут конфигурироваться, но должны быть одинаковыми для всех устройств в данной сети (RECEIVE_DELAY1, RECEIVE_DELAY2). Для европейского диапазона 868 МГц рекомендованное значение RECEIVE_DELAY1 составляет 1 секунду. Значение RECEIVE_DELAY2 должно равняться (RECEIVE_DELAY1 + 1) секунда.

anonymous ()
Ответ на: комментарий от AUX

И тут стало ясно, что чел поехавший!

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

anonymous ()
Ответ на: комментарий от anonymous

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

Нормальные люди используют вещи по назначению, если нужен реалтайм и у тебя в проекте энкодеры, датчики, то используют МК, если нужна графика то берут одноплатник с линуксом, а все что связано с ТП и реалтайм выносят на МК.

AUX ★★★ ()
Ответ на: комментарий от AUX

Нормальные люди используют вещи по назначению

золотые слова!

если нужен реалтайм и у тебя в проекте энкодеры, датчики, то используют МК

ну и сери в теме про реалтайм, сюда ты чего приполз со своими микроконтроллерами ?

anonymous ()
Ответ на: комментарий от cvv

Я пытался обьяснить другой аспект взаимодействия.

если говорить про PREEMT_RT, то ваше утверждение ошибочно

Если связатся с фишками относящимися к риал-тайму то эти времянки можно посадить гдето на порядок.

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

для ядра тем временем уже есть экспериментальная ветка LoRaWAN socket

https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/log/?...

anonymous ()
Ответ на: комментарий от I-Love-Microsoft

вот да. spi на gpio - самый медленный вариант. через юзерспейс и дженерик драйвер - тем более. но я думаю, что и «риалтайм» тут не тот, где наносекунды кто-то считает. а за пару миллисеков база успеет ответить, если там клиентов не миллионы штук вокруг.

Iron_Bug ★★★★ ()