Сообщения pi

@sv-lary#6858 да вот хз, загуглил омни и сони, по фото у меня что-то иное, чебурашка с ушами ИК прожектори и объективом сразу из платы, вокруг объектива нет площадки

Какая камера?

• OmniVision OV5647
• Sony IMX219
• USB камера?

Включи на 10 секунд. Выключи. Потрогай чип процессора. Если резко сильно нагрелся, то точно всё.

Если чип процессора жив, то замерь выходные напряжения с PMIC чипа MXL7704.

Если будет не как на картинке, то чип умер. Закажи новый на aliexpress'е и попроси ремонтников телефонов поменять, если сам паять не умеешь такие компоненты

Время (часы) на малинке? Надо попробовать!

@lednevandrey04#6851 Есть Raspberry Pi с видеокамерой, которая ... получает скорость

Видеокамера скорость НЕ получает. Скорость автомобиля нужно брать от спидометра, с CAN шины, если есть такая возможность. Но можно и с GPS. Там точность показаний будет пониже, но на скорости 150 км/час это уже не будет играть особой роли.

@lednevandrey04#6851 размещен Банк из 1000 фотографий.

Что это означает? Есть каталог на SD-в котором лежат 1000 файлов JPG ?

@lednevandrey04#6851 показывает это ролик на экране монитора

