Начнём с вводной. Пришёл как-то дрон Rekon35, ну я первым делом и сел за его обслуживание. Прошил регули на Bluejay и поменял музыку на мотороах (это важно). Осталось дело за малым - прошить приёмник ELRS версией посвежее, потому что то, что там шло (2.5.1) объявлено уже неподдерживаемым. Я не разработчик, раз разработчики так говорят, наверное, надо...
В общем, ничего сложного, я так уже 1000 раз делал - нам надо скачать ExpressLRS Configurator, хотя он может быть уже есть, но текущий просил обновиться. Далее мы его запускаем. Выбираем что нам надо шить. Ну мне нужно было обновить прошивку на модуле передатчика и на модуле приёмника. Решил начать с последнего. Это у нас HLRC 2.4. В общем, всё выбрал, версию последнюю, выбрал свою бинд фразу, свои опции. Поставил галочку на метод прошивки через Betaflight, ткнул "Build and flash" и пошёл чай пить, а заодно и вытаскивать свою аппу, её же тоже нужно прошить.
Сразу почувствовалось, что вечер перестаёт быть томным. Крутанул ошибку на самый старт, там ересь какая-то. Вбиваю в гугл, читаю репорт на гитхабе. Вижу, что есть проблема у PlatformIO проблема с Python версии 3.11. Вот прямо такая же проблема. Люди решают созданием виртуального окружения с версией 3.10. Ну мне ехать, а не шашечки, поэтому проблем нет. Проблема другая. У меня Void Linux и всё обновлённое. И даунгрейдить питон желания нет. Я посчитал, что усилия по даунгрейду и поддержанию его на таком уровне не стоят того, чтобы только собрать одну маленькую прошивку и решил скачать питон куда-нибудь. Собственно, забрал исходники, потому что бинарников нет (ну и не надо). Быстро в гугле глянул как оно всё устанавливается. Ну вроде бы просто. То есть, распаковываем, входим в нашу папочку и далее нехитрые манипуляции.
./configure --prefix=$HOME/python3.10
make
make install
Вроде бы всё хорошо. Питон установился, создаём окружение. И уже из этого окружения запускаем наш конфигуратор для ELRS. Ну выглядит как что-то подъёмное. Погнали:
cd
virtualenv ~/python3.10-env -p ~/pyton3.10/bin/python3.10
source ~/python3.10-env/bin/activate
expresslrs-configurator
Всё, конфигуратор запустился. Всё хорошо. Выбираем что ранее выбирали. Жмём опять же Build and flash и, довольный, что я такой пипец гугл умею читать, ухожу пить чай. В уме пока прикидываю какие полётные режимы буду настраивать и всё такое. Когда пришёл, меня ждал облом. Но на этот раз понятный. Дело в том, что в прошлый запуск конфигуратора при компилировании было создано уже виртуальное окружение, но для PlatformIO, чтобы он там изолированно находился и можно было его легко удалить. Оно находится, кстати, в ~/.platformio/penv/. И создано было с версией питона 3.11. Соответственно, так же не работало. Это фиксится легко. Просто удаляем это окружение и перезапускаем наш Build and flash.
Собственно, это проблему не решило. Точнее, решило, возможно, предыдущую, но при этом стала появляться другая. С другим текстом ошибки. На этот раз это было что-то совсем ересевое, типа, не найден _ctypes или типа того, по которому гуглится много чего и конкретно к этой проблеме применить не представляется возможным. Точнее, там есть разные способы, почему в virtualenv появляется такая ошибка, но перебирание решений с гугла проблему не решило совсем никак.
Я теперь уже эволюционировал и вместо Build and flash начал жать просто Build. А далее заходил в виртуальное окружение PlatformIO (~/.platformio/penv) и проводил манипуляции там. Но всё было тщетно. Ночь перевалила уже за свою вторую половину. Я подумал, что ладно, надо посмотреть что у меня ещё есть из компьютеров, но все они были на некотором удалении с доступом по сети. Например, на рабочем компьютере я ещё не успел так обновиться и как раз питон был там версии 3.10. То есть, всё вообще хорошо. Соединился, собрал. Прошивку получил. Но тут сразу сыграло несколько факторов. Первый состоял в том, что нужно было прошить модуль через Betaflight Passthrough. Второй, что машина удалённая и для прошивки по бетафлайт надо ещё пробрасывать USB порты, чем заниматься не очень хотелось. И, наконец, как-то всё это неправильно искать где собрать и вообще, стало любопытно, как это можно сделать без конфигуратора.
Тут небольшое отступление почему именно нужно было использовать Betaflight Passthrough. Дело в том, что я отключаю режим Auto WiFi, то есть переходить в режим точки доступа через определённое время после отсутствия соединения. Я так начал делать после одной истории, как я, отлетев на пару километров, потерял им управление и он упал. Я вот сейчас точно не могу сказать перезагрузился он от удара или нет, но ELRS модуль перешёл в режим WiFi и я не мог соединиться к своему дрону. При этом батарея от него не отлетела, питание подавалось, но пищалку активировать было нельзя. Не помню как я его нашёл, но оказалось, что я проходил мимо него несколько раз. Ну и в шлеме видел, что он лежит, куда-то смотрит. Поэтому режим удобный, но на практике может быть опасный.
Итак, скачал я с гитхаба архив с исходниками с потаганной версии, распаковал, нашёл там файл user_defines.txt и добавил туда то, что можно увидеть в конфигураторе ELRS в MANUAL MODE, который заполнил тем, что нажал COPY FROM STANDARD MODE. Ну далее всё не просто, а очень просто.
pio run --environment HGLRC_Hermes_2400_RX_via_BetaflightPassthrough
И, о чудо, он собрался! :) Хотя это можно было просто и в конфигураторе сделать. Откровенно говоря, тут уже пошли лишние действия для достижения результата, но просто уже проснулся спортивный интерес. Далее полученную прошивку (.pio/build/HGLRC_Hermes_2400_RX_via_BetaflightPassthrough/firmware.bin) нужно было транспортировать на дрон. Можно было это сделать через WiFi, но я подумал как я буду обновляться в следующий раз, если WiFi будет отключён? Поэтому нужно было отработать процедуру.
Собственно, далее идёт чтение исходников, поиск по ключевым словам. Но в итоге сводится к двум вещам: инициализация бетафлайт для заливки прошивки и, собственно, запуск прошивальщика:
python BFinitPassthrough.py -p /dev/ttyACM0 -b 420000 -r HGLRC_HERMES_2400_RX && python esptool-3.0/esptool.py --chip esp8266 --port /dev/ttyACM0 --baud 420000 --before no_reset --after soft_reset write_flash 0x0000 /tmp/firmware.binpython python/BFinitPassthrough.py -p /dev/ttyACM0 -b 420000 -r /tmp//firmware.bin -a upload --accept HGLRC_HERMES_2400_RX
И он залился! И теперь нужно было сделать то же самое и для модуля передатчика. Ну там хотя бы всё просто в том плане, что активация режима WiFi через управление на аппаратуре и можно прошивать по воздуху. Светало. Проблема была решена. Но перед тем как лечь спать я ещё раз решил пройтись по порядку моих действий. И во время установки питона я обратил внимание на одну надпись.
If you want a release build with all stable optimizations active (PGO, etc),
please run ./configure --enable-optimizations
И тут в голову начинают закрадываться смутные сомнения. Собственно, почему бы не попробовать? Всё равно вся ночь прошла как мигу же, минутой больше, минутой меньше разинцы нет:
./configure --prefix=$HOME/python3.10
make
make install
Далее уже просто активируем наше виртуальное окружение питона 3.10, запускаем из него expresslrs-configurator, пробуем билдить... И... Всё работает!
Если подводить итоги, то ясно, что когда находишься не в мейстриме (Ubuntu, Debian) тебе гораздо сложнее. Думаю, что тот же арч решил бы проблемы, наверное, но не уверен. Поэтому если этим заниматься постоянно, то тяжело ловить все эти обновления. Гораздо легче держать что-нибудь замороженное, но подтверждённое, что работает. С другой стороны ясно, что самую большую ценность обладают знания. Именно они помогают найти выход из ситуаций и построить планы на дальнейшие действия. Что же по ExpressLRS - новичкам тяжело конкретно в этих ситуациях, но рабочая среда у меня не совсем новичковая, если уж быть честным. Поэтому, если что-то не получается, есть смысл где-нибудь собрать наиболее типичное окружение и рабоать с него, если нужен результат.
Тут бытует мнение, что на Crossfire нажал две кнопки и у тебя всё забиндилось, обновилось что нужно. Возможно, это так. Его у меня никогда не было и желания брать тоже нет. Несмотря на что. За всё приходится платить. За свободу - больше всего.
