New Kid in Town, czyli odkrywanie „nowego ESP8266”

Takie alternatywne gotowe oprogramowania to np. Tasmota, ESPHome czy ESPEasy. Ja posiadam urządzenie Sonoff Basic R1, którego płytkę wyjętą z obudowy przedstawia fotografia 1 - powyżej. Jest to przekaźnik o maksymalnym obciążeniu 10A przy 230V sterowany przez układ ESP8266. Na płytce znajduje się też zasilacz AC/DC. Na moje urządzenie wgrałem oprogramowanie Blynk, które także jest ciekawym systemem do sterowania urządzeniami ze smartfona przez sieć. Ta platforma pozwala własnoręcznie „zbudować z klocków” graficzny interfejs użytkownika do sterowanego urządzenia. Co ciekawe, mimo że platforma ta korzysta z „chmury”, czas reakcji od naciśnięcia wirtualnego przycisku na ekranie telefonu do przełączenia przekaźnika jest niezwykle krótki – niezauważalny. To urządzenie leży w szufladzie, ponieważ jakoś nie mam potrzeby włączania czegoś z aplikacji, a poza tym nie do końca ufam małym chińskim urządzeniom podpiętym do zasilania w domu 24 godziny na dobę, 7 dni w tygodniu. Ale to, że jedno urządzenie smart leży w szufladzie, to nie powód, żeby nie kupować kolejnego.

Fotografia 2.

Dlatego przeglądałem ofertę firmy Sonoff i trafiłem na nowe urządzenie DW2-Wi-Fi – czujnik otwarcia drzwi lub okna. Pokazane na fotografii 2 urządzenie montujemy na framudze, a na oknie dołączony magnes. Wbudowany kontaktron wykrywa, czy magnes jest blisko, czy nie. Urządzenie jest zasilane z dwóch baterii typu AAA i korzysta z Wi-Fi do komunikacji. Zwykle podobne czujniki wykorzystują bardziej energooszczędne protokoły. Niby tryby uśpienia ESP8266 są bardzo efektywne i  jak najbardziej możliwe jest zrobienie tego typu urządzania na tym układzie, ale jednak raczej się ich nie spotyka. Kolejny punkt układanki to sposób ustawiania parametrów domowej sieci Wi-Fi w urządzeniu – służy do tego połączenie Bluetooth LE. Czyli nie może to być ESP8266, który nie ma tego typu łączności, może to być natomiast ESP32. Zainteresowany zacząłem szukać informacji o DW2-Wi-Fi, ale było ich bardzo niewiele, raczej tylko oferty handlowe. Ale jest jedna strona, która pokazuje „rozbierane zdjęcia” urządzania. I okazuje się, że wcale nie wykorzystuje ono żadnego układu produkcji Espressif Systems. Za to jest to coś, o czym wcześniej nie słyszałem, tytułowy nowy zawodnik w mieście – układ OPL1000A2, równie nieznanego producenta Opulinks Technology. O samym układzie i producencie za wiele informacji nie ma, ale producent udostępnia swoją stronę na githubie, gdzie jest ich już sporo. Jest dokumentacja układu, zestawu ewaluacyjnego oraz dużo narzędzi dla programistów. Zaglądając do noty katalogowej układu, widzimy, że jest to coś zbliżonego do ESP32, czyli SoC Wi-Fi integrujący w jednej strukturze wszystko poza pamięcią flash.

Rysunek 1.

Rysunek 1 (z dokumentacji producenta) przedstawia wewnętrzne bloki układu. Uwaga! Wszystkie rysunki z artykułu w oryginalnej postaci i wielkości są dostępne w Elportalu wśród materiałów dodatkowych do tego numeru. Widać kompletne radio Wi-Fi i Bluetooth 5.0 LE, dwa rdzenie  procesora, układy zasilania, peryferia szeregowe (UART, I²C, SPI), 10-bitowe ADC z 16 wejściami. W odróżnieniu od ESP32 tutaj mamy Wi-Fi 802.11b, a w produkcie Espressif b/g/n. Rdzenie procesora też są zupełnie inne. U Espressif są to Tensilica Xtensa LX6 i oba są identyczne. Natomiast tutaj mamy produkty ARM i to dwa różne. Za obsługę stosów komunikacji radiowej odpowiada Cortex M0, a Cortex M3 przeznaczony jest dla aplikacji użytkownika. Jak widać na rysunku 2, producent ma też układ z wbudowaną pamięcią Flash dla programu. Jest to OPL1200 i co ciekawe, pamięć ta jest dodana jako osobna struktura w jednej obudowie „stacked die”.

