ericN

В Yocto вы можете использовать класс recipe-util для компиляции инструментов из исходных кодов таких как fw_printenv и помещения их в /usr/bin. Вот пример рецепта, который вы можете использовать: SUMMARY = "U-Boot Environment Tools" LICENSE = "GPL-2.0" LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=94d55d512a9ba36caa9b7df079bae19f" SRC_URI = "git://git.denx.de/u-boot.git;protocol=https;tag=v2021.07 \ file://Makefile \ file://fw_printenv.c \ file://fw_env_private.h" SRCREV = "${AUTOREV}" S = "${WORKDIR}/git/tools/env" inherit recipe-util do_install() { install -m 0755 ${B}/fw_printenv ${D}/usr/bin/ } Этот рецепт загружает исходный код утилиты fw_printenv из репозитория U-Boot, компилирует ее и устанавливает в /usr/bin. Вы можете сохранить этот рецепт в каталоге meta-mylayer/recipes-extended вашего Yocto-проекта. Затем добавьте ваш рецепт в IMAGE_INSTALL_append в вашем local.conf: IMAGE_INSTALL_append = " fw_printenv" После этого перезапустите сборку вашего образа Yocto, и утилита fw_printenv будет доступна в /usr/bin после развертывания образа на целевом устройстве.

хотел предложить написать свой драйвер UART и там реализовать всё что Вам нужно, но потом увидел тут только прикладной уровень. Может быть Qt? У QSerial есть сигнал по получении байта. Пишем свой слот, который по одному выгребает весь приемный буфер серийного до стоп-символа. Как нашел, сигналит пакетом обработчику пакетов.

свои 5 коп. "ls /dev" - ищем что-то типа mmc**** расделы флеш/нан/т.п. Можно глянуть fstab и посмотреть куда смонтирован рутфс. если рутфс на /dev/mmcblk3p2, то нужен /dev/mmcblk3p1. Где-то на флеше есть раздел, в котором ядро и дерево девайсов. Нужно найти этот раздел. Смонтировать как fat куда-нибудь в /mnt/dtb В этом разделе должно быть дерево девайсов, файл *.dtb (и ядро, обычно zImage) тащим тот файл на хост ПК, преобразуем из dtb в dts Открываем текстовым редактором dts - картина маслом. Находим свой ethernet и смотрим чем он дышит? какие ноги, какое управление mdio/spi/i2c.... (я получал доступ до регистров, и по мойму как раз инструментом mii-tool). Возможно, там же увидите значения регистров вашего eth, которые драйвер ядро задает при старте. Опять же ..... вангую... возможно для ёвной конфигурации надо в probe драйвер передать аргументы. И возможно достаточно эти аргументы поправить (или задать) в dts (и получите желаемую переконфигурацию). Потом обратно dts в dtb. Переписать dtb в разделе /dev/mmcblk3p1 - профит!!! ps Но есть шанс получить кирпич. Хотя, если синтактическая ошибка в dts, то dtb не соберёте. А если передадите в драйвер из dtb "плохой" аргумент - в худшем случае ethrnet не заведётся, а всё остальное будет работать. Если не куда будет подрубить терминал, акромя ssh - то рабочий роутер без терминала - это тот же кирпич.

