Przeszukaj forum

https://botland.com.pl/wyswietlacze-do-arduino/4464-wyswietlacz-dotykowy-lcd-tft-rev-21-28-320x240px-spi-z-czytnikiem-microsd-shield-dla-arduino-waveshare-10684-5904422352608.html?fbclid=IwAR2Hht_LptyxYgvWfRCcs2hXsaxTBfCIVZZ_2bvxIhDw3aLOmWfBDs7vRUw Witam, Chciałbym zapytać czy ktoś może pracował z tym wyświetlaczem i podpinał go do ESP 32? Bo nie wiem czy są gotowe biblioteki współpracujące z tym mikrokontrolerem a wyświetlaczem, (które działają) Ewentualnie czy ktoś, może mi podpowiedzieć jakieś dostępne alternatywy bo na ekranie dotykowym mi nie zależy, tylko nie na wielkości.

Dzisiaj znów coś software-only: biblioteczka do prostej komunikacji UDP, taka po prostu konsola udp. Działa na obu ESP. Na pececie do komunikacji można użyć netcata (Linux, cygwin, pewnie Mac też), załączonego programu ardumon.py (Linux), i prawdopodobnie Ncat (Windows, nie mam jak sprawdzić). Biblioteczka jeszcze nie skończona, ale obiecałem koledze @SOYER że wrzucę 🙂 Można zacząć testować ESPUdpConsole.zip - feedback mile widziany.