Rysunek 2.

Zupełnie nowy i nieznany układ na pewno zachęca do zakupu. Bardzo niska cena również. Cel zakupu to nie użytkowanie, tylko raczej chęć, by zobaczyć, jak to działa i co z tym można zrobić. Paczka przyszła szybko. Zacząć można jednak od sprawdzenia, jak to działa w oryginalnym zastosowaniu. Do tego potrzebna jest aplikacja producenta o nazwie eWeLink. Aby połączyć urządzenie z siecią Wi-Fi, faktycznie jest wykorzystywany Bluetooth. Po wprowadzeniu urządzenia w tryb parowania poprzez przytrzymanie jedynego przycisku dioda zaczyna migać, a proces parowania przebiega sprawnie. Urządzenie jest dodane w aplikacji i można sprawdzić, jak działa. Po otworzeniu jego statusu widzimy to, co na rysunkach  3, 4, odpowiednio gdy magnes jest zbliżony lub oddalony. Wyświetlany jest też stan baterii, ale nie zmienia się on płynnie. Powyżej 2,6V bateria jest „pełna”, a poniżej „pusta”. 

Rysunek 3.

Rysunek 4.

Na rysunkach widzimy też komunikat, że dostępna jest nowa wersja oprogramowania urządzenia. Jego aktualizacja odbywa się OTA – Over The Air – czyli po prostu bezprzewodowo. W jednym z dokumentów producenta możemy przeczytać, jak to wygląda dokładniej i zobaczyć, że w pamięci flash zawsze przechowywane są dwie wersje oprogramowania: bieżąca i nowa. Czyli proces aktualizacji powinien być w pełni bezpieczny i w razie jakiegokolwiek problemu urządzenie powinno wrócić do starej wersji. I faktycznie przebiegła ona bez problemu, ale niestety nie był widoczny żaden pasek postępu. W aplikacji można tworzyć warunkowe konfiguracje, np. że otwarcie drzwi załącza światło podłączone do innego produktu Sonoff. Ale ponieważ nie posiadam żadnego produktu z oryginalnym oprogramowaniem, więc nie sprawdziłem tego.

Czas przejść od użytkowania do sprawdzania, jak to wszystko działa. Po pierwsze, czas reakcji. Nie jest on tak dobry, jak w przypadku wspomnianego powyżej Blynka. Od zbliżenia magnesu do urządzenia do zmiany na ekranie może minąć sekunda albo i kilka. Oczywiście zakładam, że urządzenie z Wi-Fi zasilane z ogniw AAA nie może być stale połączone z Access Pointem, musi przechodzić w tryb uśpienia i wybudzać się tylko na chwilę po zmianie stanu kontaktronu. A więc kolejny krok to próba potwierdzenia tego zachowania. W ustawieniach Access Pointa sprawdzam przydzielony urządzeniu adres IP i wysyłam ping. Oczywiście odpowiedzi brak. Ale wystarczy krótko nacisnąć przycisk urządzenia lub zbliżyć i oddalić magnes od kontaktronu i otrzymujemy odpowiedź. Jeżeli te operacje powtarzamy co sekundę, to pingi cały czas dochodzą. Chwila nieaktywności, urządzenie usypia i pingi nie znajdują adresata. Kolejny krok to sprawdzenie, jaki jest pobór prądu. Producent na opakowaniu obiecuje ≤40μA w trybie uśpienia i ≤15mA w trakcie transmisji. I trzeba przyznać, że wartości się zgadzają: zmierzyłem odpowiednio 27μA oraz 7,3mA. Prąd w uśpieniu cyklicznie skacze do większej wartości, niestety nie miałem dostępnego oscyloskopu, żeby to dokładniej zaobserwować.

Fotografia 3.

Czas zbadać, co tak naprawdę jest w środku. Po otwarciu obudowy w celu włożenia baterii widoczna  jest płytka drukowana jak na fotografii 3, ale to, co najciekawsze, jest od spodu. Wystarczy rozciąć nożykiem niewielkie ilości kleju umieszczone w rogach i  umiejętnie podważyć kilka klipsów dookoła, by wyjąć płytkę i zobaczyć to, co na fotografii 4.

Fotografia 4.