А что такое dev/video1? Нет, я понимаю, что в /dev/*** все устройства. Например в каком-нибудь телефоне есть у процессора CSI и на нем две камеры - фронтальная и тыльная, они будут /dev/cam0 и /dev/cam1. Но я спрашиваю про ip камеру. IP камер в dev нет. по рукой нет пока рабочей платы... не могу проверить... если --stream-to = ~/images/capt.bmp, то как несколько равок лягут в один файл?

1) Что такое "path/to/video_device"? Это uri? Как команда должна выглядеть в моём случае? Так? v4l2-ctl --device rtsp://192.168.10.20:554/live/ch01_0 C width и height понятно. 2) Что такое pixelformat? Какие бывают пиксель форматы в ip? Как его задать? 3) --stream-to - это я понял файл... т.е. имедж файл куда будет записан имедж изображение захваченное с камеры, допустим сделать так --stream-to = ~/images/capt.bmp тогда что такое --stream-count=number_of_frames_to_capture? В файл capt.bmp будет захвачено несколько имеджей изображений и они забиндятся в один bmp? Или такой командой будет захвачено не имедж, а видео?

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

в каком эфире?

Серьёзно!? А что такое мануал? Не знаю ни каких мануалов.

режим везде implicit, crc везде отключен. Пакет везде одинаковый, SF7, BW125, CR4/5. Использую библиотеку llcc68 Коммуникация с llсс68 правильная (т.е. spi c мк нормально всё считывает и записывает). даже без какой либо передачи, после включения/инита чипа статус RxBuffer-а выдает, что есть пакет по адресу 0 и длинной 255. От куда? Может так и должно быть и после первого приёма все указатели лягут по красоте. У кого есть под рукой llcc68? Можете проверить, что выдает GetRxBufferStatus() после инита до SetRx?

Передатчик на SX1276 раз в 5 секунд шлёт короткий пакет (25 байт). Пытаюсь принять на ccll68. После того, как частоты передачи по анализатору в sx1276 и ccll68 свёл на одну частоту, ccll68 начал принимать, вернее в режиме приема исправно встает флаг PREAMBLE_DETECTED и следом RX_DONE. Читаю статус rx буфера (GetRxBufferStatus), получаю длину пакета 255 байт. В начале программы устанавливаю указатель rx буфера (SetBufferBaseAddress) в 0. После приема вычитал все 256 байт из llcc68 - там мусор. 100 пудов руки не из плеч.... но... выключил передатчик на sx1276. ещё раз.... делаю инит ccll68, выставляю адреса буферов в 0 (SetBufferBaseAddress(0,0), в режим Rx модуль не перевожу, а читаю статус rx буфера (GetRxBufferStatus), получаю длина пакета 255, офсет 0. Почему длинна пакета 255? Пакета ещё не было. если включить передатчик и перевести модуль в режим continuous_receive, то после каждого пакета из sx1276, статус GetRxBufferStatus дает длину пакета 255, а смещение меняется так 0,... 255....254.... 253..... 252.... т.е. указатель в приемном буфере при каждом приеме увеличивается ровно на 255. Кто нибудь с подобной проблемой сталкивался?

физически они ни куда не подключены. в dts тоже не описаны. смотрю что в итоге пин 19 управляется, а другие нет.

как? вот какой у меня сейчас тулбар по мойму на этом тулбаре нем была эта кнопка. Забавно, даже одна цепь осталась подсвечена именно этой кнопкой. вот Customize. что от куда куда и как переносить?

Ещё вопрос по оклотеме.... вот на хаб на 24-ую ногу затянут ресет с cpu. Цепь USB_RST подсоеденина к пину NANDF_D7 (или GPIO2_IO7). На этом пине всегда 3,3В. Я в дереве девайсов убрал этот пин отовсюду. делаю команды по мануалу для imx6q echo 39 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio39/direction echo 1 > /sys/class/gpio/gpio39/value На пине +3,3В. Делаю echo 0 > /sys/class/gpio/gpio39/value - на пине остается +3.3В. Почему? Есть также пин GPIO1_IO19 - SD1_DAT2, который подключен на светодиод. Такими же командами записываю в пин "1" или "0", св.диод горит и гаснет. Всё работает. А с GPIO2_IO7 нет. Так же есть пин на управление ресетом модема GPIO3_IO15. Тоже самое - при ручном управлении на пине всегда +0,25В. Почему некоторые пины управляются через /sys/class/gpio, а некоторые нет?

а почему в starterkit не стали использовать PRTPWR, а использовали GPIO процессора?

У меня есть другой кит с imx6q и тоже с хабом USB2514. Но на моём ките управление питанием на внешних усб портах нет. Там напрямую пин Vcc в разъеме USB подтянут к шине VCC5V. В ките на starterkit питание на внешние усб подаются через ключ и управляются с GPIO процессора. В обоих китах USB2514 и в этом хабе в принципе есть PRTPWR*, но в обоих китах управление питанием с хаба не используется. На моей плате, управление питания осуществляется именно с хаба. Можно конечно переделать плату и управлять питанием с GPIO, но хотелось бы понять, что не так с PRTPWR? Или тут как раз придется писать специфичный драйвер для хаба, который сделает инит хаба по i2c?