Przeszukaj forum

Dzisiaj nieco odpoczynku od elektroniki. Ale oczywiście o ile ta cała kabelkologia jest niezmiernie ważna i ważne jest urządzenie sobie warsztatu - to samo można powiedzieć o "warsztacie programisty", czyli zorganizowaniu tak stanowiska, aby można było skupić się na tym co najważniejsze: tworzeniu kodu. Wrzucam to jako worklog, bo kilka spraw jest jeszcze nie do końca rozwiązanych (m.in. użycie esptool-ftdi, na czym bardzo mi zależy), ale w tej postaci jaka jest program jest absolutnie używalny i spełnia swoją funkcję. Na potrzebę powstania tego programu złożyło się kilka czynników. Przede wszystkim w większości do programowania swoich ESP używam frameworku Arduino, a Arduino IDE z różnych przyczyn uważam za mało używalne. Poza tym także nie przepadam za pisaniem Makefile (chociaż po napisaniu bardzo lubię używać make). Postanowiłem więc zrobić sobie wrapper do arduino-cli. Wrapper działa na Linuksie, ale nie widzę przeszkód w uruchomieniu go na Macu czy nawet na Windows, potrzebne by były jedynie niewielkie zmiany. Przede wszystkim musiałem zrobić to, czego mi a Arduino IDE brakuje - czyli oddzielna konfiguracja dla każdego szkicu. Postanowiłem pójść jeszcze dalej: ponieważ zdarza mi się ten sam program uruchamiać na kilku różnych architekturach, założyłem możliwość istnienia kilku wariantów konfiguracji dla każdego szkicu i zabrałem się do roboty. Ponieważ znałem już strukturę plików boards.txt i platform.txt poszło dość szybko - i w relatywnie krótkim czasie miałem już gotowy konfigurator. Oczywiście zanim cokolwiek się zrobi trzeba dodać nowy wariant. Po wciśnięciu klawisza "Nowa" ukazuje się okno tworzenia wariantu: Jak widać jest to podobne do menu wyboru płytki w Arduino IDE, dochodzi jedynie pole "Nazwa", pozwalające na nadanie wariantowi jakiejś łatwej do zapamiętania nazwy. Po utworzeniu wariantu można zabrać się do konfiguracji. I tu znów wzorowałem się na menu Arduino IDE - wszystkie parametry są widoczne na liście, a aktywacja wiersza (czyli dwuklik albo wciśnięcie Enter) powoduje pojawienie się możliwości wyboru predefiniowanej opcji: Jak widać, na razie różnice w stosunku do IDE są niewielkie, ale następną rzeczą, która w IDE jest dla mnie szalenie niewygodna, jest wybór portu do uploadu. Przede wszystkim - nasze systemy operacyjne przyporządkowują numer portu do urządzenia w sposób raczej losowy. Odłączenie i ponowne podłączenie płytki skutkować może np. zmianą portu z ttyUSB0 ma ttyUSB1, co potrafi trochę krwi napsuć. Dość dawno jednak stworzyłem prosty system detekcji portu, i zastosowanie go tutaj było oczywiste. Po prostu podaję jaki to ma być typ portu (do wyboru ttyS, ttyUSB i ttyACM) i/lub nazwę pod jaką zgłasza się podłączone urządzenie. Program szukając portu przeszukuje tylko te o zadeklarowanym typie, ewentualnie sprawdzając, czy nazwa odczytana z urządzenia zawiera w sobie wyszukany string. W ten sposób np. uploader dostaje informację że ma się połączyć na tym a nie innym porcie. Ten sposób działa u mnie już od ok. dwóch lat i jeszcze mnie nie zawiódł. W programie wprowadziłem jeszcze jedną zmianę: jeśli nazwa rozpoczyna się od VID:PID (np. "2341:0043 Uno R3") będzie wyszukiwane urządzenie odpowiadające odczytanym z USB wartościom VendorID i ProductID. Również nazwa w przypadku urządzeń USB będzie (o ile to mozliwe) pochodzić z oficjalnego wykazu. Następną sprawą jest ustawienie adresu i hasła OTA. O ile w IDE konieczne jest, aby urządzenie było włączone w czasie ustawiania portu, o tyle tu takiej konieczności nie ma: mogę albo skorzystać z listy urządzeń wykrytych przez zeroconf (przy czym mogę sobie zapisać albo nazwę, albo adres IP) albo podać te dane ręcznie (jeśli je znam). Poza tym mój program zapamiętuje hasło, co bywa wygodne (szczególnie w porównaniu do IDE w wersji 2.x). I ostatnia rzecz: użycie zewnętrznego programu do uploadu. Może to być np. program obsługi jakiegoś programatora, albo (jak w moim przypadku, co postaram się pokazać przy najbliższym DIY) skrypt wysyłający skompilowany plik do maszyny, do której podłączona jest płytka. W sumie okno konfiguratora uploadu wygląda tak: Istnieje również możliwość dodania dodatkowych parametrów do kompilacji. Dla architektury AVR można włączyć pełną wersję sprintf (tzn. taką, która pozwala na wypisywanie floatów). Można również dodać dowolną ilość definicji, które w programie będą traktowane jako dodatkowe linie #define. Poziom szczegółowości ostrzeżeń działa nieco inaczej niż w IDE: dla platform, dla których automatycznie dodawane jest -Werror przy wyświetlaniu wszystkich ostrzeżeń parametr ów nie jest dodawany automatycznie, można go dodać zaznaczając odpowiednie pole. W ten sposób można bez zbytniej ekwilibrystyki kompilować programy np. na ESP32 z wyświetlaniem wszystkich ostrzeżeń (w IDE przy takim przełączeniu kompilator odmawia kompilacji bibliotek które generują jakieś ostrzeżenia, choćby nawet nie miały wpływu na ich działanie): I to już cały konfigurator. Teraz wystarczy zapisać całą konfigurację (przycisk "Zapisz" lub "Zapisz i zakończ"). Jako domyślny zostanie wpisany wariant aktualnie wskazany na liście. No, ale konfigurator to nie wszystko - warto by było mieć coś, co z tego konfiguratora korzysta. Postanowiłem stworzyć jedno polecenie, które zależnie od podanych opcji będzie robiło różne czynności. Jako że najważniejszym poleceniem jest "help", tak wygląda wynik jego działania (i kilku następnych): Pisząc program natknąłem się na kilka nieprzyjemnych niespodzianek związanych z arduino-cli. Początkowo najbardziej naturalne wydało mi się umieszczenie katalogów build i cache wewnątrz katalogu szkicu. Stosowałem to już wcześniej używając arduino-builder i make, tak więc wydało mi się to najlepszym i w dodatku sprawdzonym rozwiązaniem. A guzik... arduino-cli bardzo grzecznie kompilował program, ale tylko raz. Ki diabeł? No tak, zajrzenie na githuba do issues wszystko wyjaśniło. Jest to stary, szacowny błąd z długą brodą, polegający na tym, że arduino-cli uważa pliku w katalogu build za pliki żródłowe, i próbuje je jeszcze raz skompilować (co się oczywiście nie udaje). W związku z tym preniosłem owe katalogi do /tmp, jakoś w miarę sensownie je ponazywałem i zadziałało... No prawie, a jak wiadomo - prawie robi wielką różnicę. Otóż plik konfiguracji (w formacie json) zapisywany jest w katalogu szkicu (no bo gdzie miałby być zapisany) z rozszerzeniem .json - a to też zmyliło arduino-cli które koniecznie chciało go skompilować. Zmiana rozszerzenia na .cfg skutecznie oduczyła arduino-cli nadmiernej gorliwości i wszystko ładnie ruszyło... Z jednym wyjątkiem: uploadu przez OTA. Podobno arduinio-cli to potrafi (w końcu jakoś IDE w wersji 2.x daje sobie z tym radę, aczkolwiek nie tak do końca). Postanowiłem więc darować sobie sprawdzanie i upload OTA rozwiązać "ręcznie". Jako że jak dla mnie dotyczy to tylko ESP, zaprzągłęm do pracy parser konfiguracji arduino (który i tak jest częścią programu), i dopisałem kilka linijek. Co prawda w tej postaci upload OTA możliwy jest wyłącznie dla ESP32 i ESP8266, ale po pierwsze nie mam innych mikrokontrolerów dla których mógłbym to wykorzystać, po drugie dopisanie kolejnych architektur to kwestia kliku minut, a po trzecie wszystko można załatwić możliwością uploadu przez zewnętrzne polecenie. Aha, no i najważniejsze: może autorzy arduino-cli jakoś w końcu uporają się z implementacją obsługi OTA 🙂 No cóż - chciałbym powiedzieć że to wszystko, ale już słyszę narzekania: linia poleceń? Ajaj, przecież to takie trudne, lepiej sobie kliknąć w jakieś menu w aplikacji! A da się. Porządne edytory (np. Geany) mają możliwość skonfigurowania zewnętrznych poleceń. Dla przykładu rozwiązanie wyklikane dla plików *.ino wygląda w Geany tak: No i na koniec kwestia instalacji. Najpierw musimy upewnić się, czy mamy potrzebne biblioteki i programy współpracujące:Python, gobject-introspection i gtk3 najprawdopodobniej już mamy; można to łatwo sprawdzić uruchamiając konsolę python3 i wpisując polecenia importu Gtk3: $ python3 Python 3.8.10 (default, Jun 22 2022, 20:18:18) [GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import gi >>> gi.require_version('Gtk', '3.0') >>> from gi.repository import Gtk >>> Jeśli nie było błędu wszystko jest w porządku; w przeciwnym razie należy sprawdzić w dokumentacji swojej dystrybucji. Dodatkowo potrzebny będzie pakiet zeroconf i usb.ids. Jeśli ich nie będzie, pakiet zeroconf można zainstalować z githuba, a plik usb.ids można ściągnąć z internetu i umieścić gdziekolwiek wskazując ścieżkę we właściwym miejscu w pliku arduports.py w linii zawierającej polecenie: f=open('/var/lib/usbutils/usb.ids','rb') No i ostatnie najważniejsze: arduino-cli. Możemy zainstalować z githuba, lub użyć wersji zawartej w Arduino-IDE 2.x. Ważne, aby znalazło się w ścieżce wskazanej przez $PATH! Właściwy program instalujemy oczywiście z poziomu użytkownika, a nie roota! W tym celu musimy znać katalog, w którym możemy umieścić polecenia. Dla Linuksów będą to najprawdopodobniej ~/bin lub ~/.local/bin - można to sprawdzić poleceniem: echo $PATH Załóżmy że jest to katalog ~/bin. Plik pyrduino.tgz umieszczamy tam, gdzie nie powinien się zgubić (np. w katalogu domowym) i wykonujemy kolejno polecenia: tar -xzf pyrduino.tgz cd pyrduino-src chmod 755 ardu.py ln -sf $(pwd)/ardu.py ~/bin/arducfg ln -sf $(pwd)/ardu.py ~/bin/ardu I to wszystko. Możemy teraz wejść do katalogu szkicu i pobawić się poleceniami arducfg i ardu. Na koniec jedna uwaga: o ile polecenie arducfg musi pozostać takie a nie inne (można to zmienić w pliku ardu.py), o tyle zamiast nazwy ardu możemy użyć dowolnej, która nam się podoba. I jeszcze jedno: jak wspominałem na początku, da się to pewnie zainstalować na Macu (z niewielkimi zmianami) i na Windows (z większymi zmianami). Gdyby komuś się to udało - proszę o danie znać w komentarzu; może komuś się przyda! Do ściągnięcia: pyrduino.tgz I tak już całkiem na zakończenie dla miłośników make - krótki przykład: BINARY=$(shell ardu -show | grep -P '^Build\s+=' | tr -d " " | cut -d= -f2) $(BINARY): *.ino ardu PHONY: flash flash: $(BINARY) ardu -V -flash PHONY:ota ota: $(BINARY) ardu -ota PHONY:clean clean: ardu -clean Prawda, że proste?