Czyli to, czego można się było spodziewać: najważniejszy układ OPL1000A2, pamięć Flash, jedna obudowa SOT-23 – tranzystor zabezpieczenia odwrotnej polaryzacji, dwa rezonatory kwarcowe, trochę elementów RC i antena wykonana na PCB. Mamy też kilka podpisanych pól testowych oraz 4-pinowe nieobsadzone złącze z rastrem 2,54 mm (na fotografii 4 już są wlutowane goldpiny) z bardzo dobrze rokującymi opisami, kolejno: 3V3, GND, RXD, TXD. Pierwszy opis jest trochę na wyrost, bo pin ten jest połączony bezpośrednio z plusem baterii, czyli napięcie będzie niższe niż 3,3V, ale możemy je tam podłączyć zamiast baterii. Natomiast dalej jest tylko lepiej, przecież tutaj ewidentnie jest wyprowadzony UART układu. A więc podłączyłem przejściówkę USB<-> UART i zacząłem sprawdzać, czy coś się dzieje na „typowych” prędkościach transmisji. Należy zaznaczyć, że piny są podpisane „prawidłowo”, tzn. TXD to ten, na którym OPL1000 nadaje i należy go połączyć z RXD komputera. Niektóre chińskie płytki potrafią mieć te oznaczenia zrobione dokładnie odwrotnie, tzn. TXD oznacza „tu podłącz TXD komputera” czyli jest to tak naprawdę linia odbiorcza. Nasłuch zacząłem od prędkości 9600bps. Podczas pracy urządzenie nic nie nadaje. Po wybudzeniu przyciskiem bądź magnesem też nie. Więc sprawdziłem, co się dzieje w momencie włączenia zasilania i od razu przyniosło to efekt widoczny na rysunku 5.

Rysunek 5.

Urządzenia daje nam możliwość wejścia w tryb fabryczny, niestety nie udało mi się tego dokonać. Natomiast w trybie normalnym mamy znak zachęty > i możemy wpisywać komendy AT, na które urządzenia odpowiada, ale niestety bardzo szybko „usypia”, więc mamy bardzo mało czasu. Ale jest to bardzo obiecujące zachowanie.

Na początku transmisji widać jakieś „krzaczki”. Dlatego spróbowałem powtórnego nasłuchu na innej typowej prędkości, tym razem 115200bps i otrzymałem to, co na rysunku 6. Czyli wygląda na to, że bootloader układu komunikuje się na tej właśnie prędkości, a potem kontrolę przejmuje aplikacja użytkownika, która nadaje już na 9600bps. Skoro widzimy, co mówi do nas bootloader na tym porcie UART, to czas spróbować wgrać jakieś inne oprogramowanie. Przeglądając zawartość  SDK ściągniętego z githuba natrafiłem w katalogu OPL1000A2-SDK-master\Tool\Download na program o obiecującej nazwie download_RELEASE.exe.

Rysunek 6.

Rysunek 7 pokazuje wygląd uruchomionej aplikacji. Poza możliwością wyboru portu COM używanego do komunikacji z programowanym układem ma ono kilka zakładek. Pierwsza „Pack” służy do przygotowania odpowiedniego pliku łączącego oprogramowanie dla obu rdzeni układu. Kod dla Cortex M0 odpowiedzialnego za łączność radiową  zapisany jest w pamięci ROM, ale może on być „patchowany” – takie łatki dostarcza producent w formie binarnej. Natomiast kod dla Cortex M3 to nasza skompilowana aplikacja. Zakładka OTA odpowiada za przygotowanie specjalnych obrazów pamięci gotowych do uaktualnia już nie za pomocą programatora, a przez Wi-Fi. Za samo wgrywanie przygotowanych plików binarnych odpowiada zakładka „Download”.

Rysunek 7.

Aby ESP8266 pozwoliło na wgrywanie oprogramowania przez UART, należy je uruchomić z wyprowadzeniem GPIO0 zawartym do masy. Ponieważ tu wszystko jest dość podobne, myślałem, że też trzeba któryś pin odpowiednio wysterować. Przyglądając się padom testowym, widzimy: GND, 3V3, IO8, IO9, IO10, ADC oraz RST. IO8 oraz IO9 to po prostu UART wyprowadzony też na złącze. IO10 w dokumentacji nie wskazuje w żaden sposób na wybór trybu bootowania. Okazuje się, że po naciśnięciu przycisku Download w aplikacji OPL1000 Download Tool należy po prostu włączyć zasilanie układu. Albo jeżeli było ono włączone wcześniej, to na chwilę zewrzeć linię RST do masy. Po tym rozpoczyna się wgrywanie oprogramowania. Niestety procedura ta bywa zawodna. Kilkakrotnie zdarzyło mi się, że pasek postępu zatrzymał się w trakcie procesu. Na szczęście wystarczy uruchomić aplikację ponownie i spróbować jeszcze raz.

