ESP32 + esptool.py, flaszowanie firmware micropythona (i nie tylko) za pomocą smartfona z OTG (nie tutorial)

orb777 · Marzec 3, 2025

Witam.

Ciekaw byłem, czy można w łatwy sposób zrobić to co w temacie, okazuje się, że tak, nawet na starym smartfonie (LG-M250). Metoda opisana w wiki termux-a u mnie nie zadziałała. W trybie OTG napięcie pod obciążeniem w M250 trochę "klęka", stąd lekko okrężna droga. Pewnie można też inaczej, tj. bez konwertera, zasilacza, podając 5V zmodyfikowanym przewodem USB, itd., ale akurat takie "klocki lego" miałem pod ręką:

- zrootowany android 8.1.0 + termux z doinstalowanymi pakietami: sudo, python3, pip3, pyserial, esptool, mpfshell (i pewnie z czymś jeszcze co było potrzebne)

- adapter OTG (ugreen) podłączany do telefonu

- konwerter waveshare (CH343G), w 8.1.0 wykrywany bezproblemowo

- przenośny "zasilacz" 3.3V

Pinologia jest prosta: 3.3V i GND z ESP32 podpięte pod "zasilacz", natomiast piny RX/TX/GND podłączone do konwertera waveshare. GPIO0 i GND spięte zworką (szary przewód) tylko na czas flaszowania firmware przez esptool, podczas "zwykłego" używania - nie. Najpierw włączam "zasilacz" (ESP32), następnie podłączam adapter OTG do telefonu, wtedy działa ok.

Zrzuty ekranu z termux-a po wgraniu firmware (konwerter widoczny jako port /dev/ttyACM0):

Tryb repl, czyli "konsola interaktywna" micropythona:

Prosty test (licznik):

W sklepie play można znaleźć inne apki o podobnym działaniu (esp32loader, esp32_flash), ale nie próbowałem. Przyzwyczajony jestem do konsoli i dodatkowych opcji esptool (np. backup firmware).

ethanak · Marzec 3, 2025

Z ciekawości: nie idzie podłączyć esp przez usb bezpośrednio do otg? Ew. podając 5v na esp z zasilacza a nie z telefonu?

orb777 · Marzec 3, 2025

@ethanak, w sumie próbowałem. CP2102 jest wykrywany, ale w termuxie nie pojawia się żaden nowy port w /dev, a ten który jest podany nie działa. Może coś źle robię. Jak będę mieć płytkę z CH340 to sprawdzę.

Sprawdziłem lolin32 lite (CH340C) bezpośrednio kablem. Też nie ma reakcji w /dev. Napięcie USB w normie (~4.95V przy ~13mA na luzie). Z zewnętrznym konwerterem port pokazuje się od razu.

lsusb wyświetla vid/pid CP2102, podobnie jak hwinfo:

Bus 001 Device 002: ID 10c4:ea60

dmesg również rejestruje:

Konwerter CP2102 w ESP32:
[72497.832890 / 03-04 22:19:01.700][0]  (0)[21106:kworker/0:0]usb 1-1: New USB device found, idVendor=10c4, idProduct=ea60
[72497.832952 / 03-04 22:19:01.700][0]  (0)[21106:kworker/0:0]usb 1-1: Product: CP2102 USB to UART Bridge Controller

Waveshare (CH343G): 
[73052.143620 / 03-04 22:28:16.010][0]  (0)[28241:kworker/0:0]usb 1-1: New USB device found, idVendor=1a86, idProduct=55d3
[73052.143694 / 03-04 22:28:16.010][0]  (0)[28241:kworker/0:0]usb 1-1: Product: USB Single Serial
[73052.151683 / 03-04 22:28:16.010][0]  (0)[28241:kworker/0:0]cdc_acm 1-1:1.0: ttyACM0: USB ACM device

Może brakuje odpowiedniego sterownika.

Edytowano Marzec 5, 2025 przez orb777

orb777 · Marzec 5, 2025

