Сообщения pi

Спасибо за помощь, все работает. Как оно все начало работать сам не знаю, просто неожиданно заработало.

@sv-lary#6827 Не пингуется всё кроме компютера подключенного через кабель. В PuTTY через WiFi. Я и сам понимаю, что такой ситуации быть не может, но так уж вышло.

@VBDUnit#6829 я не видел драйверов, которые это смогут с таким количеством диодов сделать на нормальной скорости.

Я в этой области не разбираюсь совсем, но просто пошёл на гуглу и вбил там в строке поиска ESP32 LED. И очень много ссылок выскочило. Например:

Board with 25 RGB LEDs is offered with ESP32-C3 or ESP32-Pico-D4
https://www.cnx-software.com/2022/01/07/board-with-25-rgb-leds-is-offered-with-esp32-c3-or-esp32-pico-d4/

На алибабе этот модуль стоит 1200 рублей.

@VBDUnit#6829 это довольно дорого

Не знаю, но это всяко сопоставимо с ценой самой ленты.

@VBDUnit#6829 получилось притащить DMA для малины

Драйвера конкретно для малины я не писал. Но, насколько мне известно, поддержка DMA там есть и так. Если же Вы планируете использовать DMA в своём драйвере LED, то может быть Вам окажется полезным перевод, который я когда-то делал для себя, в процессе разработки своих драйверов. Сайт

http://larionov.mytomsk.ru/

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

Моё мнение такое: нужно использовать аппаратные драйверы LED. Если готовых таких не найти, то надо обратиться к железячникам, которые работают с PLIS-ками. Они за три дня сделают такой драйвер. Им это будет гораздо проще, чем Вам писать драйвер с DMA...

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

Смысл такой: управление каждой лентой осуществляется через 1 пин, переключаемый с интервалом 400 нс. Если я подключу к 20 пинам 20 лент, и затем через DMA буду выводить с интервалом 400 нс на эти пины битовые маски, меняя или не меняя состояния тех самых 20 пинов за раз, то я буду параллельно управлять 20 лентами. Битовые маски для параллельного управления всеми лентами сразу в реалтайме генерируются на компе и отправляются по UDP по проводному соединению в малину, где она должна сделать, условно говоря, вот это:

while (ptr < end)
{
*dmaRegister = *ptr++;
wait400ns();
}

Всё. Больше от неё ничего не требуется. Получай данные, отправляй в пины. Но каждый раз жди ровно 400 нс, без исключений. Контроллеры умеют в точные тайминги, но с таким потоком данных не справляются, а малина наоборот - ей раз-плюнуть обработать данные, но с таймингами адская дичь. Выдерживать интервал в 400 нс, оказываются, очень сложно.

У меня уже вроде получилось добиться одинаковых интервалов, но проблема в том, что они 580 нс, а надо 400. По сути, всё из-за того, что gpio_set_value работает медленно, и мне нужно либо что-то быстрее, либо вообще DMA. Вот здесь вроде как у человека получилось притащить DMA для малины в kernel, но ссылки там битые https://forums.raspberrypi.com/viewtopic.php?t=235501

И вот здесь, по идее, мне не поможет даже ОС реального времени, т.к. проблема теперь не в ровных таймингах, а в уменьшении их длительности, для чего нужно поменять подход к работе с GPIO.

@VBDUnit#6821 Вы разбираетесь в теме намного лучше меня

Не думаю, что я разбираюсь в управлении светодиодными лентами лучше Вас. Просто мне не верится, что для решения этой задачи нужны какие-то титанические усилия.

@VBDUnit#6821 и не задержало мой код даже на 50 нс

Может я и не прав, но вроде же есть какие-то устройства (которые так и называют - LED-драйверы), специально предназначенные для таких целей.