W pobranym SDK w katalogu OPL1000A2-SDK-master\FW_Binary znajduje się plik binarny, pozwalający na używanie układu jako zewnętrznego radia Wi-Fi oraz Bluetooth LE sterowanego komendami AT. Podobnie jak domyślny firmware, z którym dostarczana jest większość modułów z układami Espressif. Na githubie Opulinks dostępny jest też plik OPL1000-AT-instruction-set-and-examples_ENG.pdf z pełną dokumentacją wykorzystywanych komend AT. Wgrałem plik opl1000_at.bin i po ponownym uruchomieniu układu i połączeniu się z nim przez UART (prędkość 115200) pojawił się znajomy znak zachęty i mogłem wydawać komendy AT. Teraz na szczęście układ już nie usypia i można się z nim komunikować bez problemu. Jak widać na rysunkach, pierwsze eksperymenty prowadziłem, używając PuTTY jako programu terminalowego. Niestety rezultaty były dość dziwne. Niektóre komendy (jak najprostsza AT) wykonywały się prawidłowo, inne powodowały jakby zawieszenie się układu. Czasami zależało to od kolejności wydanych komend. Po „zawieszeniu” jakakolwiek próba wpisywania kolejnych komend skutkowała tekstem: LF not found. Discard pending command. Okazuje się, że bardzo ważne jest, żeby zakończenie linii z komendą miało postać \r\n, czyli CR+LF. Ponieważ ustawianie tego w PuTTY jest dla mnie trochę niejasne, zmieniłem program terminalowy na CoolTerm.

Rysunek 8.

Rysunek 8 pokazuje jego prawidłową konfigurację. Parametry transmisji to 115200, 8 bitów danych, brak kontroli parzystości i jeden bit stopu. Teraz już wszystko działa niezawodnie i można było kontrolować układ. Rysunek 9 przedstawia przebieg eksperymentu. Komenda AT+RST powoduje ponowne uruchomienie układu, a jako jej rezultat widzimy efekt działania bootloadera. AT+GSLP odpowiada za uśpienie układu i przyjmuje dwa parametry: czas w milisekundach, po jakim ma się on obudzić oraz numer pinu, który odpowiada za wybudzenie. Niestety opis komend AT nie specyfikuje stanu, jaki jest wymagany. Po wydaniu komendy pobór prądu mierzony z dokładnością do 1mA spadł z 7mA do 0. Po 5 sekundach układ obudził się.

Rysunek 9.

Domyślnie Wi-Fi jest wyłączone i należy je skonfigurować. Służy do tego komenda AT+CWMODE=1. W przeciwieństwie do ESP8266, do wyboru mamy tylko wartość 1, oznaczającą tryb klienta, nie możemy utworzyć na układzie Access Pointa. Natomiast tak samo jak w ESP, nazwa sieci oraz hasło są zapisane w obszarze pamięci niezależnym od firmware i jego zmiana nie powoduje ich usunięcia. Dlatego jeżeli Wi-Fi miałem skonfigurowane w „fabrycznej” aplikacji, to zaraz po wydaniu komendy  AT+CWMODE=1 urządzenie połączyło się z moją siecią, czego dowodem są komunikaty WIFI CONNECTED i chwilę później WIFI GOT IP. Skoro adres jest przydzielony, to można go sprawdzić za pomocą komendy AT+CIFSR. Natomiast AT+CWLAP wyświetla wszystkie Access Pointy widoczne dla układu. Za pomocą AT+PING możemy odpytać hosty zarówno po ich adresie IP, jak i domenie.

Rysunek 10 przedstawia bardziej zaawansowane zadanie – utworzenie serwera HTTP i przesłanie najprostszej strony internetowej do przeglądarki. Pierwsza komenda to AT+CIPMUX=1, która przestawia układ w tryb z kilkoma (maksymalnie 4) połączeniami TCP – który jest niezbędny do działania serwera. Który uruchamiamy za pomocą AT+CIPSERVER=1,80. Pierwszy parametr to numer połączenia – jedno z 4 możliwych, a drugi to numer portu, a ponieważ chcemy korzystać z HTTP, jest to 80. Po tej komendzie serwer już działa i czeka na połączenie.

Rysunek 10.