Popatrzyłem trochę z ciekawości, chociaż przez SSH, bo na dłuższą metę z podpiętym OTG niewygodnie. Ze źródeł kernela w tej samej wersji pod andka, skompilowałem sterownik cp210x, jednak próba załadowania wysypała się bodaj brakiem odpowiedniego podpisu (?)

Jako amator bez "custom recovery" nie będę dalej grzebać. W tej konfiguracji działają być może tylko konwertery, które obsługują "CDC" i taki sterownik jest ładowany. Wg internetów CP2102 i CH340C nie ma tego trybu. Może na telefonach z nowszym andkiem i innymi sterownikami wygląda to lepiej.

Poszukałem ESP32-S3, które również ma konwerter CH343 oznaczony jako "WCH 343PC20". Podłączam bezpośrednio pod adapter OTG - port "/dev/ttyACM0" pojawia się od razu.

Edytowano Marzec 5, 2025 przez orb777

orb777 · Marzec 20, 2025

Okazało się, że jest możliwość w prosty sposób odpalić CP2102 i CH340C, tak, żeby esptool "widział" płytkę podłączoną bezpośrednio kablem USB. Bez dodatkowego konwertera, grzebania przy kernelu, kompilowania sterowników, itd. Sprawę rozwiązuje apka "TCPUART" (TCPUART_1.3.5.zip).

Czyli:

1. Tak jak wcześniej, podłączamy: "smartfon -> przejściówka OTG -> kabel USB -> ESP32" (odpalamy płytkę w trybie bootloader-a, tj. przytrzymujemy przycisk "BOOT" podczas uruchamiania albo dajemy zworkę pomiędzy GPIO0 i GND)

2. Odpalamy termux-a i dodatkowo instalujemy pakiet "socat" (komenda: "pkg i socat").

3. Konfigurujemy TCPUART, przydzielamy uprawnienia do portu USB. Przykładowo łączymy się z CP2102 i uruchamiamy serwer tcp na porcie 8888:

4. Tworzymy lokalnie wirtualny port szeregowy o nazwie np. "ttyESP32" (dla czytelności w sposób "blokujący", bez "screen", "&", itd.):

socat pty,raw,link=./ttyESP32 tcp:127.0.0.1:8888

5. Otwieramy nowy terminal ("new session") przeciągając ekran od lewej:

6. Odpalamy w nim esptool łącząc się konwerterem na płytce za pomocą portu wirtualnego (jak widać w tym przypadku jest to dowiązanie do "/dev/pts/17"):

sudo esptool.py --chip esp32 --before no_reset --after no_reset --port ./ttyESP32 chip_id

Edytowano Marzec 20, 2025 przez orb777

orb777 · Marzec 22, 2025

Zapiszę, gdybym zapomniał. TCPUART sporo ułatwia, ale nie wszystko śmiga od razu tak jak powinno. Do zarządzania plikami w micropythonie używam 3 programów: ampy, mpfshell, rshell. Ostatni jest najbardziej rozbudowany i dopracowany. Python rozpoznaje andka jako "linux", jednak ten nie korzysta z "udev", więc podczas uruchamiania rshell-a jest błąd:

Zmieniłem lekko "main.py", żeby pominąć import i użycie "pyudev" (USE_AUTOCONNECT = False)

Tylko tyle i aż tyle:

Edytowano Marzec 22, 2025 przez orb777

orb777 · Marzec 27, 2025

Dalej męczę temat "rshell". Tym razem płytki z chipem od raspberry + micropython v1.24.1. Komunikacja przez port "ttyACM0", więc apka "TCPUART" niepotrzebna.

Chciałem, żeby edytor quickedit powiązany był bezpośrednio z rshell, a pliki po zapisaniu "automagicznie" wrzucały się na płytkę. "Konsolowe" programy typu vim, nano, joe, itd., działają pod tym względem ok (parametr --editor), ale "apki" już tak łatwo nie chcą.

