logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Wydajniejszy niż ESP32 MCU do obsługi UDP i parsowania pakietów

mateos2 13 Sie 2024 14:37 2058 41
Najlepsze odpowiedzi

Jak przyspieszyć odbieranie broadcastów UDP i parsowanie pakietów na ESP32/Arduino, żeby nie gubić ramek przy wielu termostatach?

Największy zysk da poprawa stosu i parsera, a nie samo szukanie „szybszego MCU”; w tej skali sensowniejszy może być ESP-IDF albo nawet Raspberry Pi niż czyste Arduino [#21191019][#21192167] W Arduino SDK dla ESP32 domyślny UDP recvm mailbox ma rozmiar 6, a zwiększenie `CONFIG_LWIP_UDP_RECVMBOX_SIZE` do 64 wymaga ESP-IDF; Arduino można użyć jako komponentu, ale wtedy trzeba rekompilować cały zestaw [#21191373][#21192167] W samym parsowaniu warto wyrzucić `malloc`, kopiowanie do `String`, `substring()` i wielokrotne `indexOf()`, a pracować bezpośrednio na `char*` przez `strstr()` albo użyć `std::string_view`, bo to ogranicza alokacje i fragmentację sterty [#21190737][#21190975] Padła też uwaga, że broadcast UDP po Wi‑Fi jest dużo wolniejszy i bardziej zawodny niż UDP wysyłane na konkretny adres IP, więc jeśli da się zmienić sposób nadawania, to jest to najlepsza poprawka [#21191464] Jeśli zostajesz na ESP32, trzeba liczyć się z ograniczeniami arduino/lwIP i możliwą potrzebą przejścia na bardziej „serwerowy” stos sieciowy [#21191019][#21192229]
Wygenerowane przez model językowy.
REKLAMA
  • #1 21189769
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    Witajcie

    Mam pracujący moduł ESP S3 który zbiera dane z 40 termostatów Wi-Fi które rozgłaszają swoje odczyty co sekundę broadcastem UDP. Moduł odbierają pakiety, parsuje i statystyki przekazuje do BMS (rs485) I do serwera WWW (http API)

    Działa to dobrze, ale czas parsowania pakietu UDP jest duży - nawet 500us, więc dołożenie kolejnych termostatów zwiększy problem przegapienia pakietów.
    (Zakładam że 500us to świetny wynik i ciężko będzie go optymalizować - pozostaje szybszy MCU)

    Próba podmiany esp32 na Arduino opta 485 podłączone po Ethernet skończyła się porażka - moduł zalany broadcastami UDP przestaje odpowiadać.

    Czy znacie może inny moduł lub wersję która szybciej poradzi sobie z odbieraniem UDP I parsowaniem?
    Parsowanie to szukanie w string kluczy i wartości.
    Platforma to oczywiście Arduino.
  • REKLAMA
  • #2 21189788
    JacekCz
    Poziom 42  
    Posty: 8670
    Pomógł: 760
    Ocena: 1460
    mateos2 napisał:
    która szybciej poradzi sobie z odbieraniem UDP I parsowaniem


    To są dwa głęboko odmienne zagadnienia, nie powinno się mówić o nich "na jednym oddechu".
    Jedno ma dużo do sprzętu (+systemu operacyjnego w przypadku gdyby takowy występował) i nic do kodu aplikacji, drugie 100% kod użytkownika i żaden udział sprzętu


    mateos2 napisał:
    Platforma to oczywiście Arduino.


    Dobra okazja by to spie....
    Jeśli jest to typowa filozofia Arduino, z delayami, odpytywaniem portów w pętli (a nie przerwania), to zabija większą aktywność

    Dodano po 2 [minuty]:

    mateos2 napisał:
    Zakładam że 500us to świetny wynik i ciężko będzie go optymalizować

    mateos2 napisał:
    Parsowanie to szukanie w string kluczy i wartości.


    Hmmm, naiwny kod w stylu Arduinowskim może być hamulcem.
    Nie widząc kodu, odpowiedź brzmi "niekoniecznie" / "to zależy"
  • REKLAMA
  • #3 21189810
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    JacekCz napisał:
    Dobra okazja by to spie....
    Jeśli jest to typowa filozofia Arduino, z delayami, odpytywaniem portów w pętli (a nie przerwania), to zabija większą aktywność


    Jak napisałem - wykorzystuje stack TCP I proste parsowanie stringa. Nie ma w tym magii, proste C portowalne na wiele platform.

    przyklad kodu parsowania:
    
    void parseudp(AsyncUDPPacket packet) {
    long sn ;
    int pos;
    int pose;
    int rssi;
    String valt; 
    
    char* tmpStr = (char*) malloc(packet.length() + 1);
    memcpy(tmpStr, packet.data(), packet.length());
    tmpStr[packet.length()] = '\0'; 
    String data = String(tmpStr);
    free(tmpStr);
    
        pos = data.indexOf("\"sn\"",pos)+6;
        pose = data.indexOf(",",pos)-1;
        valt = data.substring(pos+5,pose);
        sn = valt.toFloat();
    


    uzywana klasa String poniewaz i tak wartosci sa potem jako string wysylane do serwera (zeby uniknac string -> float -> string)
  • REKLAMA
  • #4 21189871
    pikarel
    Poziom 39  
    Posty: 4960
    Pomógł: 407
    Ocena: 1821
    Skoro to tylko odczyt, bez potrzeby szybkiej reakcji zwrotnej dla jakiegoś sterownika grzałek/silników - to odczyt jednego czujnika może trwać nawet 20ms (tyle, co jedna klatka w TV) i nawet tego nie zauważysz a odświeżanie danych z odczytu na wyświetlacz może być co 10-20s, bo nic od tego nie zależy.
  • #5 21189898
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    Ale chodzi o to że nie robię żadnego odczytu tylko wyłapuje komunikaty termostatów.
    Ustawiam ttl na 120s i jeśli termostat nie wysyła nic od 120 sekund to go usuwam z listy.
    Aktualnie niektóre termostaty są wyłapywane nawet po 15 sekundach czyli dołożenie kolejnych zrobi więcej ramek UDP, więcej czasu na analizę i zaczną wypadać.

    Sterownik steruje grupowo pompami ciepła i może to powodować ich stop i start z błędnych powodów.

    Wpływu na wysyłanie ramek nie mam więc MCU musi wyłapywać możliwie wszystkie pakiety
    Np 40 termostatów wyśle pakiety w 100ms i chciałbym jak najwięcej wyłapać
  • REKLAMA
  • #6 21189962
    lopr_pol
    Poziom 32  
    Posty: 1691
    Pomógł: 161
    Ocena: 476
    Serio potrzebna Ci jest temperatura co 1sek.? Kto robił te termostaty, że tak sieją komunikacją? Ja bym ignorował odczyty częstsze niż 2-5min i tyle.
  • #7 21190241
    pikarel
    Poziom 39  
    Posty: 4960
    Pomógł: 407
    Ocena: 1821
    Cytat:
    dane z 40 termostatów Wi-Fi które rozgłaszają swoje odczyty

    Po co robisz odczyt tych termostatów?
    Dla zabawy, czyli dla popatrzenia sobie na nie?
  • #8 21190270
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    lopr_pol napisał:
    Kto robił te termostaty, że tak sieją komunikacją?

    Chińczyk :) czasami tak jest że zastajesz rozwiązanie i musisz się dopasować

    Dodano po 3 [minuty]:

    pikarel napisał:
    Po co robisz odczyt tych termostatów?

    Ponieważ odczyt z nich służy do sterowania ogrzewaniem, wentylacja i chłodzeniem biurowca.
    Znając termostaty i kubature która obsługują można dobrać minimalny punkt pracy systemów oszczędzając klientowi potężne kwoty na rachunkach.
  • #9 21190357
    pikarel
    Poziom 39  
    Posty: 4960
    Pomógł: 407
    Ocena: 1821
    Ty wiesz, do czego służy termostat, jaka jest jego rola?
    Wiesz, jak złożone mają algorytmy sterowania wewnątrz własnego procesora?
    Ty patrzeniem na odczyt z ich pracy - bo mają łajfaj - chcesz oszczędzać?
    Dobre.
  • #10 21190400
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    pikarel napisał:
    Wiesz, jak złożone mają algorytmy sterowania wewnątrz własnego procesora?


    Ale rozumiem że to ironia?
    Algorytm maja na 3 linijki kodu:) symulator bimetalu

    pikarel napisał:
    Ty patrzeniem na odczyt z ich pracy - bo mają łajfaj - chcesz oszczędzać?

    Nie przeczytałeś mojego posta
  • #11 21190737
    michal.zd
    Poziom 31  
    Posty: 1615
    Pomógł: 83
    Ocena: 262
    mateos2 napisał:
    JacekCz napisał:
    Dobra okazja by to spie....
    Jeśli jest to typowa filozofia Arduino, z delayami, odpytywaniem portów w pętli (a nie przerwania), to zabija większą aktywność


    Jak napisałem - wykorzystuje stack TCP I proste parsowanie stringa. Nie ma w tym magii, proste C portowalne na wiele platform.

    przyklad kodu parsowania:
    
    void parseudp(AsyncUDPPacket packet) {
    ...
    char* tmpStr = (char*) malloc(packet.length() + 1);
    memcpy(tmpStr, packet.data(), packet.length());
    tmpStr[packet.length()] = '\0'; 
    String data = String(tmpStr);
    free(tmpStr);
    
        pos = data.indexOf("\"sn\"",pos)+6;
        pose = data.indexOf(",",pos)-1;
        valt = data.substring(pos+5,pose);
        sn = valt.toFloat();
    


    uzywana klasa String poniewaz i tak wartosci sa potem jako string wysylane do serwera (zeby uniknac string -> float -> string)

    Trochę żeś przekombinował. Tyle alokacji pamięci aby wyłuskać jedną daną.
    Pakiet przychodzi jako pewnie void*, wyszukaj pozycji funkcją strstr, które działają jak indexof, wówczas nie będzie dwóch alokacji zasobów. Zawsze to trochę mikrosekund zyskasz.

    Co do pierwotnego pytania, możesz przenieść kod nanrpi zero W, cena bardzo zbliżona, ale ESP32 też ma sporą moc obliczeniową. Możliwe że framework Arduino go zabija. Czy on nie jest oparty na rtos?

    Dodano po 7 [minuty]:

    mateos2 napisał:
    40 termostatów wyśle pakiety w 100ms i chciałbym jak najwięcej wyłapać

    Stos powinien trzymać je wszystkie do momentu odczytu.
    Pomysł na odrzucanie pakietów pochodzących z tego samego czujnika jest dobry. Znasz z którego gniazda dp pakiet przychodzi, notuj czas i odrzucaj resztę wg licznika lub timera
  • #12 21190771
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    michal.zd napisał:

    Trochę żeś przekombinował. Tyle alokacji pamięci aby wyłuskać jedną daną.


    wyciagam 6 danych z kazdego pakietu UDP - format jest niestabilny (JSON'o podobny) , stabilne sa tylko klucze
    alokacja pamieci ani fragmentacja mnie nie boli - jest zapas
    praca na typie char niewiele przyspieszyla wiec zostawilem String

    popatrze jak dokladnie te pakiety sa obslugiwane i najwyzej jakas kolejke FIFO sprobuje zrobic
    albo wreszcie sie wezme i oddeleguje parsowanie na inny rdzen niz obsluge TCP :) ale wtedy zegnaj latwa portowalnosc
  • #13 21190777
    pikarel
    Poziom 39  
    Posty: 4960
    Pomógł: 407
    Ocena: 1821
    Dla wyjaśnienia; termostat to urządzenie autonomicznie stabilizujące ustaloną temperaturę przez obsługę urządzeń zapewniających tę stabilizację, np. silniki, grzałki. Niektóre termostaty wyposażono w komunikację dla zdalnego odczytu tej temperatury.
    Ty masz kłopot z jej odczytaniem, poza tym twój ESP nie steruje zwrotnie którymkolwiek z termostatów.

    To, o co pytam, to nie ironizowanie; dopytuję, po co to robisz, bo jeśli nie do sterowania, to tylko dla zabawy w odczyt, "bo można".

    Systemy ze sterowaniem ze zdalnego pulpitu mają własne programy obsługi do tego, z autoryzacją serwisowania, bez dostępu do parametrów bez tej autoryzacji.
  • #14 21190810
    JacekCz
    Poziom 42  
    Posty: 8670
    Pomógł: 760
    Ocena: 1460
    mateos2 napisał:
    alokacja pamieci ani fragmentacja mnie nie boli - jest zapas
    praca na typie char niewiele przyspieszyla wiec zostawilem String


    Ciężkie punkty zagadnienie są nie tam, gdzie je dostrzegasz.
    Alokacja to nie tylko "sumaryczne zużycie pamięci", ale każda "sztuka" musi być obsłużona w managerze, np zwalnianie kosztuje niebanalny czas. I to ten czas najcenniejszy, kiedy jest najgoręcej.
    Powoływanie nowego Stringa, każdej sztuki, to samo. Każdy widoczny powołany String, substr() itd ...

    michal.zd napisał:
    Trochę żeś przekombinował. Tyle alokacji pamięci aby wyłuskać jedną daną.

    michal.zd napisał:
    Możliwe że framework Arduino go zabija.


    Uzasadnione przypuszczenia

    Dodano po 8 [minuty]:

    mateos2 napisał:
    praca na typie char niewiele przyspieszyla wiec zostawilem String


    Można pięknie na char taki temat zoptymaliować. O ile nie jestem zwolennikiem C, to w takich limitowanych zastosowaniach ma perspektywy
    Cały odbiór do tych kilku znaków danych wyjściowych bez / z jedną alokacją

    Nie miałeś znaczącego zysku, bo nie jest to dobrze zrobione. Ratujcie, silniejszy procesor potrzebny.
  • #15 21190884
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    JacekCz napisał:
    Nie miałeś znaczącego zysku, bo nie jest to dobrze zrobione. Ratujcie, silniejszy procesor potrzebny.


    oczywiscie ze tak , ale .... $ vs czas
    wydanie na kazdy MCU 100-300zl jest dla mnie czasem tansze niz optymalizacja kodu :)
    przy 10 sztukach produktu rocznie optymalizacja jest za droga

    czasy gdy chcialo mi sie wciskac kod ze stosem TCP na arduino uno to juz przeszlosc - teraz bardziej szanuje czas + jesli kiedys komus przyjdzie kod rozwijac to latwiej znalezc czlowieka co ogarnie string w arduino od takiego co ogarnie czysty C
  • #16 21190913
    JacekCz
    Poziom 42  
    Posty: 8670
    Pomógł: 760
    Ocena: 1460
    mateos2 napisał:
    przy 10 sztukach produktu rocznie optymalizacja jest za droga


    Kod który mam w wyobraźni to żadna hackerska optymalizacja, tylko normalna porządna znajomość C, wcale nie większa ilosc linii kodu
    Ja to mam niedzisiejsza mozę zasadę: nie uprawiam komerchy na narzędziach których nie znam profesjonalnie (nie mówię o doskonałosci, bo ta nie istnieje)
    W moim świecie nietyczne by było jakbym dokonywał operacji wyrostka, komercyjnie grał na gitarze, PROGRAMOWAŁ W JĘZYKACH których nie znam naprawdę porządnie (PHP, JS, Basiki)

    mateos2 napisał:
    jesli kiedys komus przyjdzie kod rozwijac to latwiej znalezc czlowieka co ogarnie string w arduino od takiego co ogarnie czysty C


    Nie wyobrażam sobie procesjonalnego pracownika, który będzie komercyjnie programował arduino, i nie znał C. Ale pewnie jestem niedzisiejszy
    Róbmy kiszkę bo ktoś to będzie kontynuował (a ja kontynuuję). Typowe argumenty w klimatach arduino
  • #17 21190918
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    JacekCz napisał:
    mateos2 napisał:
    przy 10 sztukach produktu rocznie optymalizacja jest za droga

    Ja to mam niedzisiejsza mozę zasadę: nie uprawiam komerchy na narzędziach których nie znam profesjonalnie (nie mówię o doskonałosci, bo ta nie istnieje)


    niestety zabawa w BMS'y wymaga bycia jednoczesnie - automatykiem, koderem ,elektrykiem, elektronikiem, hydraulikiem, pompiarzem, inzynierem PV, inzynierem HVAC
    wszytkiego po trochu, czyli nic gleboko - regula 80/20
  • #18 21190927
    michal.zd
    Poziom 31  
    Posty: 1615
    Pomógł: 83
    Ocena: 262
    mateos2 napisał:
    tansze niz optymalizacja

    Wybacz, ale to nie jest dobre podejście. Od razu trzeba mieć na uwadze narzuty cppi odpowiednio dobrać narzędzie do możliwości.
    To jest jakby nie było procesor bez mmu, akurat klasa string bez ciągłej alokacji pamięci niewiele może.
    Ale w twoim przypadku, mając wszystko już w pamięci, bez sensu jest przerzucać to kilkakrotnie, oprzyj to o dostępne funkcje z c, lub napisz klasę string działającą na gotowch danych. Swego czasu tak zrobiłem, wlasna implementacja klasy string działająca na już zaalokowanym buforze, dodane potrzebne mi funkcje. Akurat niewiele potrzeba.

    Dodano po 6 [minuty]:

    mateos2 napisał:
    kiedys komus przyjdzie kod rozwijac

    Jeśli kod będzie prosty i przejrzysty, wówczas nie masz się o co martwić. Nie będzie to twoja wina, że do twojego kodu dobierze się "deweloper" a nie programista. W obecnej wersji kod nie jest prosty i przejrzysty, nie przeszedł by przez review.

    Dodano po 11 [minuty]:

    Wracając do tematu.
    Jeśli zakładasz rozszerzenie sterownika o kolejne czujniki, może rzeczywiście przejść od razu na inną platformę. Wybrałbym raspberry pi choćby zero W. Dodatkowy plus to wieksza stabilność produkcji, za parę lat nadal będzie jakiś minikomputer, rpi zero pewnie też, linux również, więc kod będzie można ew przekompilować na inną architekturę.
    Skalowalność w zasadzie nieograniczona, rozszerzenie funkcjonalności również.
    Co to za czujniki? Nie mają możliwości komunikacji z serwerem MQTT? Była by to najlepsza opcja.
  • #19 21190956
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    michal.zd napisał:
    Co to za czujniki? Nie mają możliwości komunikacji z serwerem MQTT? Była by to najlepsza opcja.


    czujniki TMS812 z Chin - takie juz ma klient zamontowane w calym obiekcie i podpiete - ESP8266 w srodku
    wsparcie producenta konczy sie na sprzedazy :)

    mialem do wyboru albo
    1/ podpiac sie pod wyjscie 230V kazdego - czyli 3 punktowe sterowanie
    2/ wybrac 20% reprezentatytwnych i podpiac kable
    3/ rev-enginnering

    50 czy nawet 10 punktow to setki metrow kabla do wciagania wiec wybralem opcje 3
    wyszlo ze albo bede sniffowal HTTPS, albo uzyje broadcastow UDP
    (pewnie chinczyk planowal zbiorczy system zarzadzania jakis)
    UDP jest golym tekstem wiec po prostu poszedlem w ta strone

    dzieki temu nie tylko mam info czy grzac czy chlodzic, ale takze rzeczywista temp a po numerze seryjnym porownujac mam dokladne info ile m2 czy m3 mam schlodzic czy zagrzac

    a to cenna informacja
    bo jesli mam podgrzac 20% pomieszczen o 0,2 stopnia to calkiem inne moce niz 80% powierzchni o 2 stopnie
  • #20 21190961
    michal.zd
    Poziom 31  
    Posty: 1615
    Pomógł: 83
    Ocena: 262
    mateos2 napisał:
    UDP jest golym tekstem wiec po prostu poszedlem w ta strone

    Bardzo dobry pomysł. Ciekawy jestem czy dane przypominają ramkę mqtt. Od początku jest json, czy jest kilka dziwnych znaczków?

    Dodano po 56 [sekundy]:

    mateos2 napisał:
    pomieszczen o 0,2 stopnia to calkiem
    nierealne. Mam wątpliwości czy pół stopnia histerezy można utrzymać na dużej kubaturze.
  • #21 21190975
    Konto nie istnieje
    Poziom 1  
  • #22 21190994
    michal.zd
    Poziom 31  
    Posty: 1615
    Pomógł: 83
    Ocena: 262
    khoam napisał:
    Obiekty std::string_view można również bezpośrednio tworzyć na char*,

    Dałem plusika za to. To bardzo dobry pomysł. Ciekawe czy Arduino pozwoli użyć biblioteki std.
  • #23 21190996
    Konto nie istnieje
    Poziom 1  
  • #24 21191007
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    michal.zd napisał:
    Bardzo dobry pomysł. Ciekawy jestem czy dane przypominają ramkę mqtt. Od początku jest json, czy jest kilka dziwnych znaczków?


    Są jakieś znaczki a od ~16 miejsca zaczyna się tekst "klucz": "wartość" ..

    Popatrzyłem na czasy i wygląda że coś jest nie teges z buforowaniem ramek UDP.
    Parsowanie teraz trwa 60 do 300us
  • #25 21191019
    michal.zd
    Poziom 31  
    Posty: 1615
    Pomógł: 83
    Ocena: 262
    mateos2 napisał:
    Popatrzyłem na czasy i wygląda że coś jest nie teges z buforowaniem ramek UDP.
    Parsowanie teraz trwa 60 do 300us

    Bez przejrzenia funkcji z Arduino niewiele wywnioskujesz.
    Parę lat temu, jak bawiłem się w embedded na esp8266, obsługa sieci, ramek ip, wykonywana była po wyjściu z funkcji loop(). Framework dla esp32 mial być oparty o rtos. Jak jest naprawdę ?
    W każdym razie Arduino nadaje się do prostych programów, wysłać dane z dołączonych czujników do serwera, obsłużyć przekaźniki. Ale do takiego projektu typu serwer/koncentrator lepiej użyć esp idf z rtos, jeśli masz zamiar pozostać na tym sprzęcie.
  • #26 21191021
    Konto nie istnieje
    Poziom 1  
  • #27 21191022
    michal.zd
    Poziom 31  
    Posty: 1615
    Pomógł: 83
    Ocena: 262
    mateos2 napisał:
    Są jakieś znaczki a od ~16 miejsca

    To trochę za dużo na mqtt.
  • #28 21191044
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    khoam napisał:
    jakie buforowanie konkretnie

    Bufor dla ramek UDP
    Muszę przejrzeć bibliotekę która używam: asyncudp
  • #30 21191160
    mateos2
    Poziom 13  
    Posty: 151
    Pomógł: 1
    Ocena: 7
    >>21191115
    ad1/ jak juz pisalem TMS812 - steruje obiegiem wody lodowej, ogrzewaniem podlogowym oraz przepustnica wentylacji
    ad2/ mozna, ale nie bede sie uczyl co to Tasmota i dlaczego dziala + nie bede bral odpowiedzialnosci za to ze dziala lub nie
    ad3/ z iloscia - jak zebrac 50-100 broadcastow UDP po 150 bajtow w 50-100ms

Podsumowanie tematu

✨ Użytkownik poszukuje wydajniejszego mikroprocesora niż ESP32 do obsługi UDP i parsowania pakietów z 40 termostatów Wi-Fi, które co sekundę wysyłają dane w formie broadcastu UDP. Obecny czas parsowania pakietu wynosi około 500 µs, co staje się problematyczne przy zwiększającej się liczbie termostatów, prowadząc do gubienia pakietów. Próba użycia Arduino Opta 485 zakończyła się niepowodzeniem z powodu problemów z obsługą broadcastów. Uczestnicy dyskusji sugerują różne podejścia, w tym optymalizację kodu, użycie Raspberry Pi 4 lub ESP-IDF z RTOS, a także rozważenie zmiany na UDP z konkretnym adresem IP, co może poprawić wydajność. Wskazano również na problemy z buforowaniem ramek UDP oraz na znaczenie odpowiedniego doboru narzędzi do wymagań projektu.
Wygenerowane przez model językowy.
REKLAMA