W przeglądarce wpisałem adres układu OPL1000 w mojej sieci i w terminalu zobaczyłem, że serwer odebrał i wyświetlił zapytanie przeglądarki. Aby jej odpowiedzieć, należy wydać komendę AT+CIPSEND=1,171. Pierwszy parametr to numer połączenia, a drugi to liczba znaków, które chcemy wysłać. Ponieważ ten eksperyment był prowadzony bardzo na piechotę, najpierw całą odpowiedź (czyli podstawowy HTTP oraz HTML) napisałem w Notatniku, policzyłem znaki, pamiętając, że każdy „Enter” to dwa znaki (CR i LF) i wkleiłem do okna terminalu. Układ potwierdził ich odebranie. Przez ten cały czas przeglądarka czekała na „ładowanie się” strony.

Wydanie komendy AT+CIPSERVER=0,80 powoduje zamknięcie połączenia, a przed nim wysłanie wszystkiego co trzeba do przeglądarki. I właśnie po wydaniu tej komendy w oknie przeglądarki wyświetliła się ta bardzo podstawowa strona. To bardzo proste eksperymenty z terminalu, ale w ten sposób można tworzyć serwer albo klienta, korzystając z innego mikrokonrolera niemającego stosu TCP/IP, np. w Arduino Uno.

Kolejny eksperyment dotyczy Bluetooth LE. Protokół ten jest dość skomplikowany, a dokumentacja komend AT nie jest idealna – po pierwsze jest pisana lekko „chińskim” angielskim, po drugie dla Bluetooth ma tylko opisy poszczególnych komend, ale nie ma przykładów ich zastosowania do wykonania konkretnego zadania. Dlatego skupiłem się na najprostszym przypadku – uruchomieniu „rozgłaszania” tak, by moje urządzenie zostało wyświetlone w aplikacji skanującej wszystkie okoliczne urządzenia Bluetooth LE. Skaner, którego używam, to aplikacja nRF Connect, a na rysunku 11 widać jej zrzut ekranu z dowodom na sukces postawionego zadania.

Rysunek 11.

Urządzenie Test_EdW to właśnie poprawnie skonfigurowany OPL1000, drugie widoczne to „inteligentna” szczoteczka do zębów. Aby osiągnąć ten cel, wystarczą tylko 3 komendy AT. AT+BLEINIT=2 inicjalizuje Bluetooth LE, parametr 2 oznacza, że będziemy też używać trybu rozgłaszania (serwera), nie tylko klienta. Druga komenda ustawia, co chcemy rozgłaszać i ma postać:  AT+BLEADVDATA=”02010603ff02E50908546573745f456457”. W tym ciągu znaków jest zapisana w dość nietypowy sposób nazwa urządzenia, czyli Test_EdW – każdy znak ASCII jest zapisany jako  reprezentacja szesnastkowa jego kolejnego numeru – czyli dwa znaki. Czyli ostatnie cyfry 57 to „W”. Zainteresowanych, jak budować te „dziwne” ciągi, zachęcam do wyszukania hasła: „ble advertising packet format”. Ostatnia komenda AT+BLEADVSTART powoduje rozpoczęcie rozgłaszania – po jej wydaniu nasze urządzenie jest już widoczne np. dla smartfona skanującego w poszukiwaniu urządzeń Bluetooth LE. Wyłącznie zmieniając treść rozgłaszanej wiadomości, zupełnie zmieniamy, jak nasze urządzenie jest rozpoznawane. Wydając komendę AT+BLEADVDATA=”0201061aff4c000215fda50693a4e24fb1afcfc6eb0764782527b7f206c5”, tworzymy tzw. iBeacon, czyli tag BLE wymyślony kilka lat temu przez Apple. Z założenia miało być ich wszędzie pełno, w sklepach miały przesyłać reklamy, w muzeach służyć do nawigowania wewnątrz budynku i wyświetlania kontekstowej informacji. Chyba nie bardzo się udało…

Ale jeżeli ktoś chce jeszcze poeksperymentować z tą nieco zapomnianą technologią, to może „zrobić” własnego iBeacona na OPL1000 – dowód na rysunku 12. Ten przykładowy ciąg znaków znalazłem w dokumentacji komend AT układu ESP32.

Rysunek 12.