Ten artykuł jest częścią serii "Tworzenie interfejsu sieciowego z wykorzystaniem ESP" #1 - część 1 (właśnie to czytasz) #2 - część 2 ESP32 czy też ESP8266 na dobre już zagościło w wielu warsztatach domowych majsterkowiczów. Większość obecnych projektów z wykorzystaniem ESP skupia się wokół dorzucenia do niego garści czujników, podłączenia do baterii i wybudzania go od czasu do czasu, aby wysłać dane o wykonanych pomiarach do naszego serwera. Czasem zdarza się, że nasze urządzenie pobiera pewne dane z zewnątrz i je wykorzystuje, np. budzik czas z serwera NTP, czy stacja pogodowa, informacje o pogodzie z wybranego serwisu. Co w sytuacji kiedy chcemy kontrolować nasze urządzenie lub obserwować jego stan z poziomu przeglądarki, a nie posiadamy Raspberry Pi, czy innej opcji, na której moglibyśmy mieć własny serwer? Co jeżeli zastosowanie dodatkowego serwera jest po prostu nieadekwatne do naszego celu? W tym artykule postaram się: omówić najpopularniejsze rozwiązania pokazać jak uruchomić serwer www ESP32 stworzyć prostą stronę www do naszych zadań wykonać interakcje strona-ESP w postaci: kontroli portu GPIO wyświetlanie wyniku pomiaru z ADC pobieranie pliku z pamięci ESP/karty SD Ten artykuł bierze udział w naszym konkursie! 🔥 Na zwycięzców czekają karty podarunkowe Allegro, m.in.: 2000 zł, 1000 zł i 500 zł. Potrafisz napisać podobny poradnik? Opublikuj go na forum i zgłoś się do konkursu! Czekamy na ciekawe teksty związane z elektroniką i programowaniem. Sprawdź szczegóły » Wszystkie powyższe rzeczy postaram się zobrazować w jak najprostszy i przejrzysty sposób. Poruszany temat jest niewątpliwie bardzo złożony i niestety nie jest możliwe aby wszystkie informacje zawrzeć w jednym artykule. Temat wymaga zarówno znajomość obsługi samego ESP, HTML, JavaScriptu czy też CSS, zaś znajomość protokołów sieciowych również byłaby mile widziana. Tutaj będą jedynie ukazane podstawy jak to wszystko ze sobą połączyć. Pokazane metody z pewnością nie będą należeć do najbardziej optymalnych rozwiązań, mają jedynie na celu ukazanie koncepcji i zachęcenia do dalszej analizy tego zagadnienia. Wszystkie kody będą skomentowane. W treści będę również odsyłał do dodatkowych materiałów, które dokładniej opisują poszczególne zagadnienia oraz tam gdzie można zdobyć więcej wartościowych informacji. Ale w jakim celu? Część z osób może zadać pytanie po co uruchamiać serwer na ESP, wiąże się to z dużym poborem energii, pomiary najlepiej z wielu czujników wysyłać w jedno miejsce, to dużo pracy itd. Inni zaś, od razu stwierdzą, że to jest to czego oni potrzebują. Jako że nie widzę większego sensu pisania długich wywodów na temat dlaczego warto, dlaczego nie, kiedy tak, kiedy nie. Przedstawię poniżej dwa praktyczne przykłady i możliwości takich realizacji które pozwolą samemu ocenić te aspekty. Pierwszym przykładem jest zdalny interfejs drukarki 3D. Dzięki niemu możemy zdalnie uruchomić drukarkę, wysyłać do niej pliki, uruchamiać druk, obserwować parametry druku, dostosowywać je, konfigurować drukarkę i wiele innych. Zostało to zrealizowane na ESP8266 i projekt jest dostępny pod tymi linkami Duet WiFi Server oraz Duet Web Control Drugi przykład jest to interfejs do sterowania lampką/oświetleniem LED. Z poziomu przeglądarki możemy ustawiać różne efekty świetlne, barwę, jasność, konfigurować urządzenie. Więcej o tym projekcie można dowiedzieć się tutaj Aircookie WLED Co będzie nam potrzebne? Podstawowa znajomość platformy ESP oraz programowania w Arduino w tym obsługa SPIFFS lub kart SD Płytka z ESP32 (wszystko powinno być kompatybilne z ESP8266) Zainstalowana biblioteka Async Web Server Dodatkowo: Znajomość języka angielskiego – dodatkowe odnośniki Płytka stykowa, potencjometr, fotorezystor czy cokolwiek sobie wymyślicie aby urozmaicić sobie temat 🙂 Zrozumienie tematu również ułatwi znajomość podstaw HTML oraz JavaScriptu. Jako że wymagane są już podstawowe umiejętności odnośnie obsługi ESP oraz Arduino, pominę kwestie instalacji biblioteki, omówienia zagadnień struktury programu czy też obsługi peryferiów. Z czym to się je? Podstawowa koncepcja naszego projektu opiera się na tym, iż na ESP uruchamiamy serwer, który na zapytanie klienta (klient czyli nas - naszej przeglądarki) zwraca odpowiednie pliki lub wykonuje pewne operacje. W ten sposób możemy poprosić ESP aby zwrócił nam plik HTML zawierający naszą stronę, przeglądarka ją odbierze, a my będziemy się mogli cieszyć widokiem naszej witryny. W ten sposób możemy wyróżnić pierwszy ze sposobów interakcji z naszym ESP, czyli z wykorzystaniem metod HTTP. W uproszczeniu, metody są to pewnego rodzaju „komunikaty” czego oczekujemy od naszego serwera. Przykładowo, wysyłamy zapytanie „GET” – oznacza że chcemy coś od serwera i ma on nam to dać, zapytanie „POST” – oznacza że chcemy coś dać od siebie. Każde nasze zapytanie będzie skutkować odpowiedzią (lub jej brakiem 🙂 ). Odpowiedzi posiadają swoje kody, które mają różne znaczenie – to daje nam dodatkowe możliwości interakcji. Wiedząc co oznacza dany kod możemy przykładowo stwierdzać czy dostaliśmy odpowiedź, czy wyświetlić jakiś błąd, lub stwierdzić że coś nie istnieje (każdemu znane 404). Najprostszym użyciem tych zapytań jest po prostu wykorzystanie odpowiednich struktur w HTML z stosownymi atrybutami. Metodę „POST” możemy wykorzystać przy tworzeniu formularza. Wadą tego rozwiązania jest fakt tego iż będzie to skutkować przeładowaniem strony przy każdej tego typu akcji. Inną opcją jest wykorzystanie pomocy Java Scriptu który będzie służył jako nasza „trzecia ręka” wykonująca te operacje w tle. Rozwiązanie to nazywa się AJAX (z angielskiego Asynchronus JavaScript and XML) i na nim się głównie skupimy w tym artykule. Drugą powszechną opcją jest skorzystanie z WebSocket. Jest to sposób ciągłej komunikacji między klientem a serwerem. Polega ona na nawiązaniu „kontaktu” z serwerem i zapytaniem go czy jest chętny na „pogawędkę”. Metoda ta idealnie się nadaje do wymiany ciągów informacji na żywo. Przykładowo potrzebujemy ciągłego odczytu z przetwornika ADC – można stwierdzić „wirtualny port szeregowy”. Oczywiście moglibyśmy zrealizować to samo zadanie z wykorzystaniem wcześniej wspomnianych metod, ale wykorzystanie metody HTTP wiąże się z całym procesem, wysłania zapytania, otrzymania odpowiedzi, co w skali procesora trwa wieki (np. jedno zapytanie kilkadziesiąt – set ms). Tutaj nie mamy tego problemu, gdyż nasze połączenie ciągle trwa i sobie rozmawiamy. W przypadku gdy nie zależy nam na ciągłym podglądzie (np. odświeżanie informacji raz na pół minuty) możemy spokojnie zadowolić się wykorzystaniem AJAX i metod HTTP. Ponadto warto nadmienić iż korzystanie z WebSocketów jest zarówno korzystne dla serwera jak i klienta ze względu na minimalną ilość przesyłanych danych (ograniczenie tego co jest nam w rzeczywistości zbędne). No to zaczynamy! Na wstępie warto nadmienić że pracujemy wewnątrz sieci lokalnej. Jeżeli połączymy się z naszym WiFi, inne urządzenia z tej samej sieci będą miały dostęp do naszego serwera. Bez stosownej konfiguracji sieci (jak i czasem ograniczeń narzuconych przez naszego dostawcę internetowego) nie będziemy mieć dostępu do naszego urządzenia z dowolnego miejsca na świecie. Na początek zacznijmy od tego czym jest nasza biblioteka i dlaczego ona. Otóż umożliwia ona komunikację asynchroniczną, co pozwala nam na posiadanie więcej niż jednego połączenia w danej chwili i działa poza pętlą loop(). Aby się nie rozpisywać na temat innych zalet i możliwości zainteresowanych dogłębną analizą odeślę tutaj. Uwaga dla użytkowników ESP8266! Biblioteka od obsługi WiFi definiuje się jako: #include <ESP8266WiFi.h> Zaś obsługa SPIFFS: #include <FS.h> Ponadto w poniższej pętli while() potrzebne jest opóźnienie, aby zapobiec uruchamianiu się watchdoga while (WiFi.status() != WL_CONNECTED){ delay(1000); } Powyższe uwagi będą zawarte w komentarzach kodów. Uruchamiamy serwer! #include <Arduino.h> #include <WiFi.h> //ESP8266 //#include <ESP8266WiFi.h> #include <SPIFFS.h> //ESP8266 //#include <FS.h> #include <ESPAsyncWebServer.h> #define SSID "nazwa sieci" #define PASS "hasło sieci" AsyncWebServer serwer(80); //utwórzmy obiekt serwera na porcie 80 void setup() { Serial.begin(115200); //zainicjujmy port szeregowy WiFi.begin(SSID, PASS); //połącz z naszą siecią wifi while (WiFi.status() != WL_CONNECTED){ //poczekajmy aż ESP połączy się z naszą seicią //delay(1000); //dla ESP8266 } Serial.printf("\nAdres IP:"); Serial.println(WiFi.localIP()); //wypisz adres IP naszego ESP przez port szeregowy //tutaj odbywa sie obsługa zapytań serwer.on("/", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/" typu GET, request->send_P(200, "text/plain", "Witaj! :)"); //odpowiedz mu kodem 200, danymi tekstowymi, o treści "Witaj! :)" }); serwer.begin(); //zainicjujmy nasz serwer } void loop() { } W powyższym kodzie widzimy następujące etapy, łączymy się z naszą siecią WiFi, ESP zwraca nam przez port szeregowy swój adres IP w naszej sieci. Będzie on nam potrzebny do wpisania w pasku przeglądarki w celu połączenia się z serwerem. Następnie tworzymy funkcję która obsługuje konkretne zapytania, w naszym przypadku po otrzymaniu zapytania GET pod adresem „/” – można to określić jako „folder główny” serwera, tak samo jak w komputerze mamy dysk np. „D:\” – odeśle klientowi odpowiedź o kodzie 200 (oznacza to „ok” – więcej o kodach tutaj) i zawartości typu tekstowej (są to typy MIME, mówią one przeglądarce co jej chcemy przekazać – więcej o typach MIME tutaj). Rezultatem, po wpisaniu w pasek przeglądarki adresu IP naszego ESP, jest strona. Tworzymy prostą stronę Jako że celem tutaj nie jest nauka HTML czy też CSS, ograniczyłem stronę do absolutnego minimum, potrzebnego do naszych zabaw. Tutaj też, odeślę do wartościowego źródła gdzie można znaleźć wiele wartościowych informacji odnośnie HTML, JavaScript, CSS oraz innych. Nasza strona będzie się składać z pola tekstowego gdzie wyświetlimy wartość odczytaną z ADC, dwóch przycisków do włączania i wyłączania diody oraz przycisku pobierania pliku z naszego ESP. <!DOCTYPE html> <html> <head> <title>Strona</title> <meta charset="UTF-8"/> </head> <body> <p id="pomiar">Wartość:</p> <button id="on">Włącz</button> <button id="off">Wyłącz</button><br> <button id="download">Pobierz obrazek</button> <script> </script> </body> </html> Kluczowe podczas tworzenia takiej strony jest nadawanie unikalnego ID każdemu elementowi, ułatwi to współpracę z JavaScriptem. Gdy już mamy przygotowaną stronę musimy ją wgrać do SPIFFS. Stąd będziemy wysyłać plik HTML jako odpowiedź dla klienta. Analogicznie można te pliki wgrać na kartę pamięci i z delikatną modyfikacją kodu serwować z niej pliki. #include <Arduino.h> #include <WiFi.h> //ESP8266 //#include <ESP8266WiFi.h> #include <SPIFFS.h> //ESP8266 //#include <FS.h> #include <SPIFFS.h> #include <ESPAsyncWebServer.h> #define SSID "nazwa sieci" #define PASS "hasło sieci" AsyncWebServer serwer(80); //utwórzmy obiekt serwera na porcie 80 void setup() { Serial.begin(115200); //zainicjujmy port szeregowy SPIFFS.begin(); //zainicjujmy system plików WiFi.begin(SSID, PASS); //połącz z naszą siecią wifi while (WiFi.status() != WL_CONNECTED){ //poczekajmy aż ESP połączy się z naszą seicią //delay(1000); //dla ESP8266 } Serial.printf("\nAdres IP:"); Serial.println(WiFi.localIP()); //wypisz adres IP naszego ESP przez port szeregowy //tutaj odbywa sie obsługa zapytań serwer.on("/", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytania pod adresem "/" typu GET, request->send(SPIFFS, "/index.html", "text/html"); //odpowiedz plikiem index.html z SPIFFS (można to zmienić na kartę SD) //zawierającym naszą stronę będącą plikem tekstowym HTML }); serwer.begin(); //zainicjujmy nasz serwer } void loop() { } Teraz po wpisaniu adresu IP naszej strony w pasek przeglądarki ukaże się nam prosta strona. Pora na działanie! Na pierwszy ogień weźmiemy obsługę LED. W tym celu konieczne będzie dorzucenie trochę JavaScriptu do naszej strony document.getElementById("on").onclick = function () { //po nacisinięciu elementu o ID "on" const zapytanie = new XMLHttpRequest(); //wyślijmy zapytanie GET, pod adresem /on zapytanie.open("GET", "/on"); zapytanie.send(); }; document.getElementById("off").onclick = function () { //po nacisinięciu elementu o ID "off" const zapytanie = new XMLHttpRequest(); //wyślijmy zapytanie GET, pod adresem /off zapytanie.open("GET", "/off"); zapytanie.send(); }; Kod ten sprawdza czy któryś z przycisków został naciśnięty, a jeżeli został wysyła stosowne zapytanie do naszego serwera. Finalnie kod strony przedstawia się jak poniżej. <!DOCTYPE html> <html> <head> <title>Strona</title> <meta charset="UTF-8"/> </head> <body> <p id="pomiar">Wartość:</p> <button id="on">Włącz</button> <button id="off">Wyłącz</button><br> <button id="download">Pobierz obrazek</button> <script> document.getElementById("on").onclick = function () { //po nacisinięciu elementu o ID "on" const zapytanie = new XMLHttpRequest(); //wyślijmy zapytanie GET, pod adresem /on zapytanie.open("GET", "/on"); zapytanie.send(); }; document.getElementById("off").onclick = function () { //po nacisinięciu elementu o ID "off" const zapytanie = new XMLHttpRequest(); //wyślijmy zapytanie GET, pod adresem /off zapytanie.open("GET", "/off"); zapytanie.send(); }; </script> </body> </html> Ponadto w sekcji setup() naszego kodu ESP musimy dodać obsługę nowo powstałych zapytań. serwer.on("/on", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/on" typu GET, digitalWrite(LED, LOW); //zapal diodę request->send(200); //odeślij odpowiedź z kodem 200 OK }); serwer.on("/off", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/off" typu GET, digitalWrite(LED, HIGH); //zgaś diodę request->send(200); //odeślij odpowiedź z kodem 200 OK }); Co daje nam w rezultacie kod jak poniżej. Ważne aby wszystkie zapytania były przed funkcją serwer.begin() #include <Arduino.h> #include <WiFi.h> //ESP8266 //#include <ESP8266WiFi.h> #include <SPIFFS.h> //ESP8266 //#include <FS.h> #include <SPIFFS.h> #include <ESPAsyncWebServer.h> #define SSID "nazwa sieci" //nazwa sieci #define PASS "haslo sieci" //hasło sieci #define LED 22 //numer pinu gdzie mamy podłączoną diodę AsyncWebServer serwer(80); //utwórzmy obiekt serwera na porcie 80 void setup() { Serial.begin(115200); //zainicjujmy port szeregowy SPIFFS.begin(); //zainicjujmy system plików pinMode(LED, OUTPUT); //ustawmy naszeg pin jako wyjście WiFi.begin(SSID, PASS); //połącz z naszą siecią wifi while (WiFi.status() != WL_CONNECTED){ //poczekajmy aż ESP połączy się z naszą seicią //delay(1000); //dla ESP8266 } Serial.printf("\nAdres IP:"); Serial.println(WiFi.localIP()); //wypisz adres IP naszego ESP przez port szeregowy //tutaj odbywa sie obsługa zapytań serwer.on("/", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytania pod adresem "/" typu GET, request->send(SPIFFS, "/index.html", "text/html"); //odpowiedz plikiem index.html z SPIFFS (można to zmienić na kartę SD) //zawierającym naszą stronę będącą plikem tekstowym HTML }); serwer.on("/on", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/on" typu GET, digitalWrite(LED, LOW); //zapal diodę request->send(200); //odeślij odpowiedź z kodem 200 OK }); serwer.on("/off", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/off" typu GET, digitalWrite(LED, HIGH); //zgaś diodę request->send(200); //odeślij odpowiedź z kodem 200 OK }); serwer.begin(); //zainicjujmy nasz serwer } void loop() { } Teraz możemy zaobserwować działanie naszego kodu. Odczyt ADC Teraz pora na odczyt wartości z przetwornika analogowo-cyfrowego. Tym razem nasz skrypt będzie automatycznie, z pewnym interwałem czasowym (500ms), wysyłał zapytanie do serwera. setInterval(function () { const zapytanie = new XMLHttpRequest(); zapytanie.open("GET", "/adc"); zapytanie.send(); zapytanie.onreadystatechange = function () { if (this.readyState == 4 && this.status == 200) { document.getElementById("pomiar").innerHTML = "Pomiar:" + this.responseText; } }; }, 500); Powyższy fragment powinien znaleźć się w pliku .html w sekcji <script>, tak jak poprzednio. Serwer w odpowiedzi będzie zwracał wartość z ADC w postaci tekstu, zaś JavaScript, w tle będzie nam podmieniał wartości na stronie uzyskane w odpowiedzi od serwera, bez konieczności przeładowania. W kodzie ESP wystarczy że dodamy taki fragment kodu do sekcji setup() przed funkcją serwer.begin(). serwer.on("/adc", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/off" typu GET, String wartosc = String(analogRead(ADC)); //wykonaj pomiar ADC i zapisz do Stringa request->send(200, "text/plain", wartosc); //odeślij odpowiedź z kodem 200 OK i odczytem z wartością }); Na powyższej animacji widać jak zmieniają się wartości. W konsoli przeglądarki (przycisk F12 powinien nam ją uruchomić w większości przeglądarek) można obserwować wszystkie zapytania wymieniane między klientem a serwerem. Jest to bardzo przydatne narzędzie do „debugowania” kiedy coś nie chce do końca z nami współpracować. Powyższe zadania możemy zrealizować również w inny sposób, poprzez wywołanie naszej funkcji z poziomu funkcji obsługi zapytań. Przykład obsługi ADC przedstawiałby się w następujący sposób. #include <Arduino.h> #include <WiFi.h> //ESP8266 //#include <ESP8266WiFi.h> #include <SPIFFS.h> //ESP8266 //#include <FS.h> #include <SPIFFS.h> #include <ESPAsyncWebServer.h> #define SSID "nazwa sieci" //nazwa sieci #define PASS "hasło sieci" //hasło sieci #define ADC 34 //numer pinu potencjometru AsyncWebServer serwer(80); //utwórzmy obiekt serwera na porcie 80 String odczyt_ADC() { return String(analogRead(ADC)); } void setup() { Serial.begin(115200); //zainicjujmy port szeregowy SPIFFS.begin(); //zainicjujmy system plików pinMode(LED, OUTPUT); //ustawmy naszeg pin jako wyjście WiFi.begin(SSID, PASS); //połącz z naszą siecią wifi while (WiFi.status() != WL_CONNECTED){ //poczekajmy aż ESP połączy się z naszą seicią //delay(1000); //dla ESP8266 } Serial.printf("\nAdres IP:"); Serial.println(WiFi.localIP()); //wypisz adres IP naszego ESP przez port szeregowy //tutaj odbywa sie obsługa zapytań serwer.on("/", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytania pod adresem "/" typu GET, request->send(SPIFFS, "/index.html", "text/html"); //odpowiedz plikiem index.html z SPIFFS (można to zmienić na kartę SD) //zawierającym naszą stronę będącą plikem tekstowym HTML }); serwer.on("/adc", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/off" typu GET, request->send(200, "text/plain", odczyt_ADC()); //odeślij odpowiedź z kodem 200 OK i odczytem z wartością }); serwer.begin(); //zainicjujmy nasz serwer } void loop() { } Pobieranie pliku Na koniec zajmiemy się pobieraniem pliku z naszego serwera. W celu pokazania jak korzystać z typów MIME przedstawię jak pobrać obrazek z naszego prostego serwera. Do naszej ESP pamięci wgramy poniższy obrazek. W tym celu musimy dodać fragment skryptu do naszej strony. document.getElementById("download").onclick = function () { //po nacisinięciu elementu o ID "download" location.href = "/download"; //przekieruj pod /download }; Podobnie jak uprzednio dodajemy go do naszej sekcji <script></script>. Działa on podobnie jak poprzednie włączanie i wyłączanie diody, lecz w normalnej sytuacji, takie działanie spowodowałoby przekierowanie pod ten adres /download. Ponieważ w kodzie programu ustawimy atrybut pobierania. Będzie to skutkowało wyskoczeniem okna pobierania. serwer.on("/download", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/off" typu GET, request->send(SPIFFS, "/Lenna.png", "image/png", true); //odeślij odpowiedź w postaci pliku png o nazwie obrazek.png z SPIFFS i umożliwij pobranie (true) }); Jak widzimy musimy wskazać skąd nasz plik ma zostać pobrany (SPIFFS, może to być również karta SD), następnie wskazujemy dokładną lokalizację naszego pliku, jego rodzaj (MIME) oraz ustawiamy atrybut pobierania jako true. W efekcie uzyskujemy pobieranie naszego pliku. Zachęcam do sprawdzenia rezultatu po zmienieniu atrybutu pobierania na false. Poniżej zamieszam finalne wersje programu Arduino oraz kodu strony HTML. #include <Arduino.h> #include <WiFi.h> //ESP8266 //#include <ESP8266WiFi.h> #include <SPIFFS.h> //ESP8266 //#include <FS.h> #include <SPIFFS.h> #include <ESPAsyncWebServer.h> #define SSID "nazwa sieci" //nazwa sieci #define PASS "hasło sieci" //hasło sieci #define LED 22 //numer pinu gdzie mamy podłączoną diodę #define ADC 34 //numer pinu potencjometru AsyncWebServer serwer(80); //utwórzmy obiekt serwera na porcie 80 void setup() { Serial.begin(115200); //zainicjujmy port szeregowy SPIFFS.begin(); //zainicjujmy system plików pinMode(LED, OUTPUT); //ustawmy naszeg pin jako wyjście WiFi.begin(SSID, PASS); //połącz z naszą siecią wifi while (WiFi.status() != WL_CONNECTED){ //poczekajmy aż ESP połączy się z naszą seicią //delay(1000); //dla ESP8266 } Serial.printf("\nAdres IP:"); Serial.println(WiFi.localIP()); //wypisz adres IP naszego ESP przez port szeregowy //tutaj odbywa sie obsługa zapytań serwer.on("/", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytania pod adresem "/" typu GET, request->send(SPIFFS, "/index.html", "text/html"); //odpowiedz plikiem index.html z SPIFFS (można to zmienić na kartę SD) //zawierającym naszą stronę będącą plikem tekstowym HTML }); serwer.on("/on", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/on" typu GET, digitalWrite(LED, LOW); //zapal diodę request->send(200); //odeślij odpowiedź z kodem 200 OK }); serwer.on("/off", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/off" typu GET, digitalWrite(LED, HIGH); //zgaś diodę request->send(200); //odeślij odpowiedź z kodem 200 OK }); serwer.on("/adc", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/off" typu GET, String wartosc = String(analogRead(ADC)); //wykonaj pomiar ADC i zapisz do Stringa request->send(200, "text/plain", wartosc); //odeślij odpowiedź z kodem 200 OK i odczytem z wartością }); serwer.on("/download", HTTP_GET, [](AsyncWebServerRequest *request){ //na otrzymane od klienta zapytanie pod adresem "/off" typu GET, request->send(SPIFFS, "/Lenna.png", "image/png", false); //odeślij odpowiedź w postaci pliku png o nazwie obrazek.png z SPIFFS i umożliwij pobranie (true) }); serwer.begin(); //zainicjujmy nasz serwer } void loop() { } <!DOCTYPE html> <html> <head> <title>Strona</title> <meta charset="UTF-8" /> </head> <body> <p id="pomiar">Wartość:</p> <button id="on">Włącz</button> <button id="off">Wyłącz</button><br> <button id="download">Pobierz obrazek</button> <script> document.getElementById("on").onclick = function () { //po nacisinięciu elementu o ID "on" const zapytanie = new XMLHttpRequest(); //wyślijmy zapytanie GET, pod adresem /on zapytanie.open("GET", "/on"); zapytanie.send(); }; document.getElementById("off").onclick = function () { //po nacisinięciu elementu o ID "on" const zapytanie = new XMLHttpRequest(); //wyślijmy zapytanie GET, pod adresem /off zapytanie.open("GET", "/off"); zapytanie.send(); }; setInterval(function () { const zapytanie = new XMLHttpRequest(); //wyślijmy zapytanie jak poprzednio zapytanie.open("GET", "/adc"); zapytanie.send(); zapytanie.onreadystatechange = function () { if (this.readyState == 4 && this.status == 200) { document.getElementById("pomiar").innerHTML = "Wartość:" + this.responseText; } }; }, 500); document.getElementById("download").onclick = function () { //po nacisinięciu elementu o ID "download" location.href = "/download"; }; </script> </body> </html> Podsumowanie Bardzo się cieszę że dotrwałeś do tego momentu! Jak wspomniałem na początku, przedstawione rozwiązania są najprostszymi, niekoniecznie zgodnymi ze sztuką rozwiązaniami. Starałem się w kodach programów ograniczyć wszystkie zbędne fragmenty i uprościć do absolutnego minimum – czego często brakuje w poradnikach z internetu, co skutkuje utrudnioną analizą działania programu. Pokazane sposoby mają na celu jedynie wprowadzenie do koncepcji tematu, zachęcenia do pracy oraz poznawania możliwości rozwiązań sieciowych, o których można by było pisać całe książki. Zarówno komunikacja z wykorzystaniem Websocketów czy tworzenie samej strony którą widzi klient – czyli strony internetowej – mogłaby zająć czas na oddzielne artykuły. W drugiej części artykułu omówię w teoretyczny sposób (bez gotowych rozwiązań programowych) jak z wykorzystaniem ESP oraz dostępnych technologii i bibliotek rozwiać takie problemy jak: konfigurowanie urządzenia z poziomu przeglądarki przeglądanie i zarządzanie plikami w pamięci ESP provisioning i co to oraz po co to właściwie jest M. S.