Это совсем не сложно (Статья

avconv -r  1 -i frame%03d.jpg -r 10 animation.h264

При этом используется программа под названием avconv, которая берет неподвижные изображения в папке и конвертирует их в видео под названием animation.h264. В зависимости от того, сколько кадров вы сделали, этот процесс может занять какое-то время и вы узнаете, что видео готово, когда снова увидите приглашение терминала.

Чтобы воспроизвести видео, найдите файл animation.h264 в папке animation и дважды щелкните его, чтобы открыть. Кроме того, вы можете воспроизвести его из Терминала, набрав следующее:

omxplayer animation.h264

Как только видео загрузится, вы увидите, как оживает ваша покадровая анимация. Поздравляем: вы превратили Raspberry Pi в мощную анимационную студию!

@lednevandrey04#6851 Точнее нужно исследование по этому вопросу.

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

У меня нормально всё. А время правильно выставлено? Если время сильно неправильное, То могут быть проблемы с ssl сертификатом

У меня клонировалось всё секунд за 30 без всяких проблем:

$ git clone https://github.com/th33xitus/kiauh.git
Клонирование в «kiauh»…
remote: Enumerating objects: 2624, done.
remote: Counting objects: 100% (706/706), done.
remote: Compressing objects: 100% (406/406), done.
remote: Total 2624 (delta 472), reused 471 (delta 298), pack-reused 1918
Получение объектов: 100% (2624/2624), 738.23 КиБ | 766.00 КиБ/с, готово.
Определение изменений: 100% (1840/1840), готово.

sudo apt-get install git -y
cd ~
git clone https://github.com/th33xitus/kiauh.git
cd kiauh
chmod +x kiauh.sh scripts/*
./kiauh.sh

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

/home/pi/.config/lxsession/LXDE-pi/autostart - попробуй сюда прописать.
если не получится, смотри после загрузки лог /home/pi/.xsession-errors - там должны быть причина почему твоя программа не стартует.

проверь права на файле sunvox. У юзера pi должны быть права на запуск этого файла.

chmod  0777 /home/pi/sunvox/sunvox
chmod +x /home/pi/sunvox/sunvox

Спасибо, пробовал сделать автозагрузку, но ничего не происходит

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

Далее вставляю строку

@/home/pi/sunvox/sunvox

Сохраняю.
Путь написал, там в папке лежит исполняемый файл.
Ничего.

dietpi

В этот файл - /etc/xdg/lxsession/LXDE-pi/autostart нужно добавить последней строкой путь до исполняемого файла твоей программы
Отредактировать файл можно в терминале. Запускаешь терминал и в командной строке пишешь

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

@VBDUnit#6838, то что у Вас импульсы получаются очень короткими, это очень очень странно.
Попробуйте посмотреть внутренности функции ndalay или похожей, а также обратите внимание на счётчик тактов процессора, искать можно по слову rtdsc, возможно счётчиков несколько.
https://raspberrypi.stackexchange.com/questions/24882/armv6-instruction-set-for-getting-timestamp-counter-tsc

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

@Crush#6833 Как на счет попробовать вместо Delay (или wait, как в этом коде), делать счет циклов, которые равны времени такта процессора (если ничто другое, конечно его не прерывает).
Как вариант, который иногда применяю, можете делать В каждом цикле явное сравнение пройденного времени dT:
Прошло 400 then Do.
Это часто решает вопрос. По началу я только так с ШИМами и работал.

Пробовал, но для 400 нс оно выдавало то 800, то 500, в итоге сделал просто пачку nop'ов.

@sv-lary#6830 Да, ESP32 и STM32 тоже ко мне едут но что-то долго.

@Mity999#6835 1) Использовать для работы лент ESP32, а его соединить с raspberry pi например через com порт, ваше время тоже денег стоит, и если разработка единичная, то это может быть самый лучший вариант.

Мне почему-то тоже кажется что выход будет примерно такой.

@Mity999#6835 )Обратите внимание на библиотеку https://github.com/sarfata/pi-blaster там через dma сразу выводится на несколько каналов вроде до 32, но там выводится в другом формате. Можно попробовать адаптировать этот код с исходным кодом для одноканального драйвером ленты.

Очень интересно, пытаюсь сейчас понять как они это сделали.

@Mity999#6835 Писать в регистры ввода вывода на прямую(предварительно промэпировав их в адресное пространство процесса), минуя какие либо вызовы функций

Уже

Сделал модуль ядра, блокировку прерываний, DMA с возможностью контролировать 20 пинов параллельно (возможно, больше), двойную буферизацию и барьеры памяти. Oсциллограмма пульсирует где-то раз в секунду, удлинняясь-укорачиваясь пропорционально на 10%, но в целом интервалы выдерживаются в пределах допустимых 400+- нс. Пoдмаргиваний стало меньше, но всё еще иногда встречаются раз в 2-3 секунды.

Ключевое место работает так:

volatile register uint32_t m;
        while (smallBufferCurPos < smallBufferEnd)
        {
             //делаем это, только обмазывая всё в три слоя memorybarriами на всякий случай
            //*setReg = *smallBufferCurPos++;
            //*clrReg = *smallBufferCurPos++;
            
            m = READ_ONCE(*smallBufferCurPos);
            barrier();
            WRITE_ONCE(*setReg, m);
            smallBufferCurPos++;
 
            barrier();
 
            m = READ_ONCE(*smallBufferCurPos);
            barrier();
            WRITE_ONCE(*clrReg, m);
            smallBufferCurPos++;
 
            barrier();
                        
            //wait 400 ns
            asm volatile(A_LOT_OF_NOP);
        }

Буферы состоят из uint32_t. По бoльшому буферу бежим указателем с шагом 24 * 3 * 3 * 2. На каждом шаге копируем 24 * 3 * 3 * 2 значения в маленький буфер. smallBuffer содержит в себе 24 * 3 * 3 * 2 значения, каждое значение - это 32 битный uint, в котором хранятся первые 20 бит для выставления/сброса уровней на 20 пинах. Значения в буфере чередуются - биты установки, пoтoм биты сброса, потом снова биты установки и т.п. После каждой пары установки-сброса ждем 400 нс с помощью нопов.

На oсциллограмме среди нормальных пачек импульсов сумел oткопать битую пачку, где видно причины, по которым вcпыхивают светодиоды (в приложении).

Я не oчень понимаю, почему оно так выглядит. Я бы пoнял, если бы местами осциллограмма была растянута, т.к. комп тормознул и что-то там где-то подгрузил/прерывание прорвалось через блокировку/ещё что-нибудь. Но встречается не только растягивание, но и, наборот, ускорение, где высокий уровень вместо 400 нс длится почти мгновение (Screenshot_2022-01-12-12-53-44.png). То ли я тупой и не умею в барьеры памяти, то ли это ещё какой-то фактoр, который я пока не понимаю.

Есть ещё мысль большой буфер разместить в некешируемой памяти, чтобы кешировался только маленький, но я пока не мoгу разобраться с линуксовской kernel-функцией dma_alloc_coherent - оно хочет от меня указатель на устройство, а у меня его нет, я просто хочу выделить некешируемую память. NULL не передашь - падает, проверил. Возможно, нужно использовать другую функцию.

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

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

1. Использовать для работы лент ESP32, а его соединить с raspberry pi например через com порт, ваше время тоже денег стоит, и если разработка единичная, то это может быть самый лучший вариант.
   2)Обратите внимание на библиотеку https://github.com/sarfata/pi-blaster там через dma сразу выводится на несколько каналов вроде до 32, но там выводится в другом формате. Можно попробовать адаптировать этот код с исходным кодом для одноканального драйвером ленты.
2. Писать в регистры ввода вывода на прямую(предварительно промэпировав их в адресное пространство процесса), минуя какие либо вызовы функций

@VVladimir#6478 Вы можете делать шесть (и более) потоков с программными ШИМами, на каждый Пин. И управляйте сплкойно драцверами Мосфетов, Ir2101 или что там вы используете.

@VBDUnit#6829 Как на счет попробовать вместо Delay (или wait, как в этом коде), делать счет циклов, которые равны времени такта процессора (если ничто другое, конечно его не прерывает).
Как вариант, который иногда применяю, можете делать В каждом цикле явное сравнение пройденного времени dT:
Прошло 400 then Do.
Это часто решает вопрос. По началу я только так с ШИМами и работал.