Я понял так, что Вы на GPIO ноге пытаетсь сформировать сигнал, управляющий работой нескольких LED-лент. Но ведь это не задача драйвера! Драйвер (программный, из ОС) должен записать в аппаратный драйвер какую-то битовую маску, которая задаёт конфигурацию светящихся огоньков, установить скорость движения этой маски через матрицу LED и направление движения. Всё остальное должна делать аппаратура!

Драйвер ос не должен работать с электрическими сигналами. Он должен работать с логикой.

> @chitsu#6824 Пинганул компьютер подключеный по проводу, с ним все нормально.

Ну а соединение в PuTTY как сделано - чрез WiFi, или через провод?

На одном компе (например - малинке) может быть несколько сетевых карточек. Некотрые могут быть проводные, а некоторые - через WiFi или ещё как. Но они все различаются по их IP.

Проанализируйте, какие IP у Вас выходят на связь. а какие - нет. И после этого можно будет разбираться.

А то вы говорите, что пингуете, но связи нет. Простите, это - оксюморон...

@chitsu#6823 У меня открывается сеанс в PuTTY

С каким IP ? Именно с тем, с которым Вы желаете работать? И в окошке PuTTY Вы можете выполнить любую команду (ну хотя бы ls) и увидите ответ?

Тогда я не понимаю - а что Вам ещё нужно?! Ведь связь - есть!

@chitsu#6822 В ответ выдало 1

Это означает, что на компе, на котором Вы выполнили эту команду, есть некая программа, котрая слушает 80 порт. Скорее всего - это какой-то HTTP сервер. Т.е. это говорит о том, что сервер (программа!) живой.

Но это ничего не говорит о линии связи связи - работает она, или нет.

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

@sv-lary#6816 Связь у меня реализована через WiFi. У меня открывается сеанс в PuTTY и WinSCP. Насколько знаю, PuTTY является клиентом для SSH связи

.

@mojo#6815 В ответ выдало 1

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

По поводу ndelay. Вот меандр, выдаваемый без ndelay:

интервал 680 нс получается, по-видимому, потому, что я не использую DMA - собственно, сейчас прикручиванием оного я и занимаюсь. И вот к этому коду после включение, и после и выключения пина я добавляю по ndelay(400). По логике интервал должен стать равными примерно 1 мкс. Но на практике происходит так:

Может я чего-то и не понимаю, но она накинула целую микросекунду, и это совсем не то, что нужно. Окей, попробуем ndelay(1):

Всё еще печаль. Видимо сам вызов ndelay занимает неприемлемо большой интервал времени.

Все эти выделения памяти с отключением кеширования и отключение прерываний я использую лишь для того, чтобы сделать поведение этого кода максимально детерминированным. Чтобы в процессе переключения пина ничего не влезло и не задержало мой код даже на 50 нс. Если есть другие способы достичь этого, буду рад узнать. ndelay, к сожалению, не работает.

@sv-lary#6819 С компа идут данные, как выставить цвета на ленте. Мне нужно передавать 30 раз в секунду цвета для 144 светодиодов, по 24 бита на каждый. Бит передается тремя подряд идущими уровнями: единица, затем значение бита, затем ноль. Каждый из этих уровней должен длиться 400 нс. Между светодиодами нужно выдерживать паузу 50 мкс. Это не слишком большой объем данных, но лента очень чувствительна к таймингу, и сбывается при малейшей отклонении.

При этом лент больше 20. Из за этого не получается использовать аппаратный PWM, по этой же причине я использую малину, а не контроллер - если контроллер и переварит 2,5 мбит/с, то задержка будет все равно значительной.

Поэтому я влез в драйверы.

@VBDUnit#6818 А как мне тогда добиться точного тайминга?

Я же уже говорил - для этого есть семейство ф-ций ядра delay() Честно говоря, я вообще не понимаю, о чём речь. Вы хотите убедить м еня в том, что для передачи 24 бит сколько-то там раз в секунду, нужно всё ядро подвешивать на spin_lock() ?! Я в это не могу поверить.