Swego czasu postanowiłem - dla oszczędności kasy i miejsca w obudowie - przerzucić się na proste moduły (typu ESP32-WROOM lub ESP12E). Na pierwszej doświadczalnej płytce miałem wszystkie elementy potrzebne do podłączenia konwertera USB-UART, ale w docelowych urządzeniach (np. czytak) absolutnie nie były one potrzebne. Postanowiłem stworzyć sobie taki własny pseudo-standard gniazda programowania i zrobić przejściówkę do popularnego konwertera HW-417. Nie będę się za dużo rozpisywał, napiszę tylko kilka rzeczy: Schemat całości to po prostu fragment ESP32 Dev Kit. Układ sprawdzony, działa zarówno z ESP32 (WROOM, WROVER) jak i ESP8266 (ESP-12E). Nie próbowałem robić żadnej specjalnej płytki, użyłem kawałka płytki uniwersalnej i części wyciągniętych z szuflady. Gniazdo programowania ma dodatkowy pin 3.3V. W tej chwili nie jest nigdzie podłączony, ale w planach mam przeróbkę płytki tak, aby można było podłączyć się albo do +5V z USB, albo do zewnętrznego zasilacza. Na zdjęciu widać, że wtyczka programatora jest ośmio- a nie sześciopinowa. Po prostu czytak ma dwa dodatkowe piny przeznaczone do podłączenia +5V do ładowania akumulatora (i bardzo się cieszę że to przewidziałem, bo z modułu ładowarki odpadło mi gniazdo USB). A ośmio[inowa żeńska wtyczka pasuje do sześciopinowego gniazda. Gniazdo do podłączenia ma 7 pinów, mimo iż sam konwerter ma sześć. Siódmy pin służy do podłączenia sygnału RTS. Niestety - wersja esptool-ftdi umożliwiająca wykorzystanie pinów DTR/CTS zamiast DTR/RTS nie jest rozwijana, a jakoś nie bardzo miałem czas żeby sprawdzić czy da się jakoś połączyć kod aktualnej wersji (CTS/RTS) z taką trochę zapomnianą gałęzią 😞 Zdjęcie kiedyś pokazywałem, ale dla przypomnienia jeszcze raz (na zdjęciu widać przewód łączący dolutowany do HW-417 pin RTS z przejściówka). Przejściówka sprawdza się zarówno przy programowaniu ESP32, jak i ESP8266. Ponieważ przewidziana jest do współpracy z esptool - powinna działać z Arduino IDE, PlatformIO jak i różnymi wynalazkami (jak mój "pyrduino"). Przyciski RESET i BOOT są tak na wszelki wypadek - esptool i tak steruje sygnałami RTS i DTR potrzebnymi do zresetowania płytki i/lub przejścia w stan uploadu.

Pisałem niedawno, że marzyłem kiedyś i takim przenośnym urządzeniu, które czytałoby mi książki w czasie spaceru czy jazdy pociągiem. I to nie audiobooki, ale zwyczajne ebooki. Cóż - kilkanaście lat temu było to raczej mało realne. Minęły lata (kilkanaście jak wspomniałem), realia się zmieniły, i chociaż rzadziej wychodzę na spacery czy wsiadam do pociągu - postanowiłem zrealizować swoje marzenie. Co prawda jakieś pierwotne założenia sobie poczyniłem, jednak pozostały z nich tylko dwa: rozmiar nie przekraczający paczki papierosów i ESP32 WROVER jako serce urządzenia. Miałem w planach kartę microSD - ale po drodze stwierdziłem, że na moim ESP mam jakieś 8MB flasha do dyspozycji na FatFS, książka po skompresowaniu zajmuje nie więcej niż pół mega, czyli kilkanaście książek powinienem zmieścić bez dodatkowych urządzeń typu czytnik kart. Kilka problemów musiałem rozwiązać zanim zabrałem się do jakiejkolwiek roboty. Najważniejsza była klawiatura: musiała być intuicyjna (tak żebym nie musiał wyciągać urządzenia z kieszeni żeby znaleźć klawisz pauzy), a jednocześnie odporna na jakieś "samoczynne" wciskanie klawiszy w kieszeni. Postanowiłem umieścić ją razem z gniazdem słuchawek i wyłącznikiem na górnej (najkrótszej) ścianie obudowy; pozwoli to na bezwzrokowe obsługiwanie czytaka, a jednocześnie jest nikłe prawdopodobieństwo że klawisz sam się wciśnie. Trochę musiałem pokombinować z ilością klawiszy (początkowo miało ich być 13, ale po ograniczeniu do 9 okazało się, że wszystkie potrzebne funkcje są dostępne). Trochę kombinowania - i wyszło mi coś takiego: Dla porównania wielkości - moje pudełko na papierosy. Jest to oczywiście tylko próbny wydruk, ale wszystkie klawisze są wlutowane do płytki, a gniazdo słuchawek jest już na swoim miejscu. Drugą niemniej ważną sprawą był rozmiar aplikacji. Tego się obawiałem najbardziej - bo o ile tworząc microlenę mogłem sobie pozwolić na dość duże uproszczenia z uwagi na przewidywalność stosunkowo krótkich komunikatów (vide "poziomica") - o tyle tutaj musiałem zastosować pełne słowniki i wzorce rozpoznawania zwrotów. Dodatkowo microlena nie miała modułu rozpoznawania czasowników - tu musiałem go stworzyć praktycznie od nowa (wersja pecetowa korzysta albo z Morfologika, albo z wbudowanego kilkunastomegabajtowego słownika czasowników). I tu niespodzianka - wszystkie dane potrzebne do przetworzenia tekstu z książki na zapis fonetyczny zmieściły się w ok. 800 kB. Co prawda analizator morfologiczny nie jest tak dokładny jak w wersji PC, ale wystarczający aby nie było rażących błędów prozodii. Przynajmniej słuchając przez pół godziny przygód Anastazji Kamieńskiej nie zauważyłem błędów (poza kompletnie popsutą odmianą liczebników, ale to kwestia błędów w programie, a nie niewystarczających danych). Tak więc testowa aplikacja, zawierająca prowizoryczny serwer www (do uploadu i ogólnie manipulowania "księgozbiorem") oraz syntezator ma ok. 1.8 MB. Ponieważ nie przewiduję jakichś "flashożernych" procedur powinienem zejść poniżej 3 MB. Biorąc pod uwagę zajmujące nieco ponad 5 MB próbki głosu potrzebne Mbroli do syntezy - powinienem móc połowę z 16 MB pozostawić na FatFS. Opiszę jeszcze klawiaturę urządzenia (w trybie odtwarzania): Klawisze po lewej stronie (piątka): dwa klawisze regulacji głośności klawisz pauzy dwa klawisze regulacji prędkości Klawisze po prawej stronie (romb) która godzina/stan baterii (krótkie lub długie wciśnięcie) dwa klawisze przeskoku o zdanie/akapit w tył lub do przodu gdzie jestem? (tytuł, rozdział, akapit) W trybie pauzy można przeskoczyć o akapit lub rozdział lub (poprzez długie naciśnięcie klawisza "pauza") przejść do stanu "stop" (tu jeszcze nie mam opracowanego znaczenia klawiszy). Ponieważ urządzenie będzie miało wbudowany zegarek - wybrałem moduł zawierający pamięć EEPROM, w której mam zamiar trzymać zarówno wszystkie ustawienia programu, jak i informacje o aktualnie czytanej książce (rozdział/akapit/offset). Cóż - zobaczymy co będzie dalej 🙂 Na pewno opiszę efekty moich bojów z wbudowanymi w ROM funkcjami kompresji/dekompresji, muszę tylko doprowadzić ten fragment kodu do postaci umożliwiającej publiczne pokazanie go bez narażania się na inwektywy oraz skrobnąć parę słów opisu typu "dlaczego tak a nie inaczej". Aha: program jest pisany pod Arduino, tak że być może ktoś wykorzysta jakieś jego fragmenty. Postaram się publikować co ciekawsze kawałki. Jeśli ktoś miałby jakieś sugestie - jestem bardzo ciekaw, bo na tym etapie mogę jeszcze dużo zmienić. Stay tuned!

- brakowało mi zawsze przy lutowaniu podgrzewacza oraz urządzenia do lutowania amatorskiego w technologii rozpływowej. - dopiero po pojawieniu się artykułu na temat użycia Uyue 946 do budowy amatorskiego podgrzewacza zdecydowałem się za to zabrać. - na razie zmontowałem układ do podania zadanej temperatury, czyli taki mały profile dla lutowania ołowiowego (PB) oraz bezołowiowego (LF). - zrzuty z programu poniżej. - w zasadzie w zakupionym Uyue 946 są wszystkie elementy, pozostało tylko wyrzucić użyty procesor i dołożyć esp32 Lolin 32 oraz wyświetlacz OLED 2.4". - długo się zastanawiałem czy raczej nie kupić MHP30 ale on nie ma profili lutowania i pole 30 x 30 mm jest zbyt małe do prac. - teraz czeka mnie dobranie parametrów do kontrolera PDI i określenie wydajności temperaturowej Uyue, do roboty. - przepraszam za jakość zrzutów ale z programu dostaje *.xbm i muszę konwertowac na *.jpg.

Przeglądając listę devkitów Espressifa trafiłem na wariant "RUST". Pierwsze myśl - czym to się różni od innych devkitów, bo trochę drogie 112zł na oficjalnym Ali. Opis sugeruje że są przykłady dla komponentów na płytce: Idąc dalej trafiam na repo ze schematem. Ciekawe, że ta płytka nie ma konwertera USB-UART tylko bezpośrednie podłączenie do USB-C. Najwyraźniej bootloader obsługuje USB. Ale to raczej nie czyni jej wyjątkowo "Rust" bo w repo wymienione są inne devkity. Podlinkowane są też są okazjonalne kursy. Patrząc na kolejne repo od esp-rs jest rozwijana implementajca ESP-IDF. Są narzędzia dla cargo np monitor. Jest też książka podobna do dokumentacji Rust w mdbook: Z opisu wynika że są jakieś 2 gałęzie projektu, jedna zgodna z std druga nie. Książka jest niekompletna, ale widać że coś się nabudowuje. Dział na oficjalnym forum jest dość pusty (samo forum jest dość puste) Ktoś coś robił w tym temacie i może podzielić się swoim doświadczeniem?

Jakiś czas temu zakupiłem sobie ESP32 CAM, niestety nie umiałem dla niej znaleźć jakiegoś sensownego zastosowania. Przeleżała z pół roku a może i więcej, aż wpadłem na pomysł zrobienia foto-pułapki. I tak oto powstała: Po mojej posiadłości często biegają dzikie zwierzęta takie jak: sarny, bażanty, dziki i zające. Te ostatnie to raczej szkodniki ale lecimy z tematem dalej. Założenia: Zapis zdjęć na karcie SD Wysyłka zdjęć na FTP Wysyłka zdjęć na maila jakiś czujnik temperatury praca możliwie jak najdłużej z jednej baterii wspomaganej panelem PV Po ogarnięciu softu na biurku podłączeniu czujnika PIR wszystko ładnie działało. Za zasilanie odpowiada jedno ogniwo 18650, przetwornica podnosząca napięcie do 5V i mały panel PV 6V 167mA. Jak widać powyżej kamera jest przylepiona klejem dwuskładnikowym, tak by uniknąć uszkodzenia tasiemki. Wszystko zostało umieszczone w obudowie po NanoStation Loco M5. Która została dostosowana do zamontowania panelu PV, czujnika PIR oraz kamery. Poniżej etap pasowania elementów. Został również wydrukowany daszek oraz uchwyty dla szyby która osłania kamerę od deszczu. Obudowa Została dodatkowo pomalowana na czarno - ale chyba będę jej robić jakieś malowanie taktyczne, lub pójdzie w ruch “termoglut” i trzcina żeby się lepiej wtapiała w otoczenie. Pierwsze wyjście w teren i klapa, wszystkie zdjęcia były przejaśnione. Po kilku próbach okazało się że kamera potrzebuje 2s! aby dostosować czas ekspozycji, (lekka tragedia bo przy zajączkach to już go może dawno nie być w kadrze) oczywiście w warsztacie wszystko działało jak należy. Następnym nietrafionym pomysłem okazało się wysyłanie zdjęć na maila, trwa to stosunkowo długo a co za tym idzie zużycie energii jest większe, co doprowadziło do rozładowania baterii po 2 dniach. Konieczne było zrezygnowanie z wysyłki zdjęć na maila. W tej chwili kamera działa bez ładowania już 5 dni. Przykładowe zdjęcia z kamery poniżej: Trapi mnie jeszcze jeden problem mianowicie jeśli na zdjęciu jest więcej szczegółów np: cały kadr trzciny lub trawy, to obraz jest obcinany tak około 100-200px z dołu. Nie jest to chyba problem buforu w ESP bo przy kompresji ustawionej w sofcie na 10 zdjęcia zajmują 384KB jeśli zwiększę kompresje zdjęcia zajmują mniej a obraz i tak jest obcinany. Oprócz zdjęć wyzwalanych czujnikiem ruchu, procesor budzi się co 30 min wykonuje zdjęcie i wysyła je na FTP. To aby mieć pewność że bateria nie uległa rozładowaniu. A i jest jeszcze nieszczęsny czujnik temperatury DS18B20, nie było łatwo go tam upchać bo okazało się że wszystkie piny na płytce są wykorzystywane i jedyny wolny pin który mogę wykorzystać to pin serial RX, co niesie za sobą konieczność wypięcia czujnika w razie chęci przeprogramowania układu. Lista wykorzystanych elementów: ESP32-CAM AI-Thinker Przetwornica step-up 5V wraz z modułem ładowania ogniw 18650 Koszyk na ogniwo 18650 Czujnik PIR Mini panel PV 6V 167mA Antena 2.4 Ghz Podsumowując, działa aczkolwiek widać pewne ograniczenia tego układu chociażby czas jaki kamera potrzebuje na uruchomienie się. Z ciekawostek do ESP32 została podłączona zewnętrzna antena, gdzie przetestowany zasięg to około 200 m :), ale pewnie to też zasługa tego że łącze się do AP który mam wystawiony na dworze. Kodu programu pozwolę sobie w tej chwili nie udostępnić bo mam tam niezły bałagan, a jeszcze staram się uporać z obcinaniem fotek, za jakiś czas na pewno go zamieszczę.

