Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

p.kaczmarek2 30 Nov 2021 00:17 40290 74
Tespol
  • WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Witajcie moi drodzy.
    Przedstawię tu pierwszy na świecie tutorial programowania modułu WiFi WB2S, czyli BK7231. Moduł ten występuje w wielu urządzeniach smart home, a w internecie panuje opinia, że nie można stworzyć dla niego własnego firmware. Nic bardziej mylnego - pokażę tu krok po kroku jak można na nim uruchomić protokoły UDP, TCP, HTTP a finalnie też i MQTT. Tutorial będzie bardzo praktyczny, gdyż zakończymy na połączeniu naszego WB2S z serwerem Home Assistant poprzez MQTT! Takie "uwolnienie" WB2S pozwoli docelowy utworzyć dla niego otwarty, open source, wsad, oferujący nieograniczoną możliwość modyfikacji, rozwijania oraz niezależność od serwerów producenta.
    UWAGA: W tekście zakładam, że czytelnik zna podstawy programowania oraz działania internetu.

    Pokrewny temat o XR809
    Warto wspomnieć, że w podobny sposób opisałem już inny moduł WiFi - XR809:
    https://www.elektroda.pl/rtvforum/topic3806769.html#19447386
    SDK w obu przypadkach jest dość podobne, np. powtarza się obecność biblioteki Lwip, chociaż np. ten fajny server HTTP z XR809 SDK nie jest tutaj dostępny. Być może go przeportuję... ale zacznijmy od podstaw.

    Wnętrza urządzeń Smart Home
    Zanim zaczniemy tutorial, to jeszcze polecam zapoznać się z moją serią o wnętrzach urządzeń smart. Poniżej niekompletna (!) lista tematów:
    - BW-LT30 czyli adapter WiFi na żarówkę - test, teardown i wgrywanie firmware ESP (tutaj z przykładem Hello World dla ESP na Arduino IDE)
    - Gniazdo elektryczne sterowane przez WiFi - BW-SHP8 - uruchomienie i testy (oparte o moduł TYWE2S)
    - Test i wnętrze BW-SS3, czyli włącznika światła na WiFi od Blitzwolfa (oparty o moduł TYWE3S)
    - Gniazdo/wtyk z WiFi PS-16-M i aplikacja eWeLink/Coolkit - test i teardown (w środku siedzi luzem ESP8285)
    - SmartLife switch - test, wnętrze i programowanie włącznika światła na WiFi (podobny włącznik, ale bez RF i opis programowania go w Arduino poprzez kabelki)
    - Włącznik SC3-01 SmartLife i wgrywanie firmware ESP przez WIFI (tuya-convert/OTA) (tym razem programowanie przez WiFi, bez potrzeby otwierania obudowy, bez lutowania kabelków)
    - Włącznik WiFi QTouch wpinany tylko w przewód L - test, wnętrze, schemat (ciekawy włącznik, który zrealizowany jest na tyrystorze a nie na przekaźniku, ale też ma w środku ESP8285)
    - WiFi SmartLife ściemniacz jednokolorowego paska LED - test, wnętrze, schemat (ciekawy sterownik paska LED na tranzystorze MOSFET i WB3S)
    - SmartSwitch Tuya WL-SW01_16 16A WiFi - test, wnętrze (WB2S) (nieco większy przekaźnik na większy prąd)
    - Sonoff Basic ZBR3, czyli słynny przekaźnik w wersji na Zigbee. Wnętrze, schemat (małe urozmaicenie od WiFi)
    - Czujnik otwarcia drzwi/okna WiFi - test, wnętrze, integracja z resztą urządzeń (czujnik oparty o moduł XR809/XR2)
    - Zigbee termometr/higrometr z LCD TS0201 RSH-Z-Bee-HS01 Tuya (zasilany bateryjnie wyświetlacz temperatury/wilgotności, tym razem na Zigbee)
    - Wnętrze zegara/termometru/higrometru TH06 i inżynieria wsteczna jego protokołu (kalendarzyk na WB3S i nieco o przetwarzaniu pakietów z danymi w formacie binarnym poprzez program w języku C)
    - Czterokanałowy przekaźnik WiFi Tuya SmartLife 4CH 10A [schemat] (nieco większy sterownik, niestety na WB3S)
    - Własny otwarty firmware dla XR809 kompatybilny z Tasmota HTTP/Home Assistant (szczegółowy opis jak stworzyć własny wsad dla czujnika drzwi na XR809)
    - Dopuszkowy włącznik/przekaźnik RR400ZB/TS011F Zigbee - test, schemat - kolejny sterownik Zigbee
    - Kamera WiFi Tuya RPP06 1080P - możliwości aplikacji, test, wnętrze - tym razem dla odmiany kamera
    Dodatkowo, temat o Tasmocie i wersji DIY przekaźnika WiFi:
    - ESP8266 i Tasmota - sterowanie przekaźnikiem WiFi krok po kroku
    Dodatkowo tematy o serii Aqara (nie na WiFi, lecz na Zigbee):
    - Czujnik otwarcia drzwi Aqara WSDCGQ11LM na Zigbee - test, wnętrze, wykresy
    - Czujnik temperatury/ciśnienia/wilgotności Aqara WSDCGQ11LM - wnętrze, wykresy
    - Czujnik ruchu Aqara RTCGQ11LM - wnętrze, modyfikacja czasu odświeżania

    Przygotowanie hardware, podłączenie WB2S
    WB2S wymagać będzie tylko dwóch połączeń UART. Czyli potrzebne będą piny:
    - RX i TX (do programowania)
    - 2RX i 2TX (do sprawdzania logu wyjścia na UART z układu)
    - oczywiście masa i zasilanie, w tym przypadku zdecydowałem się wpiąć z 5V przed LDO 3.3V
    UWAGA: jeśli chcemy zasilać z USB, to musimy usunąć duży kondensator elektrolityczny znajdujący się przed LDO. Często ma on rozmiar rzędu 680uF, a taka duża pojemność podłączona na USB pobierze w momencie rozruchu za duży prąd, co skutkuje resetem urządzenia USB i problemami z programowaniem WB2S!
    Do demonstracji użyłem przekaźnika NF101A:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Ale znam też inne urządzenia z WB2S w środku, np: SmartSwitch Tuya WL-SW01_16 16A WiFi .
    Przypominam wyprowadzenia WB2S:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Aby podłączyć UART do komputera potrzebne będą dwie przejściówki, tutaj o poziomach logicznych sygnału ustawionych na 3.3V. Używam USB TO TTL HW-597.
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Przylutowane kabelki do RX i TX (pady u podstawy modułu przy PCB) oraz czerwony kabelek do 5V (przed LDO):
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Przylutowane 2RX i 2TX (malutkie testowe pady na "plecach" modułu):
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    W celu zabezpieczenia połączeń pozwoliłem użyć sobie tymczasowo kleju na gorąco:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Finalne środowisko pracy. Widać niezbędny włącznik (potrzeby przy programowaniu) oraz dwie przejściówki UART na USB, jedna do programowania, druga do odczytania wyjścia printf:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Do programowania wsadu używam BKwriter (bk_writer1.60), procedura programowania/odczytywania jest prosta. Uruchamiamy czynność w programie, po czym wyłączamy WB2S z zasilania (i tylko z zasilania) przyciskiem, a po chwili te zasilanie przywracamy. Program powinien kontynuować działanie, jak na zrzucie ekranu:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Do odczytywania informacji z UART używam RealTerm, jak na zrzucie ekranu poniżej:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Środowisko pracy gotowe! Można programować WB2S.

    Konfiguracja SDK i kompilatora
    Sukces udało odnieść mi się z wsadem który zintegrowany jest ze środowiskiem Tuya (później spróbujemy go "uwolnić" od Tuya):
    https://github.com/tuya/tuya-iotos-embeded-sdk-wifi-ble-bk7231t
    Najpierw musimy pobrać całe repozytorium. Można to zrobić poprzez git (linia komend lub klient GUI typu SourceTree):
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    ... bądź przez przeglądarkę (przycisk Code -> Download Zip):
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Wypakowujemy paczkę do, powiedzmy, C:/bk7231/ :
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Zapoznajemy się z zawartością folderu. Pod ścieżką \bk7231\tuya-iotos-embeded-sdk-wifi-ble-bk7231t-master\platforms\bk7231t\toolchain mamy miłą niespodziankę - toolchain już jest, gcc-arm-none-eabi-4_9-2015q1:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Następnie potrzebujemy środowisko linuxowe do kompilacji. Zdecydowałem się na emulowanie Linuxa na Windowsie poprzez Cygwin. Instalację Cygwina opisywałem już tutaj:
    https://www.elektroda.pl/rtvforum/viewtopic.php?p=19628606#19628606
    Instalacja Cygwina powinna zawierać make oraz python 3.8.
    Uruchamiamy Cygwina i przechodzimy do folderu SDK. Możemy wylistować jego zawartość:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Znajdujący się tam skrypt build_sh.sh zawiera wszystko co jest nam potrzebne.
    Uruchamiamy go poprzez:
    Quote:

    ./build_app.sh apps/template_demo template_demo 1.0.0

    Argumenty wskazują który projekt kompilujemy z folderu apps:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Kompilacja zajmie trochę czasu:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Jeśli otrzymujemy błąd mówiący, że nie znaleziono komendy "python", to musimy zainstalować Pythona. U mnie jest on w wersji 3.8.10. Doinstalowujemy go poprzez instalator Cygwina (wtedy tylko doda on potrzebne paczki):
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Wtedy już kompilacja powinna przebiec pomyślnie:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Rezultaty są w apps\template_demo\output\1.0.0:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Do wgrywania używamy pliku template_demo_UA_1.0.0, ale to za chwilę. UA w nazwie może sugerować UART.

    Błędy kompilacji powiązane z \r (carriage return)
    Jeśli mimo wszystko odpalenie kompilacji (build_app.sh) wciąż skutkuje u Was problemami, a problemy te powiązane są ze standardem oznaczania końca linii (znaki specjalne \n i \r), to pewnie kłopot sprawia użyty klient git.
    Klient git automatycznie konwertuje znaki przejścia do następnej linii na standard na Waszej platformie, tylko, że jeśli korzystacie z Windowsa to git przekonwertuje je na standard Windowsowy, kiedy to Cygwin oczekuje standardu linuxowego, co będzie skutkować takim błędem:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Najlepiej jest to poprawić w linii komend git - wyłączamy automatyczną konwersje CRLF i ponownie pobieramy repozytorium - git config --global core.autocrlf false:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Można też robić to ręcznie (np. poprzez Notepad++, zakładka Edit->EOL Conversion).

    Pierwsze hello world
    Kompilacja już działa, ale trzeba jeszcze jakoś zweryfikować, czy rzeczywiście możemy edytować sensownie te projekty i czy cały build przebiega pomyślnie.
    Proponuję dopisać gdzieś jakiś printf, powiedzmy słynny "Hello world".
    Można to zrobić w apps/template_demo/src/tuya_device.c w pre_device_init:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Kompilujemy, pora wgrać wsad.

    Pierwsze wgranie wsadu
    Potrzebny będzie program bk_writer1.60.exe, który załączam do tematu.
    Plik który będziemy wgrywać to template_demo_UA_1.0.0 (plik template_demo_1.0.0.bin nie zadziała, BK nie wystartuje wtedy). Wybieramy go poprzez "Browse" i klikamy "Program".
    Wybieramy odpowiedni port COM w programie.
    Następnie wyłączamy i włączamy ponownie zasilanie od modułu (ale nie wyciągając przejściówki USB UART z portu komputera).
    U mnie do tego służy ten duży przycisk który odcina +5V podprowadzone na wejście LDO 3.3V.
    Rozpocznie się kasowanie starego wsadu:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    A potem wgrywanie nowego:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Gotowe, po 18 sekundach:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Po ponownym uruchomieniu urządzenia pojawia się nasz komunikat:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Następnie WB2S automatycznie uruchomi wgrany wsad.

    Blink LED + Timery
    Każdy tutorial zaczyna się z reguły od migania diodą LED, więc tutaj też się tym zajmiemy. Migać diodą będziemy poprzez Timer uruchamiający się co sekundę. Wszystkie modyfikacje wprowadzać będziemy w tuya_device.c.
    Najpierw trzeba się gdzieś podpiąć - proponuję device_init, ta funkcja wykonuje się na starcie urządzenia:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Funkcję myInit tworzymy sami. Trzeba tam zainicjować stan pinów oraz uruchomić Timer:
    Code: c
    Log in, to see the code

    bk_gpio_config_output - ustawia dany pin w tryb wyjścia
    bk_gpio_output - ustawia wartość na wyjście danego pinu
    rtos_init_timer - tworzy timer (funkcja będzie automatycznie wywoływana co jakiś czas)
    rtos_start_timer - startuje timer
    Jeszcze tylko musimy wiedzieć który pin to który - gdzie jest GPIO24?
    GPIO24 odpowiada P24, a lokalizacje P24 poznamy z noty katalogowej WB2S:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    PWM4 to P24 czyli GPIO24, PWM5 to P26 czyli GPIO26.
    UWAGA: na niektórych modułach ESP numery GPIO różnią się od numerów wyjść pinów z układu, tu chyba tak nie jest!
    Zostało jeszcze zmieniać stan pinów i może dodatkowo coś wydrukować na UART w ramach testu:
    Code: c
    Log in, to see the code

    UWAGA: sterowanie przekaźnikiem (MY_RELAY) nie zadziała jeśli zasilacie moduł z zewnętrznego źródła 3.3V ponieważ przekaźnik zasilany jest z linii 5V (sprzed LDO).
    Rezultat:



    Odliczanie na UART też działa:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

    Podłączenie się do sieci WiFi
    Pora podłączyć się do sieci WiFi poprzez jej SSID i hasło. Hasło niestety podamy w postaci czystego tekstu - jak na razie nie komplikujemy bardziej kodu. Po połączeniu trzeba też użyć DHCP by uzyskać dynamicznie przydział adresu IP, ale większość robi za nas BK. Oto gotowa funkcja:
    Code: c
    Log in, to see the code

    Aby to się skompilowało musimy też załączyć dodatkowo jeden nagłówek:
    Code: c
    Log in, to see the code

    Tę funkcję wołamy np. z device_init.
    Na routerze możemy sprawdzić, czy urządzenie się podłączyło:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Komunikację wstępnie sprawdzamy komendą ping. Możemy użyć przełącznika -t by pingować non stop, a nie tylko kilka razy.
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Polecam w trakcie pingowania odłączyć zasilanie WB2S i sprawdzić czy straci połączenie - to w celu weryfikacji, czy rzeczywiście pingujemy nasze urządzenie, czy może coś innego.
    Ciekawostka: warto też wiedzieć, że jest bardziej zaawansowana struktura pozwalająca na połączenie z WiFi, można w niej też np. podać również BSSID:
    Code: c
    Log in, to see the code

    Ale tu omawiam tylko podstawy, więc na razie pora przejść do przesyłania pakietów po sieci.

    Serwer UDP
    Pora na coś ambitniejszego i pozwalającego na komunikację po sieci. Serwer UDP. Zaczynamy od UDP, gdyż UDP jest prostsze, jest to protokół bezpołączeniowy, nie gwarantujący dotarcia pakietu do celu. Pakiet jest wysyłany raz i w razie zagubienia nawet się o tym nie dowiemy. Połączeniowym protokołem (i oferującym retransmisje) jest TCP, który omówimy później.
    Obsługa UDP będzie odbywać się w wątku. Polecenie recv będzie blokować wykonanie wątku do momentu odebrania pakietu. Rozwiązanie to kontrastuje z "non-blocking" sockets, ale ich tutaj nie używamy.
    Code: c
    Log in, to see the code

    Sockety na WB2S wyglądają tak jak na Linuxie, więc można wzorować się na przykładach Linuxowych (a właściwie też z winsocka). Z tego też powodu nie opiszę tu jak działa 'bind', 'recv', 'recvfrom', 'select', itp. Wszystko standardowo.
    Ale nie zapominajmy o nagłówkach, tutaj są inne niż na innych platformach:
    Code: c
    Log in, to see the code

    Tak, sockety pochodzą też z LWIP.
    Przykładowo, socket tworzymy tak:
    Code: c
    Log in, to see the code

    Na bazie tego można utworzyć funkcję:
    Code: c
    Log in, to see the code

    Teraz tylko trzeba jakoś wysłać pakiet UDP do tego serwera... by go przetestować.
    W tym celu przygotowałem w C# (na platformie Windows) program wysyłający pakiet:
    Code: c
    Log in, to see the code

    Pora na test. Czy komunikacja UDP działa?
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Działa, co widać po obu stronach (WB2S i aplikacja na komputerze).


    Serwer TCP
    UDP już uruchomiliśmy, ale UDP nie nadaje się do poważniejszych zastosowań gdyż nie posiada warstwy rzetelności (reliability), nie wspiera automatycznej retransmisji pakietów. Oczywiście, możemy coś takiego samemu zaimplementować na UDP, ale po co?
    Od tego jest TCP.
    TCP pozwala utworzyć stałe połączenie z klientem, osobno mamy tu akt połączenia, przesyłu danych, oraz zamknięcia połączenia.
    Dlatego też w przypadku TCP każdy klient będzie otrzymywać własny wątek, który będzie działać dopóki połączenie nie zostanie zerwane.
    Zacznijmy od utworzenia wątku serwera TCP:
    Code: c
    Log in, to see the code

    Teraz, wątek głównego serwera.
    Code: c
    Log in, to see the code

    W momencie nawiązania połączenia TCP tworzony jest wątek obsługi nowego klienta - funkcja tcp_client_thread. Uchwyt socketu przekazywany jest do niej jako parametr. Jest to potrzebne, gdyż funkcje recv i select są tutaj blokujące (blokują wykonanie kodu dopóki czegoś nie odbiorą).
    Funkcja obsługi klienta:
    Code: c
    Log in, to see the code

    Oczywiście recv i send można używać w tej funkcji wielokrotnie. Len mniejsze lub równe 0 poinformuje nas o zerwaniu połączenia.
    Do kodu musiałem też dopisać pomocnicze funkcje, np. zdefiniowanie tcp_server_log, w razie czego pełny kod umieszczam jako załącznik na końcu tematu.
    Po stronie komputera można użyć programu Putty w trybie Raw. Komputer nawiąże połączenie z serwerem i wyśle mu to, co wpiszemy w konsoli.
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Czy komunikacja działa?
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Jak najbardziej działa, aczkolwiek widać, że zgubiłem gdzieś znak 0 (zero bajtowe, nie w ASCII), na skutek czego do odebranej wiadomości weszły "krzaczki". Nie jest to problem, możemy albo te 0 wysyłać w pakiecie, albo sztucznie dodawać na koniec po odebraniu pakietu (buff[len] = 0).

    Serwer HTTP
    Serwer HTTP też mamy gotowy, znajduje się on w bibliotece lwIP. Jedynie tym razem musimy dodać jego źródła do makefile, aby kompilator wiedział, że jego kod należy zawrzeć w projekcie.
    Dotyczy to plików httpd.c i fs.c z platforms/bk7231t/bk7231t_os/beken378/func/lwip_intf/lwip-2.0.2/src/apps/httpd.
    Dodajemy je do application.mk:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Jeśli ich nie dodamy, to będziemy otrzymywać przy kompilacji błędy linkera, przykładowo:
    Quote:

    W:\TUYA3\platforms\bk7231t\bk7231t_os/../../../apps/my_http_server_demo/src/tuya_device.c:736: undefined reference to `httpd_init'

    Teraz jeszcze trzeba wystartować server. Na razie w prosty sposób, też w device_init, wywołamy httpd_init:
    Code: c
    Log in, to see the code

    I to starcza - na WB2S stoi przykładowa strona internetowa:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

    Serwer HTTP - własna prosta strona
    Serwer HTTP z biblioteki która dostępna jest w tym SDK zbudowany jest w dość statyczny sposób i pewnie trzeba będzie go przerobić, ale i tak warto zaprezentować tu jak dodaje się nowy plik.
    Służy do tego zawartość pliku platforms/bk7231t/bk7231t_os/beken378/func/lwip_intf/lwip-2.0.2/src/apps/httpd/fsdata.c
    Zacytuję tu jego fragment:
    Code: c
    Log in, to see the code

    Mamy tu na sztywno wpisane odpowiedzi HTTP na żądanie GET o danej ścieżce. Tutaj taka odpowiedź jest razem z zawartością pliku. Co więcej, odpowiedzi te zapisane są w hex, a nie normalnie w postaci tekstu (char) który możemy łatwo odczytać. Oczywiście po zamianie wartości hex na znak ASCII możemy odczytać co jest co.
    Można łatwo "przetłumaczyć" taką tablicę bajtów na znaki ascii, po prostu wkleić je w kod C i wydrukować lub podejrzeć w debugerze np. w Visual Studio, tak:
    Code: c
    Log in, to see the code

    Więc, podejrzyjmy pełną wartość z jednego z buforów:
    Code: html
    Log in, to see the code

    Najpierw jest nazwa pliku (zakończona bajtowym zerem). Odpowiedź HTTP zaczyna się od nagłówka "HTTP/1.0", a HTML od <html>. Ten tutaj serwer nawet "nie wie" co jest czym, traktuje to jako jeden ciąg znaków.
    Nieco niżej mamy:
    Code: c
    Log in, to see the code

    Tu określane są struktury reprezentujące pliki. Te tajemnicze "12" to długość nazwy pliku na początku bufora. Przykładowo, długość "/index.html" wynosi 12 (11 znaków + 1 NULL terminating character). Trochę nie jest to wygodne, że trzeba ręcznie wpisywać tą wartość do kodu... Zobaczmy co składa się na strukturę fsdata_file:
    Code: c
    Log in, to see the code

    Mamy tu wskaźnik na następny plik (lista jednokierunkowa), wskaźnik na nazwę pliku (string zakończony znakiem bajtowe zero) oraz wskaźnik na jego dane (treść odpowiedzi na GET, razem z nagłówkiem HTTP i zawartością pliku). Dodatkowo długość i pole na flagi. Wsparcie checksum w tym miejscu jest wyłączone.
    Pierwszy plik z kolei określa ta linia:
    Code:

    #define FS_ROOT file__mytest_html

    Czy można dodać tu jakiś plik? Jak najbardziej tak. Najpierw utwórzmy jego treść, dla przykładu może to być:
    Code: html
    Log in, to see the code

    Potem zamieńmy go na zapis liczb w hex po przecinku. Można to zrobić... osobnym programem w C, który uruchomiłem na windowsie:
    Code: c
    Log in, to see the code

    Jeszcze trzeba analogicznie zamienić jego nazwę pliku - powiedzmy, "tst.html" - też na kody hex i dopisać znak 0 kończący stringa, a potem można utworzyć analogicznie tablicę z odpowiedzią na jego żądanie GET, też w fsdata.c.
    Trzeba też osobno utworzyć dodatkową instancję struktury fsdata_file i podpiąć ją do jednokierunkowej listy.
    Poniżej umieszczam pełny 'diff' tego co dopisałem do fsdata.c:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Działa - rezultat:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

    Wsparcie MQTT - niezbędna poprawka
    Pora przejść do MQTT, czyli protokołu który zapewni nam m.in. kompatybilność z Home Assistant.
    Niestety biblioteka MQTT dostępna w omawianym SDK nie jest kompletna. Brakuje w niej implementacji uwierzetylnienia klientów MQTT. Musimy to zaimplementować sami.
    MQTT też pochodzi z biblioteki lwip-2.0.2. Implementacja znajduje się w platforms\bk7231t\bk7231t_os\beken378\func\lwip_intf\lwip-2.0.2\src\apps\mqtt\mqtt.c

    Do poprawki jest funkcja mqtt_client_connect, gdyż w budowanym pakiecie nie załącza ona hasła i nazwy użytkownika, więc MQTT będzie działać tylko w trybie bez logowania.
    Skąd o tym wiem?
    Porównałem pakiety wysyłane przez WB2S (z biblioteką bez zmian) z pakietami wysyłanymi przez narzędzie do testowania MQTT (MQTT Explorer). Do podejrzenia pakietów użyłem Wireshark. Poniżej rezultaty:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    (swoją drogą - Wireshark dekoduje automatycznie pakiety MQTT, bardzo przydatna funkcja!)
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Widać, czego brakuje, prawda?
    Poniżej załączam zrzuty ekranu z moich poprawek, do pobrania całość dam na koniec tematu:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Dodatkowo trzeba jeszcze doda mqtt.c do kompilacji w application.mk:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Można spróbować kompilować, ale to jeszcze nie zadziała:
    Code:

    ../../../sdk/lib/\libtuya_iot.a(libemqtt.c.o): In function `mqtt_disconnect':
    /root/workspace_temp/EmbedSDKs/ty_iot_wf_bt_sdk_bk/ty_iot_wf_bt_sdk_bk/sdk/mid_mqtt/src/libemqtt.c:315: multiple definition of `mqtt_disconnect'
    Debug/obj/mqtt.o:W:\TUYA3\platforms\bk7231t\bk7231t_os/beken378/func/lwip_intf/lwip-2.0.2/src/apps/mqtt/mqtt.c:1346: first defined here
    collect2.exe: error: ld returned 1 exit status

    Okazuje się, że w bibliotece libtuya_iot.a już jest funkcja o nazwie mqtt_disconnect. Nie możemy mieć drugiej takiej samej nazwy, musimy zmienić nazwę tej z mqtt.c:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Biblioteka do MQTT gotowa, pora użyć jej w praktyce.

    Wsparcie MQTT - krok po kroku
    Podstawowe informacje o MQTT są w pliku readme, ale i tak je tu przytoczę. Obsługa MQTT sprowadza się do następujących kroków:
    Krok 1: Załączenie nagłóka:
    Code: c
    Log in, to see the code

    Krok 2: Alokacja klienta.
    Metoda statyczna:
    Code: c
    Log in, to see the code

    Metoda dynamiczna:
    Code: c
    Log in, to see the code

    Krok 3: Nawiązanie połączenia. Do mqtt_connect_client_info_t wpisuje się też nazwę użytkownika, hasło, itp, jak zajdzie taka potrzeba.
    Code: c
    Log in, to see the code

    UWAGA: Do sprawdzenia stanu klienta można użyć mqtt_client_is_connected(client) .
    Krok 4. Implementacja obsługi stanu połączenia (w formie callback). Jest to tak zrealizowane, ponieważ połączenie może zająć troszkę czasu a nie chcemy wtedy przecież blokować wykonania reszty naszego kodu (tak jak w przypadku blocking sockets).
    Code: c
    Log in, to see the code


    Krok 5: Implementacja callbacków odbioru danych (tzw. w MQTT "publish"). W MQTT "publish" może być w obie strony, albo od nas albo do nas:
    Code: c
    Log in, to see the code


    Krok 6: Skoro mamy odbiór, to trzeba też móc nadawać - implementacja wysyłania publish:

    Code: c
    Log in, to see the code

    UWAGA: Do treści publish możemy wpisać cokolwiek, ale np. Home Assistant korzysta tam z formatu JSON.
    Krok 7: Odłączenie/zakończenie działania MQTT:
    Code: c
    Log in, to see the code


    Wsparcie MQTT - przykład praktyczny - kompatybilność z Home Assistant
    Teraz wykorzystajmy zgromadzoną tu wiedzę i przygotujmy program, który będzie raportować o swoim stanie przez MQTT. Przykładowo możemy tak raportować pomiar temperatury. Oczywiście sam pomiar wygenerujemy losowo, przykład ten nie obejmuje niczego innego niż MQTT.
    Do demonstracji potrzebny będzie też serwer - użyję tu serwera Home Assistant, przygotowanego wedle mojego tutorialu:
    https://www.elektroda.pl/rtvforum/topic3777098.html
    Potrzebujemy nazwy użytkownika i hasła MQTT z naszego servera. Bierzemy je z ustawień Mosquitto MQTT broker:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    W kodzie reprezentuje je struktura mqtt_connect_client_info_t. Zainicjujmy ją odpowiednimi polami:
    Code: c
    Log in, to see the code

    IP serwera jest nieco w innym miejscu. Tutaj jest też ustawienie callbacków:
    Code: c
    Log in, to see the code

    Teraz treść mniej ważnych, pomocniczych funkcji:
    Code: c
    Log in, to see the code

    Najważniejsza jest funkcja wykonująca publish, czyli wysyłającą poprzez MQTT stan urządzenia.
    Dla Home Assistant zawiera ona informacje o temperaturze w postaci JSON:
    Code:

    {\"temperature\": \"45.5\"}

    W poniższym przykładzie tworzę wartość temperatury z licznika pętli przy użyciu funkcji sinus, tak by wychodziły cyklicznie te same wartości. Zobaczymy to na wykresie z Home Assistant.
    Jeśli publish się nie powiedzie, to ponawiam połączenie MQTT.
    Code: c
    Log in, to see the code

    Drugi argument w mqtt_publish to tzw. 'topic'. Powinien się zgadzać z tym, czego nasłuchujemy w HA.
    Publish musimy wywoływać sami - np. z timera:
    Code: c
    Log in, to see the code

    UWAGA: Kwestia bezpieczeństwa wywoływania funkcji tej biblioteki z innego wątku niż była uruchamiana nie została przeze mnie do końca sprawdzona.
    Po stronie Home Assistant musimy dodać wpis do /config/configuration.yaml. Informujemy tam serwer jakiego rodzaju publish nadsłuchiwać i jak go przetworzyć:
    Code:

    sensor:
      - platform: mqtt
        name: "WB2S"
        state_topic: "wb2s"
        qos: 0
        unit_of_measurement: "ºC"
        value_template: "{{ value_json.temperature }}" 

    Ważne jest, by nazwy (name oraz topic) się zgadzały, jak również by wartość wyłuskiwana z JSON ("temperature") miała zgodna z rzeczywistością nazwę.
    Jeśli mamy kilka urządzeń, to można nadać im różne nazwy i mieć różne, osobne wykresy.
    W rezultacie w Home Assistant otrzymujemy taki wykres:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Pełny kod przykładu z MQTT też jest w załącznikach.

    Download przykładów
    Poniżej zamieszczam zmodyfikowane przeze mnie SDK wraz z projektami każdego z przykładów w folderze app. UWAGA - z SDK wyciąłem toolchain bo zajmował ponad 600MB, więc musicie go pobrać z repo osobno...
    wb2s-updat...130-v1.zip Download (20.78 MB)Points: 0.5 for user
    bk_writer1...210523.zip Download (302.64 kB)

    Do zrobienia
    Zostało tu do zrobienia kilka rzeczy. Poniżej lista, kolejność przypadkowa:
    - ten serwer HTTP z użytego SDK dla WB2S jest słaby, albo go przerobię, albo sportuję serwer z SDK XR809 (którego też już uruchomiłem)
    - nie rozpracowałem zapisu do pamięci ustawień tak by WB2S pamiętał do jakiego WiFi się łączył, ale to raczej żaden problem
    - można by spróbować nieco bardziej "uwolnić" ten WB2S od środowiska Tuya bo na ten moment ono sobie chodzi w tle w pewnym stopniu. Trzeba wyczyścić plik tuya_device ze zbędnych wywołań funkcji a może nawet poeksperymentować z omijaniem bibliotek (ale w sumie bootloader nam się przyda... nie chcemy programować tego potem przez JTAG, co też jest możliwe, jeśli dobrze pamiętam)
    - nie samym WB2S świat żyje, należałoby sprawdzić co z WB3S i podobnymi

    Projekt firmware open source dla WB2S i podobnych
    Większość niezbędnych mechanizmów potrzebnych do przygotowania uniwersalnego, otwartego programowania (podobnego do np. Tasmoty) dla tych układów jest już uruchomiona.
    W związku z tym rozpoczynam projekt o tymczasowej nazwie OpenWB2S. Projekt będzie rozwijany równolegle z projektem OpenXR809, który będzie działać analogicznie, ale na układzie XR809, szczegóły tutaj: Własny otwarty firmware dla XR809 kompatybilny z Tasmota HTTP/Home Assistant.
    Wsparcie projektu - zainteresowani mogą wesprzeć projekt poprzez:
    - testowanie (za jakiś czas założę repozytorium github pod oba projekty)
    - gromadzenie informacji w jakich urządzeniach są jakie moduły (możecie wysyłać zdjęcia, itp, chociażby w tym temacie. Wiem o liście https://templates.blakadder.com/ )
    - darowiznę paypal:
    https://paypal.me/openshwprojects

    (trochę tych różnych urządzeń jest a ja docelowo chcę przetestować ich jak najwięcej, zresztą dużo już teardown umieściłem w https://www.elektroda.pl/rtvforum/forum507.html , środki pójdą na zakup kolejnych urządzeń )
    - jeśli macie jakieś np. moduły WB2S które wam zostały po zamianie na ESP12F lub uszkodzone urządzenia smart itp to mogę je przyjąć do testów (kontakt PW)
    Jest znacznie więcej podobnych modułów do WB2S, chociażby jest WB3S i też muszę go przetestować wkrótce...

    Podsumowanie
    To już drugi pozornie zamknięty moduł WiFi który udało mi się rozpracować. Z XR809 było podobnie - też nikt nie wiedział, że da się go uruchomić na niezależnym oprogramowaniu. Tutaj z WB2S było podobnie.
    Teraz planuję rozwinąć moje oprogramowanie dla obu tych modułów a wkrótce również założę dla obu projektów repozytoria github. Celem będzie zrobienie odpowiednika Tasmoty wraz ze wsparciem MQTT. Trudno jest mi powiedzieć ile to zajmie, oraz zależy to też od odzewu i zainteresowania, ale mogę już zdradzić, że kolejnym tematem jaki chcę przedstawić na forum będzie szczegółowy tutorial MQTT ale tym razem na XR809.
    Temat będzie aktualizowany i poprawiany.

    Cool? Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    p.kaczmarek2
    Level 28  
    Offline 
  • Tespol
  • #2
    blakadder
    Level 6  
    Mam dla Ciebie kilka modułów Tuya ;)

    Polecam również poszerzyć nazwę projektu, ponieważ ten sam układ Beken jest używany w innych modułach i urządzeniach innych niż tuya
  • #3
    freedomlives
    Level 1  
    Właśnie otrzymałem kilka inteligentnych wtyczek, które niestety mają ten moduł zamiast ESP. Spróbuje sflashować jeden zgodnie z twoimi instrukcjami.
  • #4
    p.kaczmarek2
    Level 28  
    blakadder wrote:
    Mam dla ciebie kilka modułów Tuya ;)


    To świetnie, jeśli jesteś zainteresowany przekazaniem modułów Tuya do testów, proszę o kontakt napisz do mnie.

    Wiem również, że niektóre moduły WB mogą być kompatybilne pinowo z modułami ESP12F, więc .... więc mógłbym użyć breakouta ESP12F do stworzenia własnej płytki deweloperskiej WB.

    blakadder wrote:

    Polecam również poszerzyć nazwę projektu, ponieważ ten sam układ Beken jest używany w innych modułach i urządzeniach innych niż tuya


    Będę. Wiem, że jest wiele modułów z dokładnie tym samym układem - BK7231T - w tym WB2S, WB2L, WB3S, WB3L, WB3S-IPEX, WBLC5, WB8P, WBLC9 itd..
    Po prostu nie podoba mi się dziś powszechne podejście „najpierw reklamuj, potem niedostarczaj”, a przy takim rozwoju na niezbadanym terytorium trudno powiedzieć z dużą dozą pewności, że moje podejście sprawdzi się również dla nich wszystkich.

    Należy pamiętać, że w tej chwili używam bootloadera UART, a nie tylko wypalam oprogramowanie za pomocą ST-link nad czystym chipem BK.

    Mimo to postaram się sprawdzić WSZYSTKIE. Po prostu muszę je jakoś zdobyć.

    Ale nie martw się, nawet jeśli podejście oparte na tuya-iotos-embeded-sdk-wifi-ble-bk7231t SDK zawiedzie, to zawsze mam opcję kopii zapasowej w postaci ALios SDK, która moim zdaniem może również z łatwością obsługiwać te moduły, ale tym razem z wymaganiami programisty ST-link.

    PS: BKwriter obsługuje również BK3435, BK3266, BK3432, BK3288 i BK3633, ale nie wydają się one tak popularne jak BK7231T.


    EDYCJA: Załączam pliki diff/patch dla poprawki MQTT niezbędnej do obsługi autoryzacji:
  • #5
    ex-or
    Level 27  
    p.kaczmarek2 wrote:
    Trochę nie jest to wygodne, że trzeba ręcznie wpisywać tą wartość do kodu...

    Nie trzeba. Gdzieś w katalogach lwip powinnien się znajdować program fsgen (czy jakoś tak) który tworzy ten filesystem ze wskazanych plików.
  • Tespol
  • #6
    p.kaczmarek2
    Level 28  
    ex-or wrote:
    fsgen (czy jakoś tak) .

    A rzeczywiście, jest makefsdata. Chyba niedoceniłem troszkę autorów tej biblioteki.
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
  • #7
    DrTFav
    Level 2  
    Świetna robota! Nie mogę się doczekać, aby zobaczyć więcej na żetonach Beken! Udało mi się wykorzystać inspirację z twojego projektu XR809, aby przejąć kontrolę nad czujnikiem wycieku wody, który wykorzystuje protokół szeregowy Tuya, wykrywanie MQTT HA i raportowanie stanu MQTT https://github.com/tony-fav/FavTuyaXR3/blob/ master/project/at_demo/main.c Protokół Tuya byłby moim pierwszym celem, aby zaimplementować jak najwięcej urządzeń z chipami Bekena używa protokołu szeregowego Tuya do sterowania dodatkowym chipem.
  • #8
    p.kaczmarek2
    Level 28  
    @DrTFav miło widzieć więcej osób korzystających z mojego samouczka. Pracowałem też kilka razy nad protokołem Tuya, na przykład tutaj:
    https://www.elektroda.com/rtvforum/topic3819498.html
    Znalazłem również inteligentny przełącznik dotykowy z innym protokołem, oparty na tekście z ,,AT-UPDATE", takim jak ciągi:
    https://www.elektroda.pl/rtvforum/topic3812227.html

    także:
    Quote:

    Próbowałem wyłączyć zarówno serwer WWW, jak i kod at_cmd i wszystko wydawało się zepsuć/przestać działać. Nie wiem, o co chodzi.

    Widzę, że robisz wszystko w pętli main() zamiast używać przerwań. Być może wątek serwera WWW jest teraz jedynym miejscem, w którym wywoływane jest odpytywanie pakietów IP (zakładając, że używają do tego sondowania).

    Gdzie mogę kupić czujnik, który posiadasz?
  • #9
    DrTFav
    Level 2  
    Kupiłem swoją lokalnie w sklepie ze sprzętem w USA, ale na AliX są niektóre z tego samego współczynnika kształtu. Oczywiście nie ma gwarancji, co jest w środku.
  • #10
    chemik_16
    Level 25  
    no widzę że pchnąłeś temat ładnie do przodu :) gratulacje.
    bk7231 to bardzo fajny układ, znacznie ciekawszy od esp8266, konkuruje spokojnie z esp32 ;)
    Kończe remont i też dołączam do programowania tego tworu, u mnie leży 10szt gniazdek tuya, docelowo chce na nich postawić
    MQTT (włącznik, miernik prądu i napięcia, led) + bramke BLE
    może też uda się przeportować tasmote

    ale priorytetowo - odciąć go od jakiejkolwiek komunikacji ze światem zewnętrznym ;)
  • #11
    khoam
    Level 41  
    chemik_16 wrote:
    może też uda się przeportować tasmote

    Kod Tasmoty w całości oparty jest na Arduino Core, więc w pierwszej kolejności ten drugi musiałby być przeniesiony.
  • #12
    DrTFav
    Level 2  
    p.kaczmarek2 wrote:
    @DrTFav miło widzieć więcej osób korzystających z mojego samouczka. Pracowałem też kilka razy nad protokołem Tuya, na przykład tutaj:
    https://www.elektroda.com/rtvforum/topic3819498.html
    Znalazłem również inteligentny przełącznik dotykowy z innym protokołem, oparty na tekście z ,,AT-UPDATE", takim jak ciągi:
    https://www.elektroda.pl/rtvforum/topic3812227.html

    także:
    Quote:

    Próbowałem wyłączyć zarówno serwer WWW, jak i kod at_cmd i wszystko wydawało się zepsuć/przestać działać. Nie wiem, o co chodzi.

    Widzę, że robisz wszystko w pętli main() zamiast używać przerwań. Być może wątek serwera WWW jest teraz jedynym miejscem, w którym wywoływane jest odpytywanie pakietów IP (zakładając, że używają do tego sondowania).

    Gdzie mogę kupić czujnik, który posiadasz?


    Jestem zdezorientowany twoim linkiem (https://www.elektroda.com/rtvforum/topic3819498.html). Protokół Tuya jest dobrze znany i udostępniają go publicznie (https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb). To nie jest coś, co musi być poddane inżynierii wstecznej w sposób, w jaki próbujesz tam. Zarówno Tasmota, jak i ESPHome mają metody radzenia sobie z tym.
  • #13
    p.kaczmarek2
    Level 28  
    DrTFav wrote:
    Jestem zdezorientowany twoim linkiem (https://www.elektroda.com/rtvforum/topic3819498.html).

    Wiem, że Tasmota obsługuje protokół Tuya, użyłem Tasmota z tym protokołem np. tutaj:
    https://www.elektroda.pl/rtvforum/topic3825966.html
    Odwołałem się nawet do tego linku: https://tasmota.github.io/docs/TuyaMCU/ w powyższym temacie.
    Powinieneś raczej zająć się moim tematem "inżynierii odwrotnej" jako ćwiczenie edukacyjne , przykład jak podejść do nieznanego protokołu UART dla początkujących, a nie jako prawdziwa próba odwrócenia go po raz kolejny, gdy jest już publiczny.

    PS: Tyle, że lubię pisać proste poradniki krok po kroku dla początkujących (ponieważ znałem i znam wielu początkujących i wiem, jak myślą i czego potrzebują), to samo robię również w przypadku tematów innych niż Tuya. Przykład: https://www.elektroda.pl/rtvforum/topic3742912.html
  • #14
    The_Digital_1
    Level 2  
    @p.kaczmarek2 Czy to możliwe, że niektóre urządzenia mogą mieć zablokowany bezpiecznik i nie można ich zaprogramować? Mam kilka przełączników wtykowych HBN BNC-60/UT152T, które wykorzystują moduł WB2S z układem BK7231. Kiedy używam narzędzia Bkwriter, nie można go flashować ani kasować. Nie wierzę, że to moja przejściówka USB na port szeregowy, ponieważ określiłem sygnały i wyglądają na czyste. Po podłączeniu VCC do chipa BKwriter natychmiast ulega awarii. Patrząc na dekodowanie RX na programującym UART otrzymam co następuje: 0xF5 0xFD 0x40 0xFF 0xF7 0xE3 0xF5 0xFD 0x40 0xFF 0xF5 0xFD 0x40 0xFF

    Dodano po 18 [minuty]:

    @p.kaczmarek2 faktycznie ignoruje ten zrzut RX, prawdopodobnie jest źle, wtedy miałem złą prędkość transmisji. Ustawienie szybkości transmisji na 115200, tak jak to zrobiłeś, wydaje się powodować wymazywanie pamięci flash, ale utknie. Patrz załączony. FYI mogę pomyślnie wykonać operację odczytu, więc znowu czuję, że konfiguracja sprzętu jest właściwa. WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

    Dodano po 4 [minuty]:

    Wygląda na to, że wykonał częściowe wymazywanie, ponieważ urządzenie już się nie uruchamia i po prostu drukuje dołączone na TX2. WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
  • #15
    ryanpavlik
    Level 4  
    Czy udało Ci się odczytać oryginalne oprogramowanie Tuya za pomocą bk_writer? Próbowałem krótko jednego z moich, ale po prostu wydawało się, że minął czas. (Próbuję odwrócić protokół UART używany przez bk_writer i podczas zagłębiania się w sam bk_writer znajduje jakieś ciekawe informacje, prościej byłoby po prostu powąchać działające narzędzie :D )

    Wiele urządzeń z tym ma wyłamany pin ,,CEN" - moje przeczucie jest takie, że jest to ,,chip enable", czyli reset - ciągnięcie do masy powoduje coś, co i tak wygląda na reset.

    BTW: UA oznacza ,,Obszar użytkownika". To jedno z oprogramowania, które wgrasz do Tuya. QIO to oprogramowanie sprzętowe "obszaru produkcyjnego". Wydaje się, że narzędzie ma preferencyjne traktowanie dla 115200, mimo że doktorzy Tuya mówią, że używa 921600.

    Szkoda, że najwyraźniej nie można kupić tego chipa poza ekosystemem Tuya (a może poza Chinami) - wygląda całkiem obiecująco.
  • #16
    ryanpavlik
    Level 4  
    Ups... Zaszedłem dość daleko w odwrocie narzędzia Beken Writer, kiedy wypróbowałem kilka różnych wyszukiwanych haseł i znalazłem tę implementację Pythona, najwyraźniej z samej firmy, ale nie na jej organizacyjnym koncie GitHub: https://github.com /tiancj/hid_download_py/blob/master/bkutils/boot_protocol.py

    Fragmenty wyglądają jak bezpośrednie tłumaczenie kodu c++, rozpoznaję liczbę parametrów i wartości...

    Cóż, lepiej znaleźć to późno niż wcale!

    Wygląda na to, że płyta, którą mam, nie reaguje na narzędzie, jednak: czy jest jakaś blokada, która zatrzymałaby odczyt? Mam inne płytki bk7231, akurat do pierwszej już przylutowałem ładne przewody muchowe...
  • #17
    p.kaczmarek2
    Level 28  
    The_Digital_1 wrote:
    Kiedy używam narzędzia Bkwriter, nie można go flashować ani kasować.

    Nie wiem, czy da się zablokować układ BK, ale pamiętam, że miałem problemy z zaprogramowaniem XR809 z niskiej jakości mostkiem USB na UART. Czy możesz spróbować użyć tego samego, który mam?
    Jeśli zasilasz swój moduł z portu USB, czy jesteś pewien, że usunąłeś duży kondensator zbiorczy, ponieważ dużych pojemności nie można podłączyć bezpośrednio do VUSB?
    The_Digital_1 wrote:
    Po podłączeniu VCC do chipa BKwriter natychmiast ulega awarii

    czy to nie działa z dźwiękiem "Urządzenie USB odłączone" z systemu Windows?

    The_Digital_1 wrote:
    BNC-60/UT152T

    Coś z tej serii? https://www.bn-link.com/products/bn-link-extr...-switches-for-purchase-new-kit-bnc-60-u116r-5
    Postaram się go znaleźć z wysyłką do Polski, ale kupuję urządzenia z wtyczkami EU...

    ryanpavlik wrote:
    Czy udało Ci się odczytać oryginalne oprogramowanie Tuya za pomocą bk_writer?

    Tak, tutaj żadnych problemów. Pamiętam też, że przeflashowałem BK oryginalnym firmware po flashowaniu własnym i też zadziałało. Zauważyłem też, że oryginalne oprogramowanie układowe (tak samo jak wygenerowane) jest zaszyfrowane i nie można na przykład zobaczyć stałych ciągów.



    ryanpavlik wrote:
    Próbuję odwrócić protokół UART używany przez bk_writer i podczas zagłębiania się w sam bk_writer znajduje jakieś ciekawe informacje, prościej byłoby po prostu powąchać działające narzędzie :D )

    Pomocna może być tutaj IDA Pro, która może również generować pseudo kod C

    ryanpavlik wrote:

    To wspaniałe znalezisko, nie widziałem go wcześniej. Mimo to, dlaczego potrzebujesz do tego kodu źródłowego, jaki jest twój cel odwrócenia protokołu programowania UART dla BK?



    Nie mogę odtworzyć problemów, które macie oboje, czy możesz mi powiedzieć, jakich urządzeń używasz do testowania w tej chwili? Spróbuję później zaprogramować WB3S i zobaczę, jak idzie. Do tej pory nie znalazłem żadnych problematycznych żetonów Beken.
  • #18
    ryanpavlik
    Level 4  
    Cóż, zanim znalazłem skrypt Pythona, moim celem było częściowo napisanie zamiennika Pythona o otwartym kodzie źródłowym dla aplikacji BK writer ?. To była również dobra praktyka z Ghidrą i asemblerem x86, więc nie wszystko poszło na marne. Właściwie miło było zobaczyć, że to, czego się nauczyłem, bardzo ściśle pasuje do portu Pythona.

    Urządzenie, które teraz podłączyłem, zostało sprzedane jako zewnętrzna inteligentna wtyczka Feit Electric, model Plug/Wifi/wp (fccid nie jest pod ręką), nie ma modułu i wyraźnie pierwotnie było esp8266.

    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

    Mam też żarówkę RGB z WB8P, którą będę musiał podłączyć i bawić się, jeszcze tego nie zrobiłem. Jestem prawie pewien, że mam tutaj co najmniej jedną rzecz z WB2S, której po prostu nie otworzyłem (inteligentne gniazdko), pogrzebię i okablowam.
  • #19
    p.kaczmarek2
    Level 28  
    ryanpavlik wrote:

    Wygląda na to, że płyta, którą mam, nie reaguje na narzędzie, jednak: czy jest jakaś blokada, która zatrzymałaby odczyt?

    Czy jesteś w stanie odebrać wydruk wyjściowy dziennika debugowania na drugim UART?

    Na zdjęciu twojej płyty znajduje się duży kondensator zbiorczy. Czy to po stronie VIN 1117-3,3V? Jeśli chcesz mieć możliwość zasilania płyty z USB 5V, to ten kondensator należy usunąć. W przeciwnym razie, gdy odłączysz i ponownie podłączysz zasilanie w celu programowania, zbyt duża pojemność --> zbyt duży prąd rozruchowy spowoduje zresetowanie portu USB i rozłączenie klucza USB do UART.

    Sprawdź też, czy jest coś dodatkowego podłączonego na liniach UART, jak dioda stanu czy coś, zdarzyło mi się raz w przypadku TYWE3S, ale nie sądzę, że tak jest w tym przypadku

    Btw: Właśnie sobie przypomniałem, że mam jeszcze jedno urządzenie WB3S! Sterownik czterech przekaźników, ten, który tutaj recenzowałem:
    https://www.elektroda.pl/rtvforum/topic3822484.html
    Muszę teraz pamiętać, gdzie to umieściłem, a także sprawdzę, czy mogę to sflashować.
  • #20
    ryanpavlik
    Level 4  
    Hmm, ten sam wynik "braku odpowiedzi" z WB8P. Podejrzewam teraz bardziej ogólny problem: czy wgrywasz firmware przez rx1/tx1 czy rx2/tx2? Jeśli nie to, to może to mój adapter uart, oparty na cp2102. Zamówiłem kilka 340 egzemplarzy, które będą tutaj w przyszłym tygodniu. Mogę spróbować mojego autobusowego pirata, jeśli pamiętam, jak go używać.

    Próbowałem też kilku różnych czasów włączania i klikania ,,odczyt": ponieważ widziałem w analizatorze protokołów, że wysyła on ,,reboot\r\n", a następnie kilkakrotnie podstawowy minimalny komunikat, próbowałem nawet podłączyć zasilanie płyty z powrotem po kliknięciu odczytu . Wyciągnąłem kondensator na urządzeniu opartym na WB8P, aby uzyskać łatwiejszy dostęp do tylnych punktów testowych, nie wyśledziłem jeszcze obwodu, ale nie widzę, jak adapter uart spada po podłączeniu zasilania.

    Muszę złożyć tutaj drugi adapter uart: drugi, którego ostatnio używałem, to manipulowanie i wypuszczanie 4.2v na linii 3.3v ? na szczęście nie usmażył tywe-3s w sztuce ściennej inspirowanej nanoliściem ostatnio używany.

    EDIT: OK, drugi uart wyświetla wszystko dobrze. Udało mi się zrzucić oprogramowanie z WB8P, bawiąc się kablem zasilającym. Pomyśl, że to było wsteczne zasilanie przez linie Uart czy coś, ponieważ czasami wydawało się, że zaczyna się uruchamiać, gdy **odłączałem** zasilanie. Bardzo się cieszę, że w końcu udało mi się to uruchomić. Teraz mogę zacząć korzystać z oprogramowania. Mam nadzieję, że unikniesz korzystania z bazy Tuya, zwłaszcza że łańcuch narzędzi i pliki makefile wydają się uszkodzone w systemie Linux/WSL i działają tylko w systemie Windows. Wiem, że istnieją już pakiety płyt Arduino, które używają FreeRTOS, więc mam nadzieję, że integracja BK7231 z FreeRTOS pozwoli mi stworzyć w ten sposób bardziej przyjazne środowisko. (arduino/platforma)
  • #21
    ryanpavlik
    Level 4  
    Aktualizacja łańcucha narzędzi: wygląda na to, że "otafix" i "encrypt" są uruchamiane na pliku binarnym, aby przekształcić go w plik binarny "ua" zgodny z uart. Na pierwszy rzut oka, otafix wygląda, jakby po prostu dopasowywał się do rozmiaru? Szyfrowanie jest podobnie dość proste: wygląda na to, że trochę dopełnia, a następnie szyfruje za pomocą DES (szyfrowanie symetryczne!) z kluczem podanym w wierszu poleceń (a tym samym przez skrypt). Ponieważ klucz w skrypcie wystarczył do zbudowania obrazu do zainstalowania, podejrzewam, że powinien również wystarczyć do odszyfrowania zrzutów oprogramowania układowego.

    Znalazłem również to: https://github.com/tiancj/rtt_ota_tools, co sugeruje, że dostępnych jest wiele algorytmów szyfrowania, ale może to zależeć od bootloadera, który został przeskanowany przez SPI. (Jedno z oficjalnych repozytoriów ma w rzeczywistości dwa pliki binarne bootloadera, z szyfrowaniem i bez) Przypuszczalnie coś w chipie musi znać klucz szyfrowania, a bootloader wydaje się rozsądną opcją.

    Czy wiemy dużo o programatorze spi podłączonym do HID dla tych chipów? Poprzednie repozytorium Pythona, które połączyłem, obsługiwało ich protokół, ale nie wiem, skąd wziąć jeden, ani nawet jaki układ scalony jest używany, ponieważ wszystkie zdjęcia pokazują stronę złącza, która nie ma chipów, tylko złącza i elementy pasywne.
  • #22
    p.kaczmarek2
    Level 28  
    ryanpavlik wrote:
    Mam nadzieję, że unikniesz korzystania z bazy Tuya, zwłaszcza że łańcuch narzędzi i pliki makefile wydają się uszkodzone w systemie Linux/WSL i działają tylko w systemie Windows

    Proszę zamieszczać tutaj komunikaty o błędach, postaram się pomóc.

    ryanpavlik wrote:
    . Udało mi się zrzucić oprogramowanie z WB8P, bawiąc się kablem zasilającym. Myślę, że to było wsteczne zasilanie przez linie Uart czy coś,

    czy twoje poziomy logiczne UART nie są 3,3 V? Piny IO mogą mieć diody zabezpieczające do chipowania VDD, tyle MCU może działać bez podłączania zasilania do pinów VDD, tylko do IO. To tak zwana ,,pułapka na młodych graczy", jak powiedziałby Dave Jones.

    W każdym razie cieszę się, że teraz działa dla Ciebie!

    ryanpavlik wrote:

    Czy wiemy dużo o programatorze spi podłączonym do HID dla tych chipów?

    W temacie XR809 wspomniałem, że Alios SDK wyświetla okno dialogowe ST-Link V2 po udanej kompilacji i wszystkie piny SPI są dostępne, jeśli chcesz przylutować przewody. Mam pod ręką ST-Link V2, ale po prostu nie miałem czasu go wypróbować.

    ryanpavlik wrote:

    Podejrzewam, że powinno wystarczyć również do odszyfrowania zrzutów oprogramowania układowego.

    Ciekawostką, o której należy tutaj wspomnieć, jest to, że pierwszy testowany przeze mnie moduł WB2S zachował konfigurację WiFi (z hasłem) nawet po flashowaniu z mrugnięciem. Wspomniałem o tym w temacie XR809. Materiały Wi-Fi muszą być przechowywane w innym miejscu. Różni się to od przypadku ESP8266, w którym udało mi się znaleźć moje dane uwierzytelniające Wi-Fi w odczytywanym oprogramowaniu układowym za pomocą prostego edytora tekstu (więc w zasadzie wyrzucenie dowolnego inteligentnego urządzenia Tuya ESP do kosza może naruszyć twoją sieć Wi-Fi).

    Jakiś czas temu wpadłem na pomysł... może powinienem stworzyć obraz maszyny wirtualnej VMware dla (powiedzmy) Linuksa z całym łańcuchem narzędzi, aby ludzie mogli łatwiej szybko rozpocząć pracę z chipem Beken? I po prostu rozpowszechniaj obraz. Mimo to można powiedzieć, że ludzie, którzy nie potrafią poprawnie skonfigurować SDK, i tak nie byliby w stanie wnieść zbyt wiele....



    p.kaczmarek2 wrote:

    Btw: Właśnie sobie przypomniałem, że mam jeszcze jedno urządzenie WB3S! Sterownik czterech przekaźników, ten, który tutaj recenzowałem:
    https://www.elektroda.pl/rtvforum/topic3822484.html
    Muszę teraz pamiętać, gdzie to umieściłem, a także sprawdzę, czy mogę to sflashować.

    Odkryłem, że 15 minut temu było w piwnicy. Ustawiłem do tego stanowisko testowe i wiesz co, działa jak urok.
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Mogę zarówno sflashować nowe oprogramowanie, jak i odczytać istniejące (również Tuya)

    Ważne notatki:
    1. Używam kluczy sprzętowych USB do TTL HW597
    2. Każdy klucz ma zworkę między 3,3 V a VCC (wybierz poziomy logiczne 3,3 V)
    3. Zasilam WB3S za dodatkową opłatąprzewód podłączony do VBUS z USB przylutowany do klucza sprzętowego i przypadkiem NIE z pinu "5V" na kluczu sprzętowym, który nie jest VBus, służy tylko do wyboru poziomu logicznego
    4. Zdjąłem nasadkę 470uF z płyty
    5. VBUS jest oczywiście podłączony przez przycisk (ze starego telewizora) do pinu wejściowego 1117 3,3V

    Zobacz schemat:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

    Programowanie mojego mrugnięcia... (bez żadnych zmian)... i... żyje!



    Słychać kliknięcie przekaźnika, zarówno przekaźnik, jak i dioda LED znajdują się na tym samym pinie WB3S.
  • #23
    ryanpavlik
    Level 4  
    Szybka aktualizacja: Mam kompilację opartą na CMake (zamiast bash i makefile) tutaj: https://github.com/rpavlik/tuya-iotos-embeded-sdk-wifi-ble-bk7231t/tree/cmake Nie pasuje jeszcze doskonale, ale myślę, że jest blisko. To się kończy, chociaż nie próbowałem używać kompilacji, którą tworzy. Powinien być również przenośny do innych repozytoriów bk7231 SDK.

    Plik UA to "obszar użytkownika", ale także UART. QIO to "jak w spi flash qio" - pełny obraz, który umieściłbyś z fabryki, jeśli nie używasz tam uart. UG to plik OTA ,,uaktualnienia" dla aktualizacji opartych na Tuya.

    Myślę, że napięcie IO wynosi 3,3 na moich adapterach uart. Jednak nie są takie jak twoje. Zamówiłem takie jak twoje. Nie zasilam też ,,przed LDO", ale wysyłam 3,3 V bezpośrednio do pinu vcc/vbat modułu.
  • #25
    MrTechGadget
    Level 2  
    Tak ekscytujące jest widzieć ten postęp i ciągłą aktywność. Nie mogę się doczekać, aby zobaczyć postęp w kierunku czegoś, co może być konsumowane przez więcej osób, które naprawdę chciałyby uwolnić swoje urządzenia z chmury Tuya!
  • #26
    p.kaczmarek2
    Level 28  
    @ryanpavlik przy okazji, widziałeś to?
    https://www.elektroda.pl/rtvforum/topic3823834.html
    Posiadanie odwróconego protokołu programowania UART dla układów Beken może być przydatne do automatyzacji pracy programistycznej, coś w rodzaju ,,automatycznie flashuj oprogramowanie po skompilowaniu następnej wersji", wiem, że wydaje się to być dodatkową pracą do wykonania, ale jest to niezwykle przydatne, gdy musisz pracować nad kodem od dluzszego czasu.
    Zresetowanie modułu (odłączenie zasilania i ponowne podłączenie) można wykonać za pomocą pinu DTR dostępnego na niektórych mostkach UART lub pinów IO MCP2221 (jak w połączonym przykładzie)

    The_Digital_1 wrote:

    Urządzenie, które próbowałem przeprogramować, było tym:
    https://www.amazon.com/gp/product/B07WRFCXL9/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1

    10$ za sztukę i 10$ wysyłkę do Polski? To nie jest napięcie ani standard jakie tu mamy, ale i tak bym to kupił. Jedynym problemem jest to, że Amazon nie akceptuje bezpośrednio Paypal... Pomyślę o tym.

    MrTechGadget wrote:
    Tak ekscytujące widzieć ten postęp i ciągłą aktywność.!

    Postaram się wkrótce uzyskać bardzo proste, ale praktyczne demo. Będzie on bazował na wspomnianym już module przekaźników:
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Schematy (jak narysowałem kilka miesięcy wcześniej):
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    Przyciski działają (mogą wykryć kliknięcie, podwójne kliknięcie i długie przytrzymanie):
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT
    WB2S/BK7231 Tutorial - tworzymy własny firmware - UDP/TCP/HTTP/MQTT

    Najprawdopodobniej na początku skupię się na rzeczach MQTT i stworzeniu elastycznego zaplecza remapującego przyciski/przekaźniki w kodzie, podczas gdy przepustkę WiFi i konfigurację przycisków będzie można skonfigurować dopiero w czasie kompilacji (więc pierwsza wersja będzie musiała zostać ponownie skompilowana przez użytkownika w celu użycia), a potem pomyślę o konfiguratorze HTTP podobnym do Tasmota. Pozostałości Tuya również będą musiały zostać usunięte/wyłączone lub wymienione, jeśli to możliwe (jeśli możliwe jest, aby wspomniany FreeRTOS inny niż tuya działał).
  • #27
    btsimonh
    Level 11  
    Cześć wszystkim,

    Przyglądałem się flasherowi opartemu na Pythonie.
    klon jest w moich repozytoriach (szukaj btsimonh hid_download_py na github - przepraszam, nie mogę jeszcze publikować linków tutaj.) - Zaktualizuję go moimi modami, kiedy skończę moje mody.

    (Aktualizacja - aktualizacje w branch btsimonhmaster na github.com/btsimonh/hid_download_py/tree/btsimonhmaster - teraz ma opcję -r do odczytu flasha. Możesz czytać wszędzie od 0x11000 wzwyż. np. informacje wifi są przechowywane w 0x11000+0x1d1000 = 0x1e2000 - Ty może przeczytać te informacje, używając:
    Python uartprogram wifi.bin -d com4 -r -b 961600 -s 0x1e2000 -l 0x1000
    )

    Komunikuje się z chipem (w moim przypadku kontroler Calex RGBWW kupiony w Tesco w Wielkiej Brytanii).
    Najpierw implementuję funkcję odczytu oprogramowania układowego - została częściowo zaimplementowana, ale część kodu była po prostu zepsuta (jak oczekiwanie na odpowiednią liczbę odebranych znaków).

    Zgaduję, że oprogramowanie do odczytu / flashowania oparte na Pythonie byłoby jednym z komponentów, które pomogłyby nam stworzyć konfigurację PlatformIO dla tych układów / płyt.

    Ponadto, podczas wyszukiwania, znalazłem oficjalne repozytoria Beken, w tym FreeRTOS:
    szukaj bdk_freertos na github
    Nie ma tam Tuya...

    br i dziękuję,

    Szymon

    ps buduje teraz swoją aplikację demonstracyjną. dziękuję za przewodnik.
    Szybka gra z encrypt.exe i odszyfrowuje to, co szyfruje. Ale nie odszyfrowuje mojego oprogramowania w postaci odczytanej z urządzenia :( .
    - nie, domyśliłem się o co chodzi. beken_packager.exe dodaje 2 bajty (crc 'beken_onchip_crc') co 32 bajty, a na końcu dodaje trailer z mnóstwem FF i trochę informacji o aplikacji. Jeśli usunęliśmy dwubajtowe dodatki z pobranego obrazu oprogramowania układowego, to encrypt.exe prawdopodobnie go odszyfruje (odszyfrowuje pierwsze 32 bajty dobrze....). I wyjaśnia, dlaczego plik bin 886k staje się 1124k...
    Dziwne, że chip może odczytać kod wykonywalny, który został zaszyfrowany, a mimo to dane użytkownika (informacje o Wi-Fi) są jasne - chociaż może nadal crcced co 32 bajty?

    pps zaktualizował github.com/btsimonh/hid_download_py/tree/btsimonhmaster o opcję -p:
    python uartprogram -p template_demo_UA_1.0.0.bin
    tworzy template_demo_UA_1.0.0.bin.unpackage_enc.bin, który jest odpowiednikiem template_demo_1.0.0.bin z wyjątkiem śmieci na końcu oryginalnego szyfrowania? - więc możesz teraz pobrać ORAZ odszyfrować istniejące oprogramowanie (zakładając takie samo szyfrowanie jak SDK, działa dla oprogramowania z urządzenia testowego, które mam).
  • #28
    btsimonh
    Level 11  
    Hmm... kiedy zbuduję powyższe aplikacje, nie połączy się z moim Wi-Fi.
    Router narzeka:
    środa 19 stycznia 20:50:25 2022 daemon.info hostapd: wlan1: STA 7c:f6:66:0b:3f:e8 IEEE 802.11: uwierzytelnione
    środa 19 stycznia 20:50:25 2022 daemon.info hostapd: wlan1: STA 7c:f6:66:0b:3f:e8 IEEE 802.11: brak WPA/RSN IE w żądaniu skojarzenia

    wygląda na to, że wciąż czegoś nam brakuje?
    Jakieś pomysły?

    Aktualizacja:
    Naprawiony:
    void connect_to_wifi(const char *oob_ssid,const char *connect_key)
    {
    demo_sta_adv_app_init(oob_ssid, connect_key);
    }
    Jeśli określa WPA2...
  • #29
    btsimonh
    Level 11  
    Po wielu sukcesach - aplikacja non-tuya lib z działającą publikacją MQTT (ale zawiesza się po otrzymaniu wiadomości na subskrybowany temat), serwerem http i serwerem tcp, właśnie zamurowałem swoją implementację serwera TCP do aktualizacji OTA :( .
    Tak więc, koniec z odpowiedzią na flashowanie Uart i brak danych na drugim porcie szeregowym po włączeniu zasilania.
    Chyba że mógłbym flashować za pomocą SPI, myślę, że urządzenie jest podpalone :( .
  • #30
    ptooley
    Level 2  
    @ryanpavlik Dzięki za to - próbuję zacząć od zdejmowania crufta Tuya i powrotu do FreeRTOS i odpowiednich sterowników. Niestety nie mogę uruchomić kompilacji CMake. Czy możesz podzielić się tym, jak to prowadzisz? Używam typowego podejścia do pliku CMake toolchain,
    Code: Bash
    Log in, to see the code


    niestety otrzymuję dołączanie błędów:

    Code:

    [  0%] Built target beken378_common
    [  0%] Building C object platforms/bk7231t/bk7231t_os/beken378/app/config/CMakeFiles/beken378_app_config.dir/param_config.c.obj
    /home/phil/repos/beken/tuya-iotos-embeded-sdk-wifi-ble-bk7231t/platforms/bk7231t/bk7231t_os/beken378/app/config/param_config.c:12:10: fatal error: mem_pub.h: No such file or directory
       12 | #include "mem_pub.h"
          |          ^~~~~~~~~~~
    compilation terminated.
    make[2]: *** [platforms/bk7231t/bk7231t_os/beken378/app/config/CMakeFiles/beken378_app_config.dir/build.make:76: platforms/bk7231t/bk7231t_os/beken378/app/config/CMakeFiles/beken378_app_config.dir/param_config.c.obj] Error 1
    make[1]: *** [CMakeFiles/Makefile2:1616: platforms/bk7231t/bk7231t_os/beken378/app/config/CMakeFiles/beken378_app_config.dir/all] Error 2
    make: *** [Makefile:91: all] Error 2


    Czy zanim pójdę kopać, brakuje mi czegoś oczywistego?

    Dziękuję!