Popularny post ethanak Napisano Listopad 16, 2022 Popularny post Udostępnij Napisano Listopad 16, 2022 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? 5 Link do komentarza Share on other sites More sharing options...
ethanak Listopad 17, 2022 Autor tematu Udostępnij Listopad 17, 2022 Dobrze jest się przespać i wpaść na pomysł - esptool-ftdi wydaje się działać. Sposób instalacji (trochę nietypowy) opiszę jak wszystko sprawdzę - na razie poprawiony program: pyrduino.tgz I drobna uwaga: Przy kompilacji na esp8266 wyskakuje sobie błąd: xtensa-lx106-elf-g++: error: unrecognized command line option '-std=gnu++17' Błąd znany, dokładnie opisany swego czasu na githubie od arduino-cli razem z przykładowymi przykładami 😉 Z moich obserwacji: Błąd wyskakuje, jeśli nie istnieją katalogi build i cache (czyli przy nowym szkicu albo po -clean). Należy po prostu uruchomić kompilację jeszcze raz i powtarzać do skutku - gdzieś za trzecim czy czwartym razem zaczyna normalnie działać. Ewentualnie poczekać aż autorzy arduino-cli poprawią parser receptur... 2 Link do komentarza Share on other sites More sharing options...
ethanak Listopad 17, 2022 Autor tematu Udostępnij Listopad 17, 2022 Z ostatniej chwili: Arduino-cli w wersji nightly (z dzisiaj) wydaje się działać poprawnie dla esp8266 (tzn. nie ma "unrecognized option"). Ale może to tylko przypadek... 1 Link do komentarza Share on other sites More sharing options...
Harnas Listopad 18, 2022 Udostępnij Listopad 18, 2022 Nie interesowałem się nigdy arduino-cli, ale czy nie było by łatwiej napisać taki wrapper do platformio cli? I przy okazji dając większe możliwości rozwoju? Link do komentarza Share on other sites More sharing options...
Polecacz 101 Zarejestruj się lub zaloguj, aby ukryć tę reklamę. Zarejestruj się lub zaloguj, aby ukryć tę reklamę. Produkcja i montaż PCB - wybierz sprawdzone PCBWay! • Darmowe płytki dla studentów i projektów non-profit • Tylko 5$ za 10 prototypów PCB w 24 godziny • Usługa projektowania PCB na zlecenie • Montaż PCB od 30$ + bezpłatna dostawa i szablony • Darmowe narzędzie do podglądu plików Gerber Zobacz również » Film z fabryki PCBWay
ethanak Listopad 18, 2022 Autor tematu Udostępnij Listopad 18, 2022 5 godzin temu, Harnas napisał: Nie interesowałem się nigdy arduino-cli Nie interesowałem się nigdy PlatformIO, ale czy on naprawdę jest jakiś ułomny że trzeba do niego wrappery pisać? 😉 Bo np. Arduino IDE 2.x jest tak naprawdę niczym innym jak wrapperem do arduino-cli... 5 godzin temu, Harnas napisał: przy okazji dając większe możliwości rozwoju Jakie mianowicie? Link do komentarza Share on other sites More sharing options...
ethanak Listopad 18, 2022 Autor tematu Udostępnij Listopad 18, 2022 (edytowany) No i niestety, arduino-cli cały czas ma problem, ale już znam sposób na szybki workaround (dotyczy to również Arduino IDE 2.x i prawdopodobnie PlatformIO): Problem występuje, gdy dla różnych architektur istnieją takie same nazwy katalogów tools (w tym przypadku gcc). Rozwiązaniem jest wymuszenie konkretnej wersji (lub usunięcie innych architektur, ale to raczej nie jest dobre rozwiązanie) Podaję przykład dla esp8266: Znajdź swój katalog arduino15. W linuksie będzie to ~/.arduino15. Dla innych systemów patrz: https://support.arduino.cc/hc/en-us/articles/360018448279-Open-the-Arduino15-folder W katalogu znajdź subkatalog "packages/esp8266/tools/xtensa-lx106-elf-gcc" Otwórz ten katalog. Powinien tam być tylko jeden subkatalog o nazwie w stylu "3.0.4-gcc10.3-1757bed". Skopiuj tę nazwę. Teraz wróć do katalogu esp8266, przejdź do hardware/<jakiś-numerek>/esp8266 i otwórz jakimś edytorem plik platform.txt Znajdź linię rozpoczynającą się od "compiler.path". Powinna wyglądać mniej więcej tak: compiler.path={runtime.tools.xtensa-lx106-elf-gcc.path}/bin/ Zmień doklejając do ścieżki kompilatora skopiowaną nazwę katalogu po myślniku, czyli w moi przypadku: compiler.path={runtime.tools.xtensa-lx106-elf-gcc-3.0.4-gcc10.3-1757bed.path}/bin/ Arduino-cli będzie teraz szukać kompilatora w konkretnej wersji, a nie pierwszego lepszego. Edytowano Listopad 18, 2022 przez ethanak 1 Link do komentarza Share on other sites More sharing options...
ethanak Styczeń 2, 2023 Autor tematu Udostępnij Styczeń 2, 2023 Bardzo lubię nieudokumentowane zachowania różnych fajnych programów... Takie jedno coś właśnie znalazłem (kiedy arduino-cli ignoruje extra_flags z platform.txt). Mam nadzieję że więcej takich niespodzianek nie będzie. Jakby komuś się chciało potestować: pytduino.tgz 1 Link do komentarza Share on other sites More sharing options...
ethanak 12 czerwca Autor tematu Udostępnij 12 czerwca Coś się dzieje - właśnie testuję możliwość zdalnego uploadu przez RPi (nie zawsze da się użyć OTA). Na razie dla esp8266 i esp32, jeśli wyjdzie to dodam AVR-y. Wszystkie znaki na niebie i ziemi wskazują, że jutro powinno to ładnie ruszyć 🙂 1 Link do komentarza Share on other sites More sharing options...
_LM_ 12 czerwca Udostępnij 12 czerwca Co to oznacza? RPi jako przenośny programator? Link do komentarza Share on other sites More sharing options...
ethanak 12 czerwca Autor tematu Udostępnij 12 czerwca Dokładnie. Jak skończę wszystkie testy to opiszę. Zresztą nie musi być RPi, dowolny z Linuksem na pokładzie. 1 Link do komentarza Share on other sites More sharing options...
_LM_ 12 czerwca Udostępnij 12 czerwca Fajny bajer, nie trzeba nosić ze sobą wszystkich gratów Link do komentarza Share on other sites More sharing options...
ethanak 12 czerwca Autor tematu Udostępnij 12 czerwca Żeby było śmieszniej - znowu bazuję na nieudokumentowanym zachowaniu arduino-cli: parametr --dry-run zniknął z dokumentacji ale na szczęście nie z kodu 🙂 Link do komentarza Share on other sites More sharing options...
ethanak 13 czerwca Autor tematu Udostępnij 13 czerwca (edytowany) No więc tak... Pyrduino używam cały czas i stwierdziłem, że dla kogoś kto woli terminal od klikania myszami jest dużo wygodniejszy niż Arduino IDE, PlatformIO czy co tam ktoś wymyślił. Brakowało mi jednej rzeczy: jakiegoś sensownego zdalnego programowania moich esp-ków. Niby istnieje cos takiego jak OTA, ale: część ESP (np. wszystkie 8266 w domowej instalacji) nie ma dostępu do sieci (komunikują się po esp-now) część ESP (np. wszystkie 4-megowe ESP32 z syntezą mowy) po prostu nie mają miejsca na partycję OTA. Ponieważ mam taką miłą przenośną konsolkę z RPi na pokładzie postanowiłem użyć jej jako zdalnego programatora. Oczywiście nie trzeba tam żadnych ekranów czy głośników - na dobrą sprawę wystarczy RPi Zero W, przejściówka USB-OTG i jakieś zasilanie. Trzeba tylko uważać, bo niektóre "oszczędnościowe" Wemosy nie mają diody zabezpieczającej USB, tak więc jeśli siedzą w jakimś zasilanym układzie trzeba się przed tym zabezpieczyć. Ja sobie zrobiłem kiedyś (do drukarki na Arduino) przelotkę USB z niepodłączonym zasilaniem - nadała się idealnie. Oczywiście najprostsze by było zainstalowanie arduino-cli na RPi - ale takie rozwiązanie nie jest zbyt szczęśliwe. Po pierwsze, trzeba by byłó jakoś synchronizować biblioteki i płytki na obu komputerach (tzn. na tym, na którym pracujemy i na zdalnym), po drugie nawet nie chcę myśleć ile trwałaby na RPi Zero W kompilacja programu, który kompiluje się na moim blaszaku 20 minut. Postanowiłem więc przegrać na RPi tylko to, co niezbędne do uploadu i napisać kilka prostych skryptów w Pythonie. Ale najpierw o samym Pyrduino. W konfiguratorze uploadu dochodzą trzy dodatkowe pola: user, host i serial. Pole user może być puste jeśli ssh jest skonfigurowany tak, że łączy się jako właściwy użytkownik. Wypełnienie pola serial może być zautomatyzowane (czyli "pokaż urządzenia" i kliknięcie właściwego). I tu uwaga: malinka powinna być skonfigurowana tak, aby logować się bez hasła (kluczem ssl)! Polecenie ardu przyjmuje nowe argumenty: ardu -rmt To polecenie przesyła skompilowany program na RPi i uruchamia funkcję uploadu do podłączonej płytki ardu [-r] [-b <prędkość>] -rterm To polecenie uruchamia prosty terminal serial. Prędkość to domyślnie 115200. Opcja -r uruchamia terminal poprzez wrapper readline (konieczna instalacja rlwrap na głównym komputerze) - z reguły wygodniejsze choć nie zawsze. Aby RPi dostał wszystko co mu potrzebne, należy: uruchomić skrypt pitar.py - utworzy on archiwum espdir.tgz zawierający skopiowane z hosta pliki umożliwiające upload do esp32 i/lub esp8266 przegrać archiwum na malinkę zalogować się na malinkę doinstalować python3-serial, usb.ids i socat (jeśli ich nie ma) rozpakować - najlepiej bezpośrednio w katalogu domowym, powinno co prawda działać w innym miejscu ale nie próbowałem wejść do utworzonego katalogu espdir i wykonać polecenie: ./mklink.sh Utworzą się dodatkowe softlinki w /usr/local/bin/ I to właściwie wszystko... jakieś pytanka? Oczywiście kody w załączniku: pyrduino2.tgz pyrduino2.tgz Edytowano 13 czerwca przez ethanak 1 Link do komentarza Share on other sites More sharing options...
Pomocna odpowiedź
Bądź aktywny - zaloguj się lub utwórz konto!
Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony
Utwórz konto w ~20 sekund!
Zarejestruj nowe konto, to proste!
Zarejestruj się »Zaloguj się
Posiadasz własne konto? Użyj go!
Zaloguj się »