Witam...tak sobie czytam o pamięciach na ESP32 i kilku rzeczy nie jestem pewien...np. mamy funkcję która ma działać w przerwaniu, czyli void IRAM_ATTR fun() Czy wszystkie stałe znajdujące się w tej funkcji muszą być umieszczone w ram'ie? Za pomocą np. DRAM_ATTR ______________________________________ Mamy dane które chcemy zachować po głębokim śnie, więc używamy RTC_DATA_ATTR a jest też inny atrybut który robi to samo (tak mi się wydaje po lekturze) czyli RTC_NOINIT_ATTR czy można to stosować zamiennie? I czy napewno obie wersje robią to samo? Chętnie też poczytam o innych atrybutach często stosowanych i wręcz koniecznych do prawidłowego działania, jeśli się wam cos nasuwa😉

Mocne postanowienie: na podstawie doświadczeń z lalkami zrobić coś, co pozbawione jest błędów poprzednich konstrukcji 🙂 Robot początkowo miał być czarownicą, ale okazało się, że dzieci w przedszkolu negatywnie reagują na postacie tego typu (młodsze się wręcz boją czarownicy czy czarodzieja), dlatego ma być to kolejny Krasnolud. Tym razem nie Tolkienowski mieszkaniec podziemi, a sympatyczny Krasnal mieszkający w lesie, z ładną czerwona czapeczką i miłym dla oka szlafroczkiem. Ponieważ sprawę podwozia mam na razie nie do końca rozwiązaną, postanowiłem, że będzie to stary Krasnolud, jeżdżący w fotelu na kółkach. Takie rozwiązanie zwalnia mnie z konieczności ukrywania kół napędowych, a jednocześnie pozwala na użycie większych i tańszych silników (NEMA 17, kupione po 7 PLN na Allegro). Ponownie chcę użyć akumulatora Parkside (bardzo dobrze sprawdził się w poprzednim Krasnoludzie), tym razem nie kombinuję z EasyDriverami tylko wstawiłem stare dobre A4988. Zostawiam sobie jednak możliwość zastosowania TMC 2209 (o ile eksperyment pokaże, że detekcja zatrzymania silnika będzie działała poprawnie). Na razie mam złożone podwozie: Silniki które kupiłem miały założone zębatki na wałach, dlatego taka a nie inna konstrukcja kół napędowych. Teoretycznie mają półtora ampera na cewkę, na sterownikach ustawiłem na razie 0.7A a i tak są za mocne. Ale dokładniej będę mógł ustawić dopiero na zakończenie. I tu ciekawostka: koła wyposażone w łożyska 6mm miały być osadzone na wspólnej osi. Niestety, okazało się że gwintowany (podobno M6) pręt który mam ma jakieś 5.4mm średnicy i nie bardzo chciał współpracować z łożyskami. Użyłem pojedynczych śrub wymontowanych ze starej kanapy (jak dobrze sobie zostawić takie drobiazgi). A co z resztą? Głowę mam w połowie gotową. Dzisiaj powinny przyjść serwa HD1440A (zależy mi zarówno na wymiarach, jak i najmniejszym możliwym poborze prądu). W sumie jest tu pięć serw: po jednym HD1370A umieszczonych wewnątrz gałki ocznej, jedno do pionowego wspólnego ruchu oczu, jedno do skłonu głowy (uczciwe cięgło a nie jakieś wydumane zębatki) i jedno do obrotu (tym razem przekładnia zębata 1:2, sprawdziła się bardzo dobrze w poprzednich konstrukcjach). Jak tylko uda mi się zamontować serwa wrzucę jakąś ładną fotkę. Ręce - a właściwie ręka, bo tylko prawa ma być w pełni animowana. Zrobiłem bardzo ambitne założenie sześciu stopni swobody, zobaczymy co z tego wyjdzie. Serwa do napędu ręki mam. Kombinuję jeszcze z jakimś wyhamowaniem oscylacji na głównym serwie barkowym, być może uda mi się to osiągnąć programowo tylko musiałbym dodać jakieś sprzężenie zwrotne... no cóż, zobaczymy co z tego wyjdzie. Jeśli nic, zawsze mogę skorzystać ze sprawdzonego rozwiązania (ograniczenie prędkości ruchu serwa). No i oczywiście "drobiazgi": żyroskop/akcelerometr, kamera (do patrzenia na twarz rozmówcy), czujnik odległości (tym razem nie tylko do wykrywania przeszkód ale również do ustalania zbieżności oczu), syntezator mowy i takie tam różności. Zdalne sterowanie na razie poprzez UDP (ESP32 pracujący w trybie AP_STA, czyli z możliwością zarówno podłączenia do domowej sieci WiFi jak i do pracującego w trybie STA sterownika). Pozwala mi to na odłożenie zaprojektowania sterownika na sam koniec i sterowanie na razie prostą aplikacją na pececie. No cóż - sam jestem ciekaw co mi z tego wyjdzie 🙂

