RFM

Dokładnie. Brakuje atrybutu static.

PDF są w tym przypadku lepsze niż bitmapy bo można skalować bez straty jakości.

W obliczeniach uwzględniaj wewnętrzne napięcie odniesienia. Poza niezbyt precyzyjnym pomiarem problemów nie miałem ale nie próbowałem na Bluepill tylko na NUCLEO. W Bluepill często są podróby, szkoda na to nerwów. W NUCLEO masz programator/debuger, który w przeciwieństwie to chiński klonów, możesz zmienić za darmo i legalnie w J-LINK https://mikrokontroler.pl/2016/05/06/stlinkreflash-interfejs-j-link-w-zestawach-stm32-nucleo-i-discovery/ Masz więc porównanie, NUCLEO z ORYGINALNYM STM32 i programatorem St-Link V2-1 za 55zł (sam St-Link V2-1 ok 50zł kosztuje) vs Bluepill z najprawdopodobniej podróbą STM32 za 13zł do tego musisz dokupić programator. Najtańszy klon St-Link V2 (bez -1) to 13zł, razem 26zł. Niby połowa ceny NUCLEO ale 3 breakpointy vs 8192 w J-Link to przepaść.

Kupił bym, ale u mnie nie ma paczkomatu

ESP to nie potężny serwer aby kombinować z zaawansowanymi rozwiązaniami. Do takich rzeczy użyj "maliny". Obsługuje ale na komputerze na, którym jest uruchomiona czyli na komputerze klienta. Naturalnie wszelkie "antyświrusy" będą "krzyczeć". Co robi skrypt javascript, że jest niezbędny?

Sprawdzaj z jakiego IP wysłano dane.

W przykładach do biblioteki dla ESP masz zarówno serwer jak i klienta tak TCP jak i UDP. Przykłady działają poprawnie. Pobaw się nimi, pomierz czasy, gdy serwer jest w sieci i gdy go nie ma. Przeczytaj o różnicach w TCP i UDP. Jak potrzebujesz potwierdzeń a zależy na szybkości działania pętli głównej to użyj UDP i potwierdzaj ramki przez ICMP albo UDP. Jak petla główna moze "wisieć" 5 sekund użyj TCP.

Nie ma komendy jak w UART wyślij / odbierz. Zacząłbym od tego, że niepotrzebnie używasz TCP. Przez to musisz postawić serwer, na drugim ESP clienta. Wiesz, ze jak client się nie połączy to ESP "zawiśnie" na 5 sekund? Użyj UDP. Jak koniecznie chcesz sterować przekaźnikami przez URL to ok, postaw serwer ale do komunikacji pomiędzy modułami użyj UDP. Wiesz czym się różni TCP od UDP? PS. Widzę, że tak jak typ zmiennoprzecinkowy jest nadużywany przez Arduino, int zamiast unit8_t, tak w ESP nadużywane jest połączenie TCP. Robiłem porównania czasu wykonani funkcji wysyłania tych samych danych przez TCP i UDP. TCP to 100..200ms (o ile wszystko jest ok, bo jak źle to 5000ms), UDP 700..800us! Widać różnicę?

Cienkie te ścieżki. Masę warto by wylać.

