Nie wiedziałem, że ESP32 jest takie tanie. A jak się dowiedziałem to sobie kupiłem. Co prawda nie mam za bardzo pomysłu co z nim zrobić ale się pobawię odkurzając podstawy programowania. Unikałem zawsze c bo te nawiasy mnie dobijały ale trzeba się poduczyć w czym pomaga Google.
#esp32
Około trzy tygodnie temu plułem na esp32 i zrobionego na nim SensorBoxa. Nadal czynię to pod kątem programistycznym. Sam projekt PCB też mocno bym poprawił
Udało mi się jednak uruchomić ten diwajs i, po wymianie jednego czujnika, ruszyło wszystko.
Przetwornica miała ustawione zbyt wysokie napięcie wyjściowe (4 V zamiast maksymalnie 3V3). Prawdopodobnie multimetr Marcina "lekko" przekłamuje.
Przez zbyt wysokie napięcie jeden czujnik raczej nie przeżył.
Do tego odwrotnie użyta była wtyczka do czujnika PM, tu musiałem tylko zamienić przewody żeby było zgodnie z dokumentacją.
Każdego dnia oddalamy się od programistycznego boga.
Dostałem niedziałający Sensorbox V2 do uruchomienia. Dokumentacja tego projektu jest, delikatnie mówiąc, amatorska. Programowanie... przez stronę www (wuteef?!). Troubleshooting ze strony dewelopera nie istnieje, od prawie roku, po aktualizacji esphome, urządzenie uruchamia się z migającym na biało ekranem. Rozwiązania wrzucane przez użytkowników w komentarzach nie działają, nikt też nie wrzuca działającej binarki, choć chwali się jak to jemu działa.
Ale to jest najlepsze: kompilacja firmware bez funkcji home assistant i komunikacji wifi, do odczytu danych z kilku czujników wewnętrznych i pokazaniu ich na LCD zajmuje... prawie godzinę!
Nie ma aktualnie czasu na nic, datalogger niedokończony, w pracy młyn, głowa pęka bo jakieś kłopoty z błędnikiem (lvl 40+), więc to dobry moment na rozpoczęcie nowego projektu komputerka do sterowania komory do owocowania grzybów.
W esp32 znaleziono backdoora i przedstawiają to jak coś bardzo poważnego.
I jest to spory problem bo wiem, że w Polsce i Niemczech ten mikrokontroler jest używany w energetyce.
Jestem ciekawy co zostanie postanowione. Espressif nie udostepnia całego kodu źródłowego na swoje uC. Nawet jeśli będzie jakiś hotfix to nikt poważny nie powinien używać tego w strategicznych obszarach. A więc machną ręką czy będzie wielka modernizacja?
Komendy do diagnostyki dostępne przez USB (czy inne transporty HCI). Więc nie jest to tak poważne - gdyby były dostępne przez Bluetooth to inna sprawa. Myślę, że to jest jedynie problem w niewielu zastosowaniach.
Napisałem libke pod #esp32, którą testowałem tylko na płytkach esp32 i esp32 s(3). Libka to multiframeworkowy wifiManager z paroma extra funkcjonalnościami. Nie mam na stanie płytek z z serii C jednak z tego co wiem to wifi, i serwer http obsługuje się identycznie jak na zwykłych esp-kah i esp-kach z serii S. Mógłby ktoś to potwierdzić albo zaprzeczyć? Readme będzie ładniej wyglądało jak usunę te "should work" z shieldów.
@Klopsztanga Jak znam życie z tymi tanimi płytkami, to problem będzie z dokumentacją. Co drugi pin GPIO będzie działał tak jak powinien, i żeby to w ogóle działało, będziesz musiał pohaczyć ze sobą kilka niekompatybilnych bibliotek.
Po tym, jak na jednej z tanich płytek musiałem brute forcem ustalać który PIN przekłada się na które oznaczenie (i czy w ogóle działa) stwierdziłem, że pierdzielę i następnym razem biorę RPI.
Kiedyś w pracy handlowcy narzekali na ekrany dotykowe w jednym z naszych produktów. Dorzuciłem więc własne kulki, które można było uruchomić tajną kombinacją w GUI.
Pograli, pobawili się i okazało się, że przestali narzekać na ekran dotykowy
Wstałem rano, wypiłem kawę i stwierdziłem, że skoro i tak kupiłem od razu dwa MSGEQ7, to trzeba zmontować stereo. Kilka chwil drutowania, później parę zmian w kodzie i cyk, można robić dyskotekę.
Muszę sobie kupić szpule odpowiednich drucików do breadboardów i samemu powycinać odpowiednie długości, bo z gotowców nie da się nic estetycznego ułożyć. Trzeba rzeźbić z tego, co się ma, ani to kolorami zgrupować, ani sensownie poprowadzić. A nie chce tego zamykać w pudełku, bo podoba mi się taka widoczna elektronika.
Ja wiem, że nic wielkiego, ale jaram się jak dziecko
Zawsze chciałem podpiąć sobie spectrum analyzer pod gramofon, bo po prostu lubię ten efekt. Ale nie na tyle, by kupować jakieś cudaki. Co innego samemu zbudować. Prosty układzik na MSGEQ7, teraz tylko dopracować, zamknąć w obudowie, zmienić ekran na większy, podpiąć i jakoś fajnie zsynchronizować listwę LED i zapraszam na dicho
Od jakiegoś czasu szukam sobie relaksującego hobby na zimę i wymyśliłem #programowanie. Przeszedłem od podstaw assemblera 6502 przez podstawy grafiki 2d i 3d, następnie podstawy pisania shaderów dochodząc do #arduino i #esp32 . Tu zdecydowanie zostanę na dłużej, bo zabawa jest przednia, a w domu już zaczynają się walać różne mikrokontrolery i układy. A i w pracy udało się wdrożyć banalny projekt. Polecam.
Z fajnych bajerów jest ESP-MESH czyli espki tworzą swoją sieć mesh i komunikują się bezpośrednio z pominięciem routera.
Też możesz sprawdzić ESP-HOME. Odbiega to trochę od programowania bo tutaj generujesz soft na podstawie konfiguracji. Używany do automatyzacji domu, współpracuje z popularnym Home Assistant. I masz gotowe OTA (programowanie przez wifi)
Udało mi się naprawić pare bugów i dodać do servera obsługę przez web socket. Dodalem funkcjonalność listowania dostępnych sieci wifi na stronce i aktualnie wygląda to jak na zdjeciu. Niestety się to nie ładuje po pierwszym wczytaniu strony a dopiero po kliknięciu przycisku "refresh". Problemem jest to że frameork twierdzi że podaje mu zły uchwyt do serwera i nie może znaleźć deskryptora soketu, który jest z nim powiązany. Dziwne ... Wiem, że w requeście, odpowiedzialny za inicjaliwoanie handshaku, który przychodzi od klienta(przeglądarki) jest uchwyt jakiegoś serwera ale zakładałem że jest to tem sam uchwyt, który został mi zwrócony jak tworzyłem instancje serwera? Czyżby to był bug frameworku ? Nie wiem. Dokumentacji do tego nie ma i zostaje mi tylko analiza kodu bibliotecznego
Następnymi krokami będą:
dodanie obsługi "custom parametrów" ( na wzór tego co oferuje wifiManager od tzapu)
minifikacja stronki ( ogólnie liba zajmuje ponad 1mb i musze to zoptymaliwoać pamięciowo ale na początek zaczne od tego)
dodanie logera na stronce ( taki bonus bo inne wifiManagery tego nie mają)
Jakie inne funkcjonalności moge jeszcze dodać ? Co ma konkurencja, lub czego nie ma a powinna mieć? Na koniec ankieta.
Zrobiłem libke do łączenia się z wifi na #esp32 . Jest to marna(narazie) podróba wifiManagera od tzapu. Zrobiłem ją tylko dlatego, że tamta działa tylko na arduino-esp32 a moja arduino-esp32 i na czysym espidf framweroku (oraz przez platformio). Narazie mam
Odpalanie wifi w trybie AP
Serer http ze stroną do podania loginu i hasła do wifi
Captive portal ( działa na linux i android, na innych platformach nie testowałem)
Zapis i odczy credentiali z pamięci Flash
Przejście do trubu STA lub AP_STA ( do wyboru przez uzytkownika)
Moje założenia to:
libka ma działać na zasadzie plug and play ( co jest trudne ze względu na kolejny punkt)
libka ma być niezależna od frameworku/IDE (nie ważne czy ktoś używa arduino, platformIO czy czystego espidf)
Pytanie:
Jakie dodatkowe funkcjonalności powinienem dodać ? Myślałem nad umożliwieniem dodawania przez użytkownika innych parametrów oprócz SSID i hasła do wifi do stronki i ich zapis. I jeszcze dodać na stonce logger. Czyli okienko gdzie bedą wyświetlać się logi z wykonywania programu bo czasami ktoś może nie mieć dostępu do portu szeregowego żeby je czytać jak urzadzenie gdzieś stoi.
@fitoplankton ma i korzystam. Mam ustawiony cpp17 żeby mieć optionale bez konieczności dodawania boosta. Pewnie pijesz do tego new i delete. Otóż funkcje frameworku są napisane w C a nie w cpp. To co widisz na screenie wyżej wygląda teraz tak jak poniżej.
Jak to jest rozwiązane w #arduino framework, że przed użyciem SIFFS nie trzeba tworzyć partycji spiffs za pomcą jakiś osobnych narzędzi ? Domyślam się że ardu robi jakąś statyczną analize kodu i jesli jest nagłówek od SPIFFS to automatycznie tworzy partycje ale to tylko moje domysły. Badał to ktoś? W espidf trzeba robić to ręcznie. Robie biblioteke pod espidf, która używa SPIFFS i jest to spora wada bo nie będzie działała na zasadzie plug and play. Jakieś pomysły jak to obejść ?
Rozebrałem dzisiaj jednorazówkę z żabki żeby zobaczyć jak to działa. Wynik widzicie na zdjęciu. Grzałką jest zwykły drut owinięty dookoła waty. Całość zasilana jest akumulatorem 3,7v o pojemności 1.81Wh z oznaczeniem PX 001-03. Akumulator ten można ładować co daje możliwość przerobienia tego papierosa na wielorazowego. Mój przestał działać jak napięcie spadło z 3.7 do 3v. Jednak to co w tym wszystkim najbardziej ciekawego to układ sterujący zasilaniem. Ma on oznaczenie CSC912D (w obudowie SOT23-5) i znajduje się po drugiej stronie tej małej płyteczki #pcb , którą oznaczyłem strzałką. Szukałem tego w Internecie i znalazłem tylko dwie wzmianki na ruskim i niemieckim forum( linki niżej). Wie ktoś co to za układ? Z tego co ruscy piszą to jest to układ na specjalne zamówienie, którego nie da się kupić ale jego odpowiednikiem jest LTC4054. (Ruscy piszą że to mikrofon który zbiera szum powietrza i załącza ogrzewanie). Ma on również funkcje komunikacji poprzez diode co jest często spotykane w elektronicznych papierosach. Mam jeszcze kilka modeli. Dajcie pioruna jak chcecie sekcje, żeby zobaczyć co tam siedzi.
Klient do mnie napisał że program się przestał kompilować. Okazało się że to przez ostatnią aktualizacje Blynka do wersji 1.3. Dodali czeka kompilacji który sprawdza czy zahardkodowano BLYNK_TEMPLATE_ID , BLYNK_TEMPLATE_NAME i od teraz nie mozna ustalać tych wartości podczas runtime ( nie żeby wcześniej było można ale przynajmniej tego nie sprawdzali i wszystko działało). Jak macie ten sam problem na zakomentujcie linijki ze zdjęcia w BlunkApi.h.
Btw nienawidzę tej liby. Jest koszmarnie zaprojektowana. Przypomina mi projekt grupowy robiony na odwal się.
Dużo rzeczy w embedded jest na odpierdol, byle szybciej, bez myślenia o przyszłości i najlepiej z użyciem przestarzałych technologii. Strasznie mnie to irytuje i jeśli kolejna moja praca to będzie rzeźba to się zacznę przebranżawiać