- przyszedł czas na dokończenie zeszłorocznego projektu zegarka na RGB ringu z 60 diodami rgb. - projekt zawiera esp32 WEMOS Lolin 32, akumulator Li-Po 400 mAh, czujnik temperatury BME280, czujnik światła BH1750, mp3 odtwarzacz DFPlayer oraz czujnik IR model TSOP31256 , OLED 2.4" SSD1309, WS2812 RGB w kształcie ringu z 60 ledami RGB. - na razie mam wszystko "doklejone" do tarczy zegara analogowego 26 cm i patrzę jak to ustawić aby było optymalnie dla mnie. - czas jest pokazywany na ringu RGB przez pojedyncze piksle , czerwony godzina, zielony minuta, niebieski sekundy, zaznaczone są także znaczniki czasu co 15 minut w kolorze żółtym. - jest jeszcze wahadło w kolorze zielonym biegające od 0 piksla do 59 i z powrotem, czas "obiegu" to 1 sekunda. - jako sterownik IR użyłem popularnego sterownika NEC IR do Car IR. - sterownik IR reguluje głośność muzyki, wybiera katalogi i pliki do odtworzenia, zatrzymuje wahadło, restartuje cały system. - na wyświetlaczu OLED pokazuję czas, numer pliku i katalogu do odtwarzania, wilgotność, temperaturę oraz ciśnienie barometryczne, siłę światła lux. - pętla obsługi RGB pracuje na core1, reszta programu na core 0. - program komunikuje się z serwerem NTP za pośrednictwem Wi-Fi, dwa razy dziennie. - problemy jakie mam obecnie to mruganie diod RGB podczas pracy wahadla oraz zbyt duże świecenie diod RGB w trybie nocnym. - aktualizacja programu nie jest wykonywana w trybie OTA, ponieważ esp32 Lolin 32 ma tylko 4MB flasha a program obecnie zajmuje 1.6MB. - program podaje aktualny czas głosowo co 15 minut, próbki są pobierane z karty SD na DFPlayer. - poniżej zdjęcia z aktualnego stanu prac.

Używam esp32-cam i chciałbym zapisywać dane z czujnika na kartę SD. Niestety, ale gdy wysyłam dane komendą file.println w pętli loop, to albo plik jest pusty, albo plik zawiera dane tylko tak jakby po jednym przejściu pętli.

No cześć, kilka miesięcy wzlotów i upadków, kłótni z żoną i w końcu jest .... ESPoBOT 🙂 Robot gąsienicowy RC z kamerą FPV i chwytakiem. Sterowanie oparte o ESP32-wroom 32D. Zacząłem od Arduino, ale z uwagi na problemy z komunikacją dwustronną NRF24L01, przesiadłem się na ESP32. Napędem są 2 silniki 9Vdc z przekładnią 87:1 na podwoziu gąsienicowym z regulacją prześwitu, kontrolowane przez sterownik oparty o układ TB6612. Prędkość silników regulowana płynnie w zakresie 0-30cm/s (1km/h). Robot wyposażony w chwytak umożliwiający chwycenie detalu, podniesienie/opuszczenie z użyciem 3 serw. Kontrola zaciśnięcia chwytaka zrealizowana poprzez pomiar prądu serwa. Regulacja prędkości serw. Zainstalowana kamera 1200TVL do przekazywania obrazu fpv 5.8GHz na telefon, PC lub wyświetlacz AV. Zasięg nadajnika do 500m. Robot wyposażony w oświetlenie LED RGB. Całość zasilana z akumulatora LiPo 1800mAh 11,1V 20C i zabezpieczona bezpiecznikiem polimerowym 4A. Dodatkowo akumulator zabezpieczony programowo przed rozładowaniem. Komunikacja dwustronna z padem na częstotliwości 2.4GHz (ESP-NOW) i zasięgu do 250m. Pad wyposażony w 2 joysticki, 6 guzików, potencjometr, enkoder oraz wyświetlacz OLED 128x64 do wyświetlania parametrów urządzenia. Zasilany z akumulatora 9V 650mAh USB.

Wczoraj zacząłem coś tam bazgrać po półtora miesiąca przerwy i chcąc użyć wskaźnika jako argument funkcji napotkałem problem braku inkrementacji wartości na którą wskazuje ten wskaźnik... pomyślałem sobie że być może ja coś źle zapamiętałem lub ESP32 nie obsługuje takiego wyrażenia, no ale raz dwa do neta zajrzałem i wychodzi że wszystko jest ok składniowo, na pro mini taki sam problem... ktoś wie czemu? int x; fun(&x); void fun(int *z) { *z++; Serial.print(x); } Powyższy kod daję zero... natomiast takie coś.. *z += 1; daje już oczekiwany rezultat...