Pomógł prosty skrypt, chociaż nie mam zbytnio pomysłu jak go "cwano zablokować", żeby kończył się wraz z zamknięciem quickedit. Parametry "blokujące" dla komendy "am" u mnie nie działają (obojętnie w której wersji "am", systemowej lub termux-owej), skrypt wykonuje się dalej, co wiąże się z usunięciem przez rshell pliku tymczasowego zanim zdąży otworzyć go quickedit. Żeby temu przeciwdziałać, co 2 sekundy sprawdzany jest "pid" quickedit, na tej podstawie przerywana jest pętla, po czym sterowanie wraca do rshell.

Ogólnie daje to radę, ale może zna ktoś lepsze rozwiązanie?

//

Zmieniłem odrobinę skrypt, tak jest chyba optymalniej.

#!/data/data/com.termux/files/usr/bin/sh
if [ -z "${1}" ]; then echo "[BŁĄD]: brak podanej nazwy pliku"; exit 1; fi
if [ ! -f "${1}" ]; then echo "[BŁĄD]: brak pliku \"${1}\""; exit 2; fi
if [ ! -w "${1}" ]; then echo "[BŁĄD]: nie można zapisać do pliku \"${1}\""; exit 3; fi

APK="com.rhmsoft.edit"
if am start -n "${APK}/${APK}.activity.MainActivity" -d "file://`realpath -q ${1}`" > /dev/null 2>&1; then sudo sh -c "while pidof -s -q ${APK}; do sleep 2; done"; else echo "[BŁĄD]: nie można uruchomić \"${APK}\""; fi

Edytowano Marzec 28, 2025 przez orb777

orb777 · Marzec 30, 2025

Ciąg dalszy radosnej twórczości amatora. Dodałem do skryptu "quickedit" możliwość tworzenia nowych plików w rshell podając np. "edit nowy.py". Korzystam z tego również bezpośrednio w termux-ie.

#!/data/data/com.termux/files/usr/bin/sh

if [ -z "${1}" ]; then echo "[BŁĄD]: podaj nazwę pliku"; exit 1; fi
FILE="`realpath -q ${1}`"
if [ ! -f "${FILE}" ]; then touch "${FILE}"; IS_NEW="true"; fi

APK="com.rhmsoft.edit"

STAT_A=`stat -c %Y "${FILE}"`
if am start -n "${APK}/${APK}.activity.MainActivity" -d "file://${FILE}" > /dev/null 2>&1; then 
	sudo sh -c "while pidof -s -q ${APK}; do sleep 2; done" 
else
	echo "[BŁĄD]: nie można uruchomić \"${APK}\""
fi
STAT_B=`stat -c %Y "${FILE}"`

if [ -n "${IS_NEW}" ] && [ "${STAT_A}" -eq "${STAT_B}" ]; then rm -f "${FILE}"; fi

Kolejna rzecz - montowanie na andku "wirtualnego" flash-a RP, tak, żeby można było wrzucić tam plik firmware w formacie .uf2. Próbowałem kilku menedżerów plików, w tym "wynalazki": exFAT/NTFS for USB by Paragon, MLUSB Mounter - File Manager i żaden sobie z tym nie poradził. Pomogło stare, dobre "mount/umount". Powstał więc prosty skrypt ("raspberry-fw-flash"), który "wykrywa" i montuje RP uruchomione w trybie bootloadera, po czym wrzuca firmware. Wersja skryptu "zero", więc "działa dopóki nie wyłoży się, najwyżej poprawię". Zapis "rshell-acm" to alias komendy rshell z dodatkowymi parametrami. Oczywiście nic nie stoi na przeszkodzie, żeby zrobić aliasy komend i wywoływać "mount/umount" ręcznie, jednak wolałem mieć "prosto i automagicznie".

W skrypcie używam zapisu "if [...]; else; fi", ale równie dobrze można "&&" i "||". Pierwszy jest chyba bardziej czytelny. Testowałem również na linux-ie, tyle, że trzeba podmienić "shebang" (pierwszą linijkę) np. na "#!/usr/bin/env bash".

#!/data/data/com.termux/files/usr/bin/bash