Dobrze kombinujesz ale można to jeszcze przyspieszyć umieszczając w init0 czy 1 pamiętając, że R1 nie ma (może nie mieć) wartości 0 i jeśli będzie potrzeba trzeba w ASM zrobić wstawkę np XOR r1,r1. W .init3 R1 już == 0 ale wcześniej wykona się parę rozkazów. Co dokładnie robią init? .init0: Jeśli ją zdefiniujemy wykona się zaraz po resecie (wektor pod adresem 0). .init1: Niezdefiniowana, dla użytkownika. .init2: Używana przez C, zeruje R1 i SREG, inicjalizuje stos: 0000008c <__ctors_end>: 8c: 11 24 eor r1, r1 8e: 1f be out 0x3f, r1 ; 63 90: cf ef ldi r28, 0xFF ; 255 92: d0 e1 ldi r29, 0x10 ; 16 94: de bf out 0x3e, r29 ; 62 96: cd bf out 0x3d, r28 ; 61 .init3: Niezdefiniowana, dla użytkownika. Od tej sekcji bezpiecznie jest umieszczać kod w C, ponieważ R1 i stos jest już zainicjalizowany. .init4: Zeruje sekcję /bss oraz kopiuje wartości przypisane zmiennym z pamięci flash do ram. 0000009c <__do_copy_data>: 9c: 11 e0 ldi r17, 0x01 ; 1 9e: a0 e0 ldi r26, 0x00 ; 0 a0: b1 e0 ldi r27, 0x01 ; 1 a2: ea ec ldi r30, 0xCA ; 202 a4: f0 e0 ldi r31, 0x00 ; 0 a6: 00 e0 ldi r16, 0x00 ; 0 a8: 0b bf out 0x3b, r16 ; 59 aa: 02 c0 rjmp .+4 ; 0xb0 <__do_copy_data+0x14> ac: 07 90 elpm r0, Z+ ae: 0d 92 st X+, r0 b0: a0 30 cpi r26, 0x00 ; 0 b2: b1 07 cpc r27, r17 b4: d9 f7 brne .-10 ; 0xac <__do_copy_data+0x10> Dla mikrokontrolerów z pamięcią programu większą niż 64kB przy kopiowaniu sekcji .data dba o odpowiednie ustawienie rejestru PAMPZ. .init5: Niezdefiniowana, dla użytkownika. .init6: Niezdefiniowana w C, używana w C++. .init7: Niezdefiniowana, dla użytkownika. .init8: Niezdefiniowana, dla użytkownika. .init9: Skok do main(): b6: 0e 94 61 00 call 0xc2 ; 0xc2 <main> ba: 0c 94 63 00 jmp 0xc6 ; 0xc6 <_exit> 000000be <__bad_interrupt>: be: 0c 94 00 00 jmp 0 ; 0x0 <__vectors> 000000c2 <main> Jest jeszcze .fini .finit9: Nie używany. definiowanych przez użytkownika. Tu nastąpi skok po wykonaniu exit (). .fini8: Nie używany. definiowanych przez użytkownika. .fini7: Nie używany. definiowanych przez użytkownika. .fini6: Niewykorzystane dla programów w C, ale wykorzystywane do destruktorów w programach C ++. .fini5: Nie używany. definiowanych przez użytkownika. .fini4: Nie używany. definiowanych przez użytkownika. .fini3: Nie używany. definiowanych przez użytkownika. .fini2: Nie używany. definiowanych przez użytkownika. .fini1: Nie używany. definiowanych przez użytkownika. .fini0: Przechodzi w nieskończoną pętlę po zakończeniu programu. 000000ca <_exit>: ca: f8 94 cli 000000cc <__stop_program>: cc: ff cf rjmp .-2 ; 0xcc <__stop_program> ale w Arduino nigdy się nie wykona, bo wyjście z loop powoduje ponowny skok do niego bo loop() znajduje się w wiecznej pętli (może razem z setup? Nie pamiętam).

Który pin konkretnie, bo zasadniczo, w AVR sprzętowo się nie da. Można skrócić ten czas przez: wyłączenie bootloadera i skrócenie czasu resetu na min (domyślnie w Arduino są chyba 64ms). Inne rozwiązanie rezystor podciągający ale nie z każdym pinem to wyjdzie, np RX jest połączone z mostkiem USB i wiele zależy co on robi po czy w czasie resetu.

Czy "u8g2.drawCircle" wykonuje operację na wyświetlaczu czy w buforze w RAM?

Projekt bardzo ciekawy zwłaszcza wykorzystanie kamery bo przeważnie w przypadku liczników wykorzystywana jest dioda sygnalizująca zużycie energii. U siebie problem rozwiązałem licznikiem ORNO-514 (504 wariuje przy małych mocach) + WemosD1. Mam nie tylko informację o sumarycznym zużyciu energii ale także chwilowej mocy zarówno czynnej jak i biernej, napięciu, prądzie, współczynniku mocy http://es2.noip.pl:83/ Dane zapisuję w plikach CSV co 10 sekund na serwerze lokalnym i w Internecie więc nie ma problemu aby zrobić wykres w arkuszu kalkulacyjnym. Niewątpliwa zaleta jest pobór prądu poniżej 1W (ORNO + ESP) w porównaniu do RPi (2..3W). Samo RPi jest droższe niż ORNO + ESP a trzeba jeszcze doliczyć koszt kamery i karty SD, zasilacza (niewątpliwie dla RPi zasilacz będzie droższy niż dla ESP). Więcej o moim rozwiązaniu można przeczytać na Forbot

Analizując zasadę tworzenia "obrazu" wnioskuję, ze autor konstrukcji brał wzorzec z drukarek igłowych. Zapomniał jednak, ze tam kolumna (w ramach wiersza) jest generowania w jednej chwili. Najprostsza zmiana w programie, która znacznie przyspieszyłaby tworzenie obrazu, to rysowanie kolumnami. Dzięki temu oszczędzany jest czas na poruszanie głowicy (zasobnika). W praktyce można przyjąć, że oszczędzamy czas przeznaczony na przesunięcie głowicy = rozdzielczość X * rozdzielczość Y / 2 (dzielimy na 2 bo jak w igłówkach, rysowanie odbywa się przy ruchu głowicy w obie strony). Nie widziałem oryginalnego filmu, nie wiem ile czasu głowica przesuwa się z jednego końca do drugiego i jaka jest rozdzielczość obrazka, ale z tego co widziałem, można szacować, że nie chodzi o przyrost szybkości rzędu 10% a raczej 100...200%.

Naturalnie ale w wątku jest mowa o Arduino co najczęściej jest rozumiane jak AVR. Nawet jak nie AVR to Arduino libs. Znasz biblioteki dla Arduino, które obsłużą DMA2D czy choćby DMA do transferu danych do sterownika wyświetlacza z wykorzystaniem FCM albo wbudowany sterownik wyświetlacza np w F429? Ja nie znam i nigdy o czymś takim nie słyszałem natomiast dla FT8xx EVE wygeneruje kod dla Arduino.