Hej, próbuje wysłać przez kolejkę na FreeRTOS strukturę wraz z rozróżnieniem dwóch tasków wysyłających i jednym odbierającym. Tak wygląda mój kod: #include "queue.h" typedef int taskProfiler; typedef enum { eSender1 = 0, eSender2, }DataSource_t; typedef struct { uint8_t ucValue; DataSource_t eDataSource; }Data_t; static Data_t xStructToSend[2] = { (100, eSender1), (50, eSender2) }; QueueHandle_t xQueue; taskProfiler senderTaskProfiler = 0; taskProfiler receiverTaskProfiler = 0; void setup() { // put your setup code here, to run once: Serial.begin(115200); delay(5000); Serial.println(xStructToSend[1].ucValue); xQueue = xQueueCreate(3, sizeof(Data_t)); xTaskCreate(vSenderTask, "Sender Task 1", 8192, &(xStructToSend[0]), 2, NULL); xTaskCreate(vSenderTask, "Sender Task 2", 8192, &(xStructToSend[1]), 2, NULL); xTaskCreate(vReceiverTask, "Receiver Task", 8192, NULL, 2, NULL); } void vSenderTask(void *pvParameters) { BaseType_t xStatus; const TickType_t xTicksToWait = pdMS_TO_TICKS(100); Data_t xReceivedStructure; memcpy(&xReceivedStructure, &pvParameters, sizeof(pvParameters)); while(1) { xStatus = xQueueSend(xQueue, pvParameters, xTicksToWait); if(xStatus != pdPASS) { Serial.println("Could not send to the Queue"); } Serial.println(xReceivedStructure.ucValue); } } void vReceiverTask(void *pvParameters) { Data_t xReceivedStructure; BaseType_t xStatus; while(1) { xStatus = xQueueReceive(xQueue, &xReceivedStructure, 0); if(xStatus == pdPASS) { if(xReceivedStructure.eDataSource == eSender1) { Serial.print("This is from Sender1: "); Serial.println(xReceivedStructure.ucValue); } else { Serial.print("This is from Sender2: "); Serial.println(xReceivedStructure.ucValue); } } else { Serial.println("Could not receive data from the queue"); } } } void loop() { // put your main code here, to run repeatedly: } W "setup()" linia "Serial.println(xStructToSend[1].ucValue);" zwraca mi wartość 0 chociaż teoretycznie powinna 50. Tak samo dzieje się w tasku wysyłającym w linii "Serial.println(xReceivedStructure.ucValue);". Wyglada jakby od samego początku była zła inicjalizacja wartości zmiennych w wysyłanej strukturze. Sam task Receiver zwraca wartość 152 lub 160. Jaki błąd został popełniony w tym kodzie i w jaki sposób prawidłowo mogę zainicjalizować zmienne w strukturze? Z góry dziękuje za pomoc. Pozdrawiam

Witam. Próbuję rozpocząć swoją przygodę z arduino. Na początek wybrałem płytkę TTGO esp32 z wyświetlaczem. Mam już pewne podstawy jeśli chodzi o samo programowanie w różnych językach ale nigdy nie próbowałem programować urządzeń. Po napisaniu najprostszego programu typu "hello word" albo wybraniu jakiegokolwiek gotowca nie mogę uruchomić go na swojej płytce. Przesyłanie zawsze kończy się komunikatem "hard resetting via RTS pin" i na tym koniec. Resetowanie przyciskiem umieszczanym na płycie nie daje rezultatów. Na YT znalazłem kilka filmów na ten temat. Między innymi ten poniższy, który pokazuje, że nie jest to żaden problem natomiast nic to nie zmienia. Nie uruchamia mi się program. Strasznie sie napaliłem na płytki arduino, widzę wiele zastosowań ale już 3 dzień nie mogę wystartować i powoli opadam z sił a podejrzewam, że to jakiś problem początkującego. Pomożecie?

Do kompletu z gadającym miernikiem - tym razem suwmiarka. Na początku uwaga: opisywany projekt przewidziany jest do współpracy z suwmiarką Vorel. Inne suwmiarki mogą działać lub nie. O ile układ pinów w gnieździe jest dla wszystkich urządzeń taki sam, o tyle wtyczka może nie pasować (i raczej nie będzie). Można spróbować oryginalnej wtyczki lub za pomocą OpenSCAD-a przyciąć ją do pożądanych rozmiarów (przykładowy kod zarówno na githubie, jak i w załączniku). Ponieważ istnieje kilka różnych protokołów przesyłania danych z tego typu urządzeń pomiarowych, trzeba się liczyć z tym, że kod programu może nie pasować: o ile funkcja odczytująca pojedynczy bit powinna działać, to zarówno odczyt pakietu jak i funkcja dekodowania pakietu mogą nie działać! I przede wszystkim dobra wiadomość: urządzenie (w obu wersjach) jest przystosowane do obsługi przez niewidomych. Zarówno kod, jak i schemat zostały zamieszczone na githubie, podam więc tylko najważniejsze informacje: Płytka LOLIN32 Lite została wybrana przede wszystkim ze względu na wbudowaną ładowarkę i możliwość pracy bezpośrednio z akumulatora LiPo. Rozwiązanie toru audio jest nienajlepsze (to taki eufemizm), ale działa. Oczywiście zastosowanie lepszego rozwiązania jest mile widziane. Należy tylko pamiętać, że ESP jeśli nie generuje dźwięku ustawia pin audio na zero, i tor audio nie powinien w tym momencie pobierać prądu z akumulatora. Można oczywiście przerobić program tak, aby obsłużyć podłączony dekoder I2S (np. taki) - jeśli ktoś jest zainteresowany a nie potrafi sam tego zrobić proszę dać znać w komentarzu. Aplikacja na telefon - proszę wybaczyć, to mój pierwszy projekt zrobiony w App Inventorze i nie zanosi się na to, aby ich było dużo więcej. Ważne, że działa. Gdyby ktoś chciał napisać swoją lepszą, jej sposób działania (to musi pozostać) jest następujący: Po wczytaniu komunikatu pierwszy znak jest zapamiętywany i ucinany, a do syntezatora wędruje pozostała część tekstu. Po zakończeniu pracy wymagane jest odesłanie zapamiętanego znaku, aby program suwmiarki wiedział kiedy skończyła się mowa. Obsługa suwmiarki realizowana jest jednym przyciskiem. Suwmiarka może pracować w trzech możliwych trybach: odczyt ciągły (co sekundę), odczyt zmian (jeśli zmieniła się wartość lub po naciśnięciu przycisku) oraz odczyt na żądanie (po wciśnięciu przycisku). Zmianę trybu wymusza się poprzez dłuższe (ponad 0.5 sekundy) wciśnięcie przycisku. Program odczytuje wynik w milimetrach lub calach (w tym przypadku tylko trzy cyfry po przecinku) rozpoznając, w jakich jednostkach pracuje suwmiarka. Pierwszy odczyt jest anonsowany (milimetry/cale), w następnych jednostka jest pominięta. Ponieważ wynik w milimetrach ma dwa miejsca po przecinku a wynik w calach trzy - łatwo się zorientować, w jakich jednostkach jest podany. Aby włączyć bluetooth i użyć telefonu jako syntezatora mowy, należy trzymać przycisk przy włączaniu urządzenia. Można uzyć dowolnego syntezatora dostępnego dla Androida, ale w przypadku syntezy Google należy liczyć się z dość dużymi opóźnieniami. Związane jest to z samym procesem syntezy dokonywanym na serwerach Google i program nie ma na to wpływu. Przy użyciu ESpeaka lub Vocalizera opóźnienie jest praktycznie niezauważalne. Dobra, tyle teorii. Pomysł siedział mi w głowie od paru lat - od pewnej (niedokończonej zresztą) dyskusji na Majsterkowie. Pierwsze próby były co prawda całkiem udane, ale użycie ESP8266 wymagało dodania konwerterów na wejściu, wyjście audio było takie sobie, a całość wymagała zasilania 5V i podłączana była kablem do suwmiarki. Nie było to specjalnie wygodne, toteż projekt poszedł w zapomnienie. Aż do chwili, kiedy zgłosił się do mnie ktoś kto znalazł mnie przez tamtą dyskusję z Majsterkowa, z pytaniem, czy jestem w stanie zrobić taką "gadającą suwmiarkę". Co prawda z różnych przyczyn nie chciałem podejmować się wykonania całości, ale pomyślałem, że przynajmniej napiszę działający program. To już poszło szybko. Funkcje odczytu pakietu za pomocą wejść analogowych na ESP32 znalazłem na githubie, syntezator miałem gotowy i przetestowany z poprzedniego projektu, więc tu żadnych problemów nie było - program ruszył właściwie tego samego dnia. "Ktosia" odesłałem na nasze forum (bo pomyślałem, że na pewno znajdzie się ktoś kto takie urządzenie zrobi, szczególnie że nie trzeba się martwić działaniem programu), kod wrzuciłem na githuba i zająłem się czymś innym. Tyle, że po chwili owego zajmowania się stwierdziłem, że taka gadająca suwmiarka bardzo by mi się przydała, i postanowiłem spróbować swoich sił w wykonaniu całości. Po krótkim szukaniu znalazłem kilka elementów które kupiłem z myśla o innym projekcie. Przede wszystkim niewielki akumulatorek (być może trochę za mały, ale się sprawdził) oraz mały głośniczek, wymiarami idealnie pasujący do suwmiarki. Lolina miałem co prawda zamontowanego w innym urządzeniu, ale mogłem go przynajmniej dokładnie zmierzyć, a płytka DevKit posłużyła mi do kolejnych eksperymentów. Szybciutko więc znalazłem Lolina na Allegro, i zająłem się projektowaniem obudowy. Po kilku nieudanych próbach doszedłem wreszcie do czegoś, co było już w miarę używalne. I tu uwaga dla kogoś, kto chciałby zrobić takie urządzenie. Zamieszczam co prawda pliki STL i scad, ale są one przygotowane pod konkretne elementy, i wymagane jest użycie wyłącznika i przycisku dokładnie takiego, jak w moim projekcie! Głośnik i akumulator też muszą być takie same! Wracając do rzeczy: wyłącznik i przycisk wlutowane są do kawałków płytki uniwersalnej dociętych tak, że wchodzą w przygotowane prowadnice (wystają ok. 1.5 mm z obu stron). Wzmacniaczyk (to taka szumna nazwa dla jednego tranzystora) umieściłem również na kawałku płytki uniwersalnej przymocowanej tymi samymi śrubkami, które służą do mocowania elementu przytrzymującego głośnik. Jeśli chodzi o sam druk, obudowa musi być wykonana z PETG ze względu na konieczną sprężystość uchwytów przytrzymujących urządzenie na suwmiarce. Dobranie parametrów druku jest zależne od posiadanej drukarki, ale ważne jest aby chłodzenie było minimalne - inaczej uchwyty mogą się odłamać! Pozostałe elementy mogą być z dowolnego materiału (PLA, ABS) z wyjątkiem wtyczki; ta musi być wydrukowana z TPU z warstwą najlepiej 0.1mm (0.2mm pierwsza). Na szczęście moja poczciwa A8 dała sobie radę doskonale (co utwierdza mnie w przekonaniu iż osoba, która kiedyś na forum twierdziła jakoby Anet A8 się nie nadawała do "poważnych rzeczy" była co najmniej w błędzie). Jak widać, urządzenie trzyma się na suwmiarce za pomocą trzech uchwytów (czwarty służy do zabezpieczenia wtyczki przed przypadkowym wypadnięciem) i nie wymaga żadnych przeróbek suwmiarki (poza oczywiście zdjęciem klapki zabezpieczającej gniazdo danych i schowaniem jej w jakieś bezpieczne miejsce). Niestety, rachityczny głośniczek brzmi trochę niespecjalnie... teoretycznie mógłbym sprzęgnąć układ z komputerem i użyć np. speech-dispatchera - tyle, że nie zawsze mam komputer pod ręką. No, komputer komputerem, ale w dzisiejszych czasach każdy ma przecież telefon! Postanowiłem nieco ulepszyć program i pozwolić mu na użycie telefonu z Androidem jako syntezatora mowy. Niestety, na pisaniu czegokolwiek pod Androida to ja się nie znam absolutnie. Na szczęście MIT App Inventor zawiera wszystkie klocki potrzebne do zbudowania takiej aplikacji. Co prawda nie przepadam za składaniem programów z klocków - no, ale na szybko innej możliwości napisania czegoś na Androida raczej nie miałem. Aplikacja jak wyszła tak wyszła - najważniejsze że działa. Na tym mógłbym skończyć, ale zakiełkował mi nowy pomysł. A co, jeśli ktoś nie przepada za doczepianiem dodatkowych pudełeczek do suwmiarki, a zgadza się na kabelek idący choćby właśnie do telefonu? Wystarczyłoby przecież usunąć z mojego programu wbudowany syntezator, a serial BT zastąpić zwykłym serialem... No tak, tylko że w tym przypadku użycie ESP32 to overkill. Akurat pod ręką miałem RPi Pico, i postanowiłem sprawdzić, czy się nada. Pierwsze próby z Serial Terminalem poszły świetnie; telefon co prawda w czasie podłączania twierdził że to pewnie kamera i chciał uruchomić IP Webcama, ale po wyperswadowaniu mu tego połączył się grzecznie z terminalem. Czyli sukces? Akurat. Serial Terminal bardzo ładnie dogadał się z Pico, ale ani wbudowany w Inventora moduł, ani rozszerzenie które podobno łączy się z wszystkimi możliwymi typami Arduino nie chciały gadać z Pico. A gdyby tak Arduino? Z tego co miałem w grę wchodziły tylko UNO i Nano, ze względu na wbudowane USB. Akurat miałem jeden nadmiarowy egzemplarz Nano więc postanowiłem go użyć. Co prawda ktoś tam kiedyś stwierdził, że Arduino jest za wolne ale jakoś mi się nie chciało wierzyć. Podłączyłem, i... Oczywiście. I nic. Na wejściu dostałem sieczkę. Ale to było do przewidzenia; o ile sam procesor powinien moim zdaniem wystarczyć, o tyle przetwornik A/D na Arduinowych ustawieniach jest faktycznie za wolny. Na szczęście nie potrzeba tu precyzyjnego pomiaru - wystarczy stwierdzenie, czy sygnał na wejściu jest w okolicy zera czy powyżej 1V. Po przestawieniu preskalera z 1:128 na 1:16 Arduino zaczął pięknie odbierać pakiety z suwmiarki. Reszta była już prosta. Przycisk został wlutowany bezpośrednio do GND i D3 Arduino (akurat ładnie tam pasuje). Przewód do suwmiarki również został bezpośrednio przylutowany do Arduino. W ten sposób udało mi się zrobić coś, co nie wymaga żadnych dodatkowych elementów (nawet przycisk można pominąć jeśli nie korzystamy z odczytu "na żądanie" - aplikacja pozwala na zmianę trybu na odczyt ciągły lub odczyt zmian). Sama aplikacja na telefon jest podobna do poprzedniej. Obudowę tym razem wydrukowałem z PLA. Mogłaby być mniejsza - ale nie miałem śrubek mniejszych niż M2. Po złożeniu układ działa bez zarzutu z jednym wyjątkiem: pierwszy odczyt po podłączeniu do telefonu może być zniekształcony. Najprawdopodobniej na początku w buforze serial Androida są jakieś śmieci, ale jako że dotyczy to tylko pierwszego odczytu postanowiłem z tym na razie nie walczyć. W ten sposób powstały dwie wersje urządzenia. I o ile pierwsza wymaga trochę indywidualnego podejścia przy złożeniu tego wszystkiego w całość - o tyle druga jest gotowa do użytku i może być wykonana nawet przez kogoś, kto potrafi tylko lutować i wydrukować wtyczkę do suwmiarki (lub ma kumpla z drukarką). A oto suwmiarka w działaniu: Na koniec - wszystkie potrzebne pliki w zipie.roznosci.zip Czyli: pliki stl i scad dla wersji ESP32 pliki stl, scad i ino dla wersji Arduino pliki aia i apk dla wersji Arduino pliki stl i scad wtyczki