info(){
	case "${1}" in
		"" | "--help" | "-h" ) echo -e "Użycie: `basename ${0}` <plik_firmware.uf2>\n\n[RP w trybie bootloadera]:\nPrzytrzymaj chwilę przycisk BOOT[SEL] podczas [re]startu."; exit 0 ;;
	esac
	if ! [[ -f "${1}" && "${1}" == *.[uU][fF]2 ]]; then echo "[BŁĄD]: podaj prawidłowy plik firmware w formacie \"uf2\""; exit 1; fi
	if [[ "`xxd -ps -l 8 ${1}`" != "5546320a57515d9e" ]]; then echo "[BŁĄD]: plik \"${1}\" posiada niewłaściwy nagłówek \"uf2\""; exit 1; fi
}

depends(){
	declare -A app=( ["blkid"]="blk-utils" ["findmnt"]="util-linux" ["sudo"]="tsu" ["xxd"]="xxd" )
	for k in "${!app[@]}"; do if command -v "${k}" > /dev/null 2>&1; then unset "app[$k]"; fi; done
	if [ ${#app[@]} -gt 0 ]; then echo -e "[BŁĄD]: brak pakietów (${!app[@]}), aby zainstalować wpisz: \"pkg i ${app[@]}\""; exit 1; fi
	unset app
}

set_vars(){
	FW_FILE="`realpath -q ${1}`"
	TMPDIR="${TMPDIR:-/tmp}"
	RP_DIR="${TMPDIR}/raspberry_firmware_flash"
}

find_rp(){
	echo -n ">> wykrywam RP w trybie bootloadera ... "
	RP_DEV="`sudo blkid -l -n vfat -o device -t LABEL=RPI-RP2`"
	if [ -z "${RP_DEV}" ]; then echo "[BŁĄD]"; exit 1; else echo -e "[OK]\n>> RP widoczne jako \"${RP_DEV}\""; fi
}

mount_rp(){
	if ! check_mnt; then
		mkdir_rp
		echo -n ">> montuję RP ... "
		if ! sudo mount -t vfat "${RP_DEV}" "${RP_DIR}"; then echo "[BŁĄD]"; exit 1; else echo "[OK]"; fi
	else
		echo ">> katalog RP jest już zamontowany, nie montuję ponownie ..."
	fi
}

umount_rp(){
	echo -n ">> odmontowuję ... "; sudo umount -q "${RP_DIR}" > /dev/null 2>&1
	if [ $? -eq 0 ]; then echo "[OK]"; else echo "[BŁĄD]"; fi
}

copy_firmware(){
	echo -n ">> kopiuję firmware ... "
	sudo cp -f "${FW_FILE}" "${RP_DIR}/" > /dev/null 2>&1
	if [ $? -eq 0 ]; then echo "[OK]"; else echo "[BŁĄD]"; fi
}

mkdir_rp(){
	mkdir -p "${RP_DIR}" > /dev/null 2>&1
}

check_mnt(){
	if [ -z "${RP_DEV}" ]; then return 1; else findmnt "${RP_DEV}"; fi > /dev/null 2>&1
}

clean(){
	rm -fr "${RP_DIR}" > /dev/null 2>&1
}

on_exit(){
	if check_mnt; then umount_rp; clean; fi
}

test_sudo(){
	if [ `sudo id -u` -ne 0 ]; then echo "[BŁĄD]: \"sudo\" nie działa poprawnie"; exit 1; fi
}

trap on_exit EXIT
depends
info "${1}"
test_sudo
set_vars "${1}"
find_rp
mount_rp
copy_firmware

Edytowano Marzec 31, 2025 przez orb777
nagłówek uf2

orb777 · 14 marca

W związku z aktualizacją do pythona "3.13" pojawiły się <pewne problemy>. Python w poprzednich wersjach zgłaszał androida jako "linux", aktualnie już jako "android".

Nieprzystosowane programy/biblioteki (np. esptool, rshell, mpremote) wykładają się na tym, co wygląda mniej więcej tak:

Jednak, można to naprawić, przynajmniej na 3 sposoby.

=== Pierwszy sposób ===

Zaktualizować bibliotekę "pyserial" mając nadzieję, że już to naprawiono (nie żart! hehe) i pominąć kolejne metody.

pip install --upgrade pyserial

=== Drugi sposób (najbardziej uniwersalny) ===

Dodać odpowiedni wpis w pliku, który rzuca wyjątek "ImportError" (powinno działać aż do ponownej aktualizacji biblioteki)

  File "/data/data/com.termux/files/usr/lib/python3.13/site-packages/serial/tools/list_ports_posix.py", line 119, in <module>
    raise ImportError("Sorry: no implementation for your platform ('{}') available".format(os.name))

1. Otwieramy "list_ports_posix.py" w edytorze tekstowym (dla przykładu używam "micro"; jeżeli nie ma, instalujemy: "pkg i micro")

micro "/data/data/com.termux/files/usr/lib/python3.13/site-packages/serial/tools/list_ports_posix.py"

2. Dodajemy kod (oznaczony blokiem "#dodane"), pamiętając o "python-owych wcięciach", następnie zapisujemy :

Kod:

# dodane    
if plat[:7] == 'android':
    from serial.tools.list_ports_linux import comports
# dodane

=== Trzeci sposób ===

Modyfikacja "launcherów" programów, tutaj np. w "mpremote":

1. Żeby nie szukać pakietu, wpisujemy ("command -v" lub "which", $() lub ``, zależnie od preferencji)

micro "$(command -v mpremote)"

2. Dodajemy tam wpis (sys.platform = 'linux') i zapisujemy plik.

Python w wersji "3.13" usunął także bibliotekę "telnetlib", z której korzysta choćby "mpfshell". @ethanak wspomniał, że jest na pypi i faktycznie, pod lekko zmienioną nazwą (przynajmniej w dwóch kopiach).

https://pypi.org/project/standard-telnetlib/

https://pypi.org/project/telnetlib-313-and-up/

<<< mpremote >>>

Kolejną rzeczą do poprawki jest wspomniane wcześniej "mpremote" (dokumentacja), czyli całkiem fajne narzędzie do micropython-a. Działa bez root-a, współpracuje z "tcpuart". Oprócz podstawowych funkcji posiada także tryb "repl". Żeby nie wpisywać komend za każdym razem, przyda się "opakować" je w prosty skrypt. Za jakiś czas wrócę do tego tematu, a także do poprawionego "wrappera" dla "quickedit". Na razie można posłużyć się aliasem.

Poniższy alias ustawia edytor na "micro" i łączy nas z płytką:

alias mpr='export EDITOR="micro"; mpremote connect "socket://localhost:8888"'

Przykładowo wyświetlamy zawartość pamięci flash uC w postaci drzewka:

mpr fs tree

<<< UWAGA >>>

Żeby tryb "repl" w "mpremote" działał, potrzebna jest poprawka w pliku "/data/data/com.termux/files/usr/lib/python3.13/site-packages/mpremote/console.py", inaczej prawdopodobnie zobaczymy taki błąd:

Poprawka:

1. Otwieramy plik "console.py":

micro "/data/data/com.termux/files/usr/lib/python3.13/site-packages/mpremote/console.py"

2. Szukamy tam widocznej sekcji (to co trzeba dopisać oznaczyłem blokiem komentarzy "#dodane"):

Kod całej metody "waitchar" klasy "ConsolePosix" po modyfikacji (dla wyróżnienia specjalnie po polsku):

    def waitchar(self, pyb_serial):
        # TODO pyb_serial might not have fd
        # select.select([self.infd, pyb_serial.fd], [], [])
        
        # dodane
        poprawka = pyb_serial.fileno() if getattr(pyb_serial, "fd", None) is None and hasattr(pyb_serial, "fileno") else pyb_serial.fd
        select.select([self.infd, poprawka], [], [])
        # dodane

Po poprawce jest ok.

Aby "wstrzelić się" w uC, na którym działa już kod uPy w pętli, trzeba nacisnąć przycisk RST/EN na płytce, następnie szybko klepnąć "enter" w termux-ie, np. z komendą "mpr fs ls". Przerywa to wykonywanie pętli programu uPy. Nawet w "repl" łatwiej wejść w ten sposób, niż wpisując od razu "mpr repl". Przynajmniej u mnie.

<<< Wisienka na torcie (chociaż nie nowość) >>>

Okazało się, że "esptool" jest w stanie pracować z gniazdami, czyli z "tcpuart". Krótko mówiąc: flaszowanie firmware w ten sposób nie wymaga posiadania root-a, dzięki "tcpuart" nie musimy też podawać portu (tty). W esp32 trzeba pamiętać, żeby dać zworkę pomiędzy "gpio0 i gnd".

Aliasem ułatwiamy sobie robotę:

alias esptool-tcpuart='esptool --chip esp32 --before no-reset --after no-reset --port "socket://localhost:8888"'

Przykładowe użycie:

esptool-tcpuart chip-id

<<< Na koniec: o co chodzi z "aliasami" w bash-u? >>>

W termux-ie, domyślnie są nieaktywne. Aby zaczęły działać, po kolei wykonujemy komendy widoczne na pierwszym screenie i dodajemy dwie linie (32 i 33) do pliku "bash.bashrc", przeładowujemy za pomocą "source" lub restartujemy terminal. Po zmianie zawartości w ".bash_aliases" także przeładowujemy ten plik lub restartujemy terminal.

Edycja ".bash_aliases" / przykładowa zawartość:

Wszystko powyższe nadal dotyczy sprzętu, o którym wspomniałem w pierwszym wpisie. Zmieniła się natomiast wersja termux-a i pythona. Nie mam najmniejszego pojęcia, czy zadziała to na nowszym androidzie, ponieważ z wersji na wersję "zwykły" użytkownik tego systemu może coraz mniej. Aktualnie uC podłączam do hub-a usb zasilanego z powerbanku, a hub do smartfona przez otg. Także powerbank zasila uC.

Kuniec opowieści. Jak pokręciłem coś w opisie, wtedy poprawię, na razie "wydaje się być ok".

W załączniku (termux-konfig.zip) wrzucam lekko zmodyfikowany konfig termux-a, który domyślnie znajduje się w "$HOME/.termux".

Zmiany to:

- jedna linia dodatkowych klawiszy (zamiast dwóch)

- kolory, wyłączenie wibracji

- "allow-external-apps" ustawione pod obsługę zewnętrznych apek (można wyłączyć, jeżeli nie integrujemy termux-a z innymi aplikacjami)

Nie rozwijaj tego:

Jeśli dotrwałeś do końca nudziarstwa i właśnie czytasz te 3 kropki ... to niestety nie zwrócę ci cennych minut życia, ale ... jesteś prawdziwym twardzielem!

Edytowano 16 marca przez orb777

orb777 · 17 marca

Niestety nie udało się uruchomić esptool z esp8266 przez "tcpuart", wywala błąd (nodemcu v3, d1 mini; CH340C). "Normalnie" (CH343G; /dev/ACM0 + root) flaszowanie esptool-em idzie bez problemu. Połączenie bezpośrednie przez otg i bez roota też działa, da się gadać w "repl" zarówno w "apko-terminalu", jak i telnet/netcat + tcpuart. Także esp8266 pogadać w ten sposób lubi, ale łyknąć firmware już nie.

Ciekawe, czy za "tcpuart" stoi [ta biblioteka], tak jak za wieloma innymi apkami. Skrypt "termux-usb" przydziela niby tymczasowe uprawnienia do urządzenia usb, zwracając deskryptor, ale nie wiem na razie jak to wykorzystać.

Edytowano 17 marca przez orb777

orb777 · 30 marca

https://github.com/jeelabs/esp-link

Ogólnie żadne to odkrycie, ale powyższe narzędzie pozwala obejść problem z tcpuart. Tworzy most tcp-uart (wifi) na esp8266, więc nie trzeba podłączać nic do telefonu. Przykładowo w "presets" ustawiłem pinologię "esp-bridge". Jeżeli esp-link nie chce odpalić hotspota na naszym ustawieniu, wtedy płytkę docelową zasilamy już po starcie mostu.

Podłączenie: płytka źródłowa ("nodemcu v3" z esp-link) -> docelowa ("nodemcu v3"). Dla bezpieczeństwa można zastosować rezystory/diody na liniach. Ja podłączyłem "na Jana", bo jakoś tak wyszło, wiadomo.

Vin -> Vin
GND -> GND
TX -> RX
RX -> TX
GPIO12 (Reset) -> EN
GPIO13 (ISP/Flash) -> GPIO0 (pin "D3")

Rezultat: port 2323, baud domyślny (115200), automatycznie wprowadza uC w tryb bootloader-a, "dogaduje się".

Zmiana baud na 460800. Przy użyciu "socket" skazana na niepowodzenie (+ typowy komunikat o błędnej częstotliwości kwarcu):

W związku z powyższym próbujemy dogadać się za pomocą protokołu "rfc2217", niestety trochę kiszka (albo robię coś źle?):

Po ustawieniu w opcjach konsoli (baud=115200) możemy pogadać z repl uPy (nc/mpremote). Esp-link wypluwa na dzień dobry komunikat do konsoli, więc w repl uPy dostajemy info o nierozpoznanej komendzie.

Ogólnie działa. Szkoda tylko, że nie udało się dogadać przez rfc2217 na wyższym baud, wtedy można by szybciej wgrywać firmware. Oczywiście w ramach rozsądku, jako, że transmisja idzie przez gniazda i w "eter".

Na koniec, flaszowanie esp-link na "nodemcu v3" (metoda podana [tu]). Po drobnym update dla wersji 3.0.14 (linux, port: /dev/ttyUSB0):

curl -L http://s3.voneicken.com/esp-link/esp-link-v3.0.14-g963ffbb.tgz | tar -xzf - && cd esp-link-v3.0.14-g963ffbb && esptool --port /dev/ttyUSB0 --chip auto erase-flash && esptool --port /dev/ttyUSB0 --chip auto --baud 230400 write-flash --flash-size=detect --flash-freq 80m 0x00000 boot_v1.6.bin 0x1000 user1.bin 0x3FC000 esp_init_data_default.bin 0x3FE000 blank.bin

Edytowano 30 marca przez orb777

orb777 · 16 kwietnia

Kolejny pomysł dla mobilków, o którym wspomniał @ethanak - "Raspberry Pi Zero". Wybrałem wersję 4-rdzeniową (Zero 2W). Zastanawiałem się też nad "Orange Pi Zero 2W" w wyższej cenie, jednak do terminala wystarczy to co jest. Przydatna może być też dedykowana aluminiowa obudowa, która (sądząc po opiniach) dosyć dobrze odprowadza ciepło z chip-u. Na swoją czekam, dokupiłem oddzielnie. Spotkałem się z opiniami, że tłumi nieco sygnał wifi, okaże się jak przyjdzie.

Testowo, za pomocą "Raspberry Pi Imager" zainstalowałem "chudego" Debiana - "DietPi". Dostępny jest też jeszcze chudszy "Alpine Linux", który nie zapisuje automatycznie zmian z sesji. Przetestuję go kiedyś, wydaje się być fajną opcją po uprzednim skonfigurowaniu środowiska, jako, że z ramdysków w linuxie korzystam od dawna.

Jeżeli obsługujemy DietPi tylko przez ssh, przed pierwszym uruchomieniem warto zajrzeć na kartę do plików konfiguracyjnych "dietpi.txt" i "dietpi-wifi.txt", żeby skonfigurować m.in. sieć. Python, vsftpd (ftp serwer), esptool, itd., wszystko działa ok. Duży plus za to, że mamy fizyczne połączenie przez usb, natomiast przez wifu (ssh) tylko ekran i klawiaturę z andka (termux-a). Zużycie energii podczas normalnej pracy porównywalne z esp32 z włączonym wifi, także fajna sprawa, na powerbanku trochę pociągnie.

Jak na razie jest to najlepsza opcja pod "mobilne programowanie uC w terminalu" z jaką spotkałem się.