Tam jest opisany przykład, jak stworzyć i Beacona. A komendy AT są kompatybilne. Początkowo planowałem stworzyć urządzenie, które będzie mogło przez BLE przesyłać jakieś dane. Niestety temat wykraczający poza proste rozgłaszanie swojej obecności okazał się zbyt złożony na potrzeby tego artykułu. Ponieważ chcę, aby był on zachętą i inspiracją dla Czytelników do eksperymentów z tym układem, a najbardziej z Bluetooth LE, mam nadzieję że ktoś bardziej zaznajomiony z tym protokołem zgłębi temat i powstanie chociażby sztandarowy projekt – czyli termometr. Tyle że z BLE i wyświetlający pomiar na smartfonie, a między pomiarami śpiący z bardzo małym poborem energii, jak dla Bluetooth Low Energy przystało.

Czytelnicy zapewne zastanawiają się, czy po takich eksperymentach da się wrócić do oryginalnej funkcjonalności urządzenia? Skąd wziąć oryginalny firmware? Narzędzie OPL1000 Download Tool pozwala tylko wgrać oprogramowanie, ale nie odczytać. Więc sami nie możemy stworzyć „kopii zapasowej”. Na szczęście oryginalne oprogramowanie jest  dostępne na githubie producenta. Znajduje się w katalogu: OPL1000A2-Door-Sensor-Coolkit-Cloud-HTTPS. Cool­kit to producent oprogramowania eWeLink. Podczas pisania tego artykułu aktualna wersja nazywała się: opl1000_coolkit_door_sensor_003_020_2290_2001.bin. Jest to plik gotowy do wgrania – nie trzeba go łączyć z patchem dla procesora M0. Po jego wgraniu urządzenie normalnie działa z aplikacją eWeLink jak przed eksperymentami.

Oczywiście tak było z moją wersją urządzenia i oprogramowania, ale nie mogę zagwarantować, że tak będzie w przyszłości. Dostępność tego oprogramowania na stronie producenta układu pokazuje, że nie jest ono dziełem firmy Sonoff, a jest to po prostu przykładowy projekt Opulinks. Poza plikiem binarnym dostępne są pełne źródła – projekty dla środowiska uVision firmy Keil. Pobrałem je, jednak niestety te źródła to 2937 plików w 462 folderach zajmujących w sumie ponad 120MB. Jest też dokument PDF – niestety tylko po chińsku. Ten poziom złożoności całkowicie przerasta moje zdolności programistyczne. Widzę tam źródła systemu FreeRtos i kilka różnych „warstw” oprogramowania i mam wrażenie, jakby oryginalna aplikacja bazowała na innej. Może na oprogramowaniu pozwalającym na sterowanie komendami  AT – to by tłumaczyło, czemu są one dostępne przez chwilę po wybudzeniu urządzenia. Bardziej zaawansowanych Czytelników zachęcam do analizy – wygląda na to, że wszystko jest dostępne, tylko jest tego bardzo dużo. Może uda im się ustalić, czym jest tryb „factory” dostępny tuż po uruchomieniu urządzenia i jak w niego wejść.

W chwili pisania tego artykułu układ OPL1000A2 ani żadna płytka rozwojowa czy ewaluacyjna nie były dostępne do zakupu, a więc jedyna możliwość eksperymentowania z tym układem to kupno czujnika DW2-Wi-Fi. Na szczęście urządzenie jest naprawdę niedrogie, a pozwala na dużą swobodę eksperymentów. Niestety chociaż kod źródłowy aplikacji jest dostępny, nie znalazłem schematu urządzenia. Dokumentacji jest dużo, niestety część jest tylko po chińsku, a to, co jest po angielsku, jest też czasami trudne do zrozumienia, jest to typowy „chiński angielski”. Dokumentacja samego układu OPL1000 ma tylko 30 stron i podtytuł „Non-NDA Version”. Dla tak zaawansowanego układu można się spodziewać setek stron, czyli jest to tylko niewielki wycinek, a pełna dokumentacja dostępna jest po podpisaniu umowy o poufności z producentem. Mimo to i tak dostępne jest naprawdę wiele informacji oraz oprogramowania i daje to pole do ciekawych eksperymentów.

Przedstawiłem Czytelnikom nowy układ i możliwości eksperymentowania z nim. Ciekawy jestem, czy powstanie jakiś projekt z jego wykorzystaniem opublikowany na łamach EdW. Czy czytelnicy bardziej biegli w oprogramowaniu ode mnie rozgryzą SDK i modyfikacje kodu w uVision? Czy ktoś zbuduje ciekawe urządzenie sterujące układem za pomocą komend AT? Czy może powstanie port Arduino dla tego układu? Czy zdobędzie on taką popularność jak ESP8266?