Hej, zajmuję się właśnie FreeRTOS'em na esp32-s3 devkitc-1 i chce stworzyć instancje funkcji aby można było ją wywoływać wielokrotnie w zależności od podanego argumentu. #define RED 2 #define GREEN 44 #define YELLOW 1 typedef int taskProfiler; taskProfiler REDLEDProfiler = 0; taskProfiler GREENLEDProfiler = 0; taskProfiler YELLOWLEDProfiler = 0; const uint16_t *redLed = (uint16_t*)RED; const uint16_t *greenLed = (uint16_t*)GREEN; const uint16_t *yellowLed = (uint16_t*)YELLOW; void setup() { // put your setup code here, to run once: Serial.begin(115200); delay(2000); xTaskCreate(ledControllerTask, "RED LED Task", 8192, (void*)redLed, 1, NULL); xTaskCreate(ledControllerTask, "GREEN LED Task", 8192, (void*)greenLed, 1, NULL); xTaskCreate(ledControllerTask, "YELLOW LED Task", 8192, (void*)yellowLed, 1, NULL); } void ledControllerTask(void *pvParameters) { pinMode(pvParameters, OUTPUT); while(1) { digitalWrite(pvParameters, digitalRead(pvParameters)^1); vTaskDelay(500); } } void loop() { // put your main code here, to run repeatedly: } Przy próbie kompilacji pojawia się błąd: exit status 1 invalid conversion from 'void*' to 'uint8_t' {aka 'unsigned char'} [-fpermissive] Czy jest jakiś dobry sposób na castowanie tych typów zmiennych?

- cały projekt jest wzorowany na schemacie ze strony https://www.instructables.com/Yet-Another-Smart-Weather-Station-But/ - urządzenie zbudowano z eps32 Wemos Lolin 32, żyroskopu MPU6050, odbiornika RF RX-B6, czujnika temperatury DHT22 oraz dwóch wyświetlaczy ePapier 4.2 cala oraz 2.9 cala, czarno-białych. - do sprawdzania stopnia naładowania akumulatora Lipo 3.7V 3500mAh użyto klucza MOSFET typu p oraz tranzystora npn do sterowania tym kluczem. - żyroskop określa aktualne przechylenie obudowy i podaje parametry do programu, program ustawia odpowiednio ekrany poziomo, pionowo. - stan pogody jest odczytywany poprzez router Wifi ze strony internetowej, podającej dane aktualne oraz prognozę 3-dniową. - program nie pobiera ikon do wyświetlania tylko nazwy tych ikon i generuje grafikę dla danej nazwy ikony. - czas jest pobierany z serwera NTP i synchronizuje czas lokalny na RTC układu esp32. - parametry i dane sa przechowywane w 8kB pamięci RTC, pojedyncze dane są przechowywane w EEPROM (flashu). - program po uruchomieniu wyświetla przyczynę uruchomienia, określa położenie żyroskopu i wg tych danych aktualizuje ekrany i program przechodzi w tryb uśpienia (setup) lub w tryb odczytu danych ze stacji WH5029 (loop). - wybudzić układ może timer albo przerwanie od żyroskopu (ruszenie obudową). - o godzinie 14:00 układ jest restartowany, restart jest także wymuszany co 15 bootowanie systemu. - do stacji pogodowej podłączono także odbiornik RF, odbierający dane z małej lokalnej stacji pogodowej model WH5029. - stacja ta podaje dane takie jak: temperatura, ciśnienie, kierunek i siła wiatru, wielkość opadu deszczu. - jest to takie zabezpieczenie na wypadek awarii Wi-Fi, do zabezpieczenia danych wykorzystano także trzy adresy routerów Wi-Fi na telefonach. - wyświetlacze są montowane do obudowy taśmą klejącą, połówki obudowy są także sklejone taśmą, autor obudowy nie przewidział żadnych zatrzasków dla połówek obudowy. - wersja oprogramowania to 0.30, program nie był optymalizowany, podprogramy duplikują się dla kolejnych orientacji ekranów. - w programie w komentarzach podano co należy poprawić w bibliotekach. - program nie jest dokończony dla obsługi ekranu 2.9 cala. - czasami na ekranach pojawia się napis WAIT, jest to przypadek gdy program odczytuje dane ze stacji WH5029. - montaż urządzenie jest typu kanapkowego, na dole jest wyświetlacz 2.9 cala, potem akumulator, płytka z elektroniką i do drugiej połowki obudowy jest przyklejony wyświetlacz 4.2 cala. - robiłem próby z wyświetlaczami z poziomami szarości oraz z wyświetlaczami 3-kolorowymi, efekty mizerne chyba z powodu słabych bibliotek. wnioski: 1.- niektóre ekrany są za bardzo przeładowane informacją 2.- obsługa żyroskopu jest chyba błędnie napisana, czasami układ nie reaguje na ruszanie obudową. ESP32-e-Paper-Weather.zip PCB_PCB_ePapier stacja pogodowa2_8x_2022-06-05.pdf Schematic_ePapier stacja pogodowa2_2022-04-07.pdf

...czyli trochę już zakurzony (ale za to dobrze przetestowany) projekt. Zaczęło się od tego, że pewna osoba zapytała mnie, czy byłbym w stanie zrobić coś w rodzaju metrówki. Początkowa odpowiedź miała brzmieć "nie", ale postanowiłem trochę pogłówkować. Oczywiście jakieś specjalizowane czujniki nie wchodziły w grę - urządzenie miało być zmontowane z tego, co można kupić od ręki bez czekania pół roku na transport z Chin, i to za cenę w miarę przystępną. Najpierw nie miałem pomysłu - ale w pewnej chwili gdy spojrzałem na drukarkę uświadomiłem sobie, że przecież pasek GT2 powinien być na tyle dokładny, żeby zapewnić milimetrową dokładność na odcinku - powiedzmy - dwóch metrów. Miałem jakieś kawałki pasków, więc zabrałem się do testowania. Na pierwszy ogień poszedł zwykły tani enkoder z nałożoną na oś zębatką. Pomiar okazał się wystarczająco dokładny - niestety, sam enkoder nie wytrzymał, trzeba było bardzo powoli przesuwać pasek, a po paru szybszych próbach po prostu przestał działać. Na szczęście miałem pozostałe po jakimś niezrealizowanym projekcie transoptory szczelinowe. Trochę projektowania, trochę drukowania - i to okazało się strzałem w dziesiątkę. Osadzony na łożyskach bęben z PLA bardzo dobrze współpracował zarówno z paskiem jak i z transoptorami, zapewniając pożądaną rozdzielczość pomiaru 1mm. Reszta była już prosta. Większość programu już miałem, czyli tym nie musiałem się przejmować. Użyłem jak zwykle płytki LOLIN32 Lite i typowego modułu MAX98357A. Kilka rezystorów wlutowałem po prostu w kawałek płytki uniwersalnej, to samo z wyłącznikiem i przyciskami - i urządzenie praktycznie ruszyło bez większych problemów. Piny na schemacie oznaczone są nazwami funkcji - przykładowe (zastosowane przeze mnie) przyporządkowania pinów znajdują się w pliku ESPMeter.h. Na zdjęciu urządzenie może sprawiać wrażenie jakiejś plątaniny kabelków - ale to dlatego, że nie chciałem odcinać przewodów od akumulatora, poza tym chciałem mieć jednak wszystko połączone na goldpinach. Na razie urządzenie spisuje się nieźle, zarówno mój egzemplarz jak i (podobno) kolegi @Jaha. Dodatkowo może z powodzeniem służyć jako centymetr krawiecki (zdaniem osoby niewidomej). Przy okazji wyszło, że niewidomy nawet pierwszy raz stykając się z Arduino IDE jest w stanie posługując się Windowsem z NVDA zarówno dokonać potrzebnych modyfikacji plików, jak i skompilować/wgrać program na płytkę - potrzebna tylko bardziej szczegółowa instrukcja. Szkoda, że Arduino IDE nie współpracuje z Linuksową Orcą 😞 I to tyle. Tym razem bez filmiku - byłby krótki i nudny i pewnie ktoś by się doczepił do tempa mowy 🙂 Dokładna instrukcja, plik OpenSCAD-a, schemat, kod źródłowy razem z microleną, Mimbrolą i polskim głosem - w załączniku.Metrowka.zip

- z tego powodu że obraził się na mnie mój klon analizatora zacząłem szukać przykładów analizatorów na sieci. - znalazłem analizator logiczny na układzie esp32 pracujący z PulseView. - tutaj strona autora projektu https://github.com/pschatzmann/logic-analyzer. - może ktoś zna podobny projekt? - jest tego dużo ale wiele z nich nie jest dalej rozwijana lub mają błędy.

- uruchomiłem esp32-prog (JTAG) pod eclipse na programie blink, działa na esp32 Lolin32. - uruchomiłem Arduino wersja 2.xx i nie mogę skonfigurować tego esp32-prog. - czytam , czytam i nie mogę uwierzyć że na razie Arduino 2.xx nie obsługuje tego interfejsu. - czy jest jakiś inny myk jak mimo wszystko dołączyć esp32 do Arduino ? - mam program napisany pod Arduino i nie chcę go przerabiać pod idf.

Witam panowie...mam taki problem ze chcialem troszke potestowac to ESP-CAM jako "nagrywarka" video no i pojawia sie taki problem, ze nie dziala😉 kod sie wgrywa, ale wywala blad w monitorze ze karta pamieci nie jest wykrywana (chyba)..karta byla formatowana, dodatkowo trzeba wrzucic folder "data" na SD (zrobione)..juz brak mi pomyslow🤔 ktos uzywal tego wynalazku z linku? https://github.com/s60sc/ESP32-CAM_MJPEG2SD blad w monitorze ponizej.. zastanawia mnie tez kwestia polaczenia z Wifi..nie wiem czy dobrze robie, haslo/login wpisalem do pliku "utils" (nie ma opcji wpisania tych hasel z poziomu kodu) bede wdzieczny za kazde sugestie😉 ps. wywala blad stad..

Wstęp Od poprzednich właścicieli mieszkania dowiedziałem się, że w piwnicy zdarzają się kradzieże. W związku z tym postanowiłem zbudować fotopułapkę na złodzieja: urządzenie, które po wykryciu ruchu robi zdjęcia i wysyła je na serwer. Serwer natomiast powiadamia mnie mailowo (z załączonymi zdjęciami) o wykryciu ruchu. Finał tej historii był taki, że... nie zdążyłem. Jakiś miesiąc przed ukończeniem projektu było seryjne włamanie, którego także padłem ofiarą 😕 Wracając do meritum: Hardware - ESP32-CAM - Arduino Pro Mini (klon) - moduł czujnika ruchu PIR HC-SR501 - moduł czytnika RFID MRFC522 - akumulator żelowy 6 V 4,5 Ah - obudowa Kradex Z2AW - przetwornica mini step-down 360 - Raspberry Pi 4 (serwer) Zasilanie W piwnicy nie ma gniazdka, więc założyłem, że zasilanie będzie akumulatorowe. Nie chciałem kombinować z wpinaniem się w oprawę oświetleniową i ryzykować oskarżenie o kradzież prądu. Gdybym nawet miał dostęp do prądu, to i tak dobrze byłoby zastosować akumulator buforowy. No może uprościłoby to projekt o tyle, że ESP, które jest nadrzędnym modułem urządzenia, mogłoby pracować w sposób ciągły, bez usypiania. Napięcie akumulatora obniżane jest do 3,3 V przez małą, tanią, chińską przetworniczkę step-down i... w zasadzie tyle. Komunikacja Miałem to wielkie szczęście, że w piwnicy łapie mi zasięg domowego WiFi. Dzięki temu odpadło kombinowanie z LoRa czy GSM. ESP "gada" z serwerem z wykorzystaniem socketów TCP. Schemat działania ESP jest w trybie deepsleep z którego budzi się co 2 godziny w celu zaraportowania napięcia akumulatora, albo od przerwania wywołanego sygnałem z czujnika ruchu. Jeśli wybudzenie wywołał czujnik ruchu, ESP w pętli robi zdjęcia i wysyła je do serwera w mieszkaniu. Wszelki zapis na karcie SD odpadał już w założeniach, bo złodziej może urządzenie zniszczyć albo po prostu zabrać ze sobą. Zdjęcia przesłane na serwer są już bezpieczne. Wyjście z pętli następuje w dwóch przypadkach: gdy czujnik PIR przestanie wykrywać ruch, albo gdy obecność zostanie zautentyfikowana przez przyłożenie tagu RFID do czytnika. Serwer ma następujące zadania: stanowi sprzętowy watchdog układu - kontroluje, czy ESP skomunikuje się przynajmniej raz na 4 godziny oraz oczywiście wysyła powiadomienia mailowe o detekcji. Powiadomienia mailowe są dwa - pierwsze zawsze po wykonaniu dwóch zdjęć (chyba że wcześniej nastąpi autentykacja), kolejne to już transfer wszystkich zdjęć jakie urządzenie zdążyło wykonać i przesłać do wyjścia z pętli. Jeśli uwierzytelnię się przez zeskanowanie breloka RFID, to drugi mail ze zdjęciami nie jest wysyłany - obrazki usuwane są z serwera. Jaką rolę ma w tym Arduino, skoro wszystko ogarnia ESP? Prostą, zabrakło mi pinów w ESP, żeby podłączyć wszystkie peryferia 🙂 czytnik RFID komunikuje się po SPI, więc zabiera ich sporo. Arduino jest interfejsem, który odczytuje i przechowuje UID odczytanego tagu, a na żądanie (otrzymane z ESP przez Serial), podaje tę wartość. Dodatkowo mierzy napięcie baterii (również w odpowiedzi na komendę Serial) oraz daje akustyczny sygnał buzzerem, gdy odczyta tag. Nie bawiłem się nawet w usypianie Arduino. Jest ono podłączone do masy przez tranzystor i ESP załącza je sobie przy starcie i wyłącza gdy nie jest już potrzebne. Ciekawym problemem, który pojawił się pod koniec realizacji projektu było fałszywie pozytywne wzbudzanie czujnika ruchu, gdy ESP wybudzało się "z timera". W Internecie były dziesiątki wątków sygnalizujących ten problem z modułem HC-SR501. Dwa największe tropy to było zasilanie (spory pobór prądu przy starcie ESP, gdy łączy się z WiFi) oraz sam sygnał WiFi. To drugie było łatwiejsze do zdebugowania i okazało się od razu celnym strzałem. Pomogło stworzenie ekranu z folii aluminiowej wokół tylnej części modułu PIR. W montażu wspomagałem się drobnymi elementami, które sam projektowałem i drukowałem w 3D - panel przedni, tylna pokrywa PIR, uchwyt montażowy baterii, ramka montażowa czytnika RFID. Żeby było trochę druciarstwa to w niektórych miejscach wspomógł mnie hot-glue i... sznurek. Oprogramowanie ESP32-CAM - Micropython Raspberry Pi (serwer) - Python Arduino - C++ (Arduino) Jeśli ktoś jest zainteresowany, mogę upublicznić repozytorium na Githubie. Jeszcze tego nie zrobiłem, bo musiałbym wyczyścić kod z danych osobistych, a najlepiej przenieść te zmienne do oddzielnego pliku. Zdjęcia front wnętrze bonus - jednooki Project Manager Wydawało mi się że mam gdzieś zdjęcie z zamkniętą obudową, ale nie znalazłem. W sumie wygląda to prawie jak oryginalna obudowa, bo oprócz wystających z panelu frontowego obiektywu kamery i czujnika ruchu, na zewnątrz nie ma żadnych elementów. fot. Kradex

Hej wszystkim! Jako, że posiadam własnoręcznie zbudowanego campera i chciałbym w najbliższym czasie pokusić się o stworzenie systemu IoT, który pozwalałby mi na sterowanie bezprzewodowo, również przez internet, różnymi jego podzespołami. Jak to zwykle bywa przy dużych projektach - czym więcej się czyta, tym mniej się wie, więc postanowiłem, że spróbuję napisać do Was, być może ktoś mnie nakieruje co muszę wiedzieć 🙂 Ogólny zarys jest taki - system musi mieć serce (tudzież mózg ;)) - tutaj natknąłem się na takie platformy jak arduino, raspberry pi, czy ESP32. Nie chcę, żeby całość pobierała więcej energii niż musi, a podzespoły były jak najtańsze i dawały najwięcej możliwości rozbudowy/modyfikacji. Odpadają więc dosyć powszechnie stosowane w branży urządzenia typu sonoff, czy tuya. Do centrali podłączone miałyby być konkretne czujniki (jak poziomu wody, otwartych okien/drzwi, itp.), odbiorniki (przekaźniki sterujące urządzeniami zarówno na 12v jak i na 230v), piloty (sterowanie oknem dachowym - podczerwień, sterowanie ogrzewaniem postojowym - pilot radiowy), oraz silniki elektryczne (zawór spustowy szarej wody). Najbardziej przeraża mnie mnogość rozwiązań oprogramowania - z tego co się dowiedziałem są rozwiązania płatne typu Arduino Cloud, albo open source, jak Thinx. Ja chciałbym coś, co wymaga jak najmniej fizycznego programowania (choć jeśli to konieczne, to nie odrzucam i takich rozwiązań), oraz ma możliwość zastosowania czytelnej aplikacji na smartfona, komputer i tablet. Pytań i wątpliwości jest oczywiście więcej, ale może na podstawowe tego co przedstawiłem, ktoś będzie w stanie polecić jakieś rozwiązania, za co z góry dziękuję.😉