Скажите, в Вашем драйвере вообще есть функция обработки прерываний? Вы знаете, как управлять вводом/выводом по прерываниям?

@sv-lary#6812 Далее, по поводу блокировки прерываний с помощью spin_lock_irqsave() Эта функция может использоваться только в очень ограниченные периоды времени. Использовать её во время выполнения операций ввода/вывода довольно сомнительно. тем более, если данные передаются из/в userspace. А если нужной страницы из userspace в этот момент нет в оперативной памяти? Я настоятельно рекомендую убрать эти вызовы.

А как мне тогда добиться точного тайминга? По идее каждые 24 переданных бита я делаю паузу в 50 мкс, и к ней уже требования пониже. Может, стоит тормозить прерывания только на передаче 24 бит и потом на время паузы отпускать? А чтобы нужная страница памяти подгрузилась перед блокировкой 1 раз вхолостую прочитать нужные 24 состояния, потом блокировка, передача, разблокировка и пауза в 50 мкс. Так можно?

@sv-lary#6812 Нюанс в том, что малина кроме получения пакетов по UDP и управления лентами ничего делать не будет, поэтому я и отношусь так спокойно к торможению ядра.

@mojo#6814 Да, походу к этому все идёт. Вопрос - кому нибудь удавалось накатить этот патч на Raspbian на малине 4B? Я слышал с этим патчем постоянно проблемы и много гемора

А причём тут веб-сервер ?!!!!

Сообщение

@chitsu#6813 Destination Host Unreachable

на русском звучащее как:

@chitsu#6813 Заданный узел недоступен.

Означает отсутствие физической связи между компом источником пинга и компом назначения.

Если ваша домашняя сеть построена на обычной витой паре и кабель воткнут в разъём на малинке, то это сообщение (скорее всего) говорит о том, что где-то провод выпал из разъёма, Ваша киса перегрызла кабель или ещё что-то в таком же духе.

Если вся связь в домашней сети идёт через WiFi, то это (скорее всего) означает, что точка доступа выключена или неисправна, или же малинка почему-то не может законектиться на точку доступа. Тут надо смотреть логи на малинке или зайти как администратор на точку доступа и посмотреть состояние соединений.

Кстати, если выдаются такие сообщения, то разумеется. никакой контакт с удалённым компом невозможен в принципе. И если Вы при таких сообщениях заходили куда-то по SSH, то значит - куда-то не туда Уточните IP обоих компов и проверьте ещё раз.

Значит отвалился веб-сервер.
Проверь командой

netstat -ant | grep 'LISTEN' | grep ':80' | wc -l

Если в ответ пустота, то так и есть

Возможно имеет смысл поэксперементировать с ОС реального времени или накатить real time kernel на Raspberry Pi OS

Я уже лет 10 занимался написанием драйверов для линуха, так что некоторый опыт есть. И эти вот Ваши идеи:

если делать 76 раз asm("nop"), то получается точно выдержать интервал 400 нс.

и

на время передачи данных делает spin_lock_irqsave()

кажутся мне довольно странными...Главная задача программиста при написании драйвера - уменьшить временные задержки, вносимые драйвером в работу ОС. А Вы делаете всё, что бы нарушить нормальную работу ядра. Но тогда не стоит удивляться, что результаты получаются какие-то странные!

Я по этим двум пунктам выскажусь так:

Для организации задержек на фиксированный интервал времени в ядре есть набор вызовов:

ndelay(unsigned long nsecs)
udelay(unsigned long usecs)
mdelay(unsigned long msecs) 

Я думаю, их вполне достаточно для Ваших целей.

Далее, по поводу блокировки прерываний с помощью spin_lock_irqsave() Эта функция может использоваться только в очень ограниченные периоды времени. Использовать её во время выполнения операций ввода/вывода довольно сомнительно. тем более, если данные передаются из/в userspace. А если нужной страницы из userspace в этот момент нет в оперативной памяти? Я настоятельно рекомендую убрать эти вызовы.