ESP 8266 <> Arduinno NANO - zmiana miejsca instalacji BLYNK

Duży może więcej

Nurtuje mnie od jakiegoś czasu zagadnienie współpracy UNO/NANO z ESP8266. A dokładniej, czy słaby 8 bitowy mikrus procesorowy winien nadzorować działanie całego systemu i jeszcze sterować o wiele potężniejszym mikrokontrolerem ESP8266. Brak w tym logiki poza logiką historyczną - Arduino był pierwszy i to on obrastał w kolejne peryferia w tym odpowiedzialne za komunikację różnego rodzaju shieldy.  Ale od czasu gdy ESP wkupił się w łaski Arduino IDE i może być traktowany na równi z Atmelami utrzymywanie stanu rządzenia dużego przez małego wydaje się anachronizmem. Szczególnie, że zapełnienie 32 KB pamięci UNO/NANO dokonuje się błyskawicznie  przy wykorzystywaniu BLYNKa a 10 krotnie większa pamięć ESP8266 pozostaje praktycznie pusta.

Można oczywiście minimalizować kod  Atmegi. W wielu miejscach znajdziemy poradniki jak z kobyły Arduino IDE i gotowych bibliotek wrócić do czystego C i bezpośredniego sterowania rejestrami zmniejszając kod 10-20 krotnie przy standardowym programie blink. To oczywiście doskonały pomysł dla osób na poważnie (głównie zawodowo) chcących zająć się programowaniem mikrokontrolerów. Ale ja dziękuję. To jest dokładnie odwrotna logika niż ta, która legła u podstaw tego bloga. Bo oczywiście bez problemu zminimalizuję sterowanie portami ale biblioteki RCSwitch albo OneWire już nie. Że o BLYNKu nie wspomnę - a to są prawdziwe KOBYŁY pochłaniające gros zasobów malutkiej Atmegi. A nie mając zamiaru pisania własnych bibliotek nie pozostaje mi nic innego niż przeniesienie części kodu do większego procesora. W końcu mam dwa i niech się dzielą robotą.

Dobrym pytaniem jest czy w ogóle sprzęgać te dwa nierówne w klasach procesory jeśli większość programów da się już uruchomić na ESP. Moim zdaniem, dopóki chińczyk będzie oferował praktycznie 5 portów I/O i jeden analogowy to takie połączenie ma sens. Nawet jeśli za drzwiami czeka już kolejna mutacja  - ESP-32. Przyjazność, mnogość dobrze działających sprawdzonych bibliotek, potężne grono fanów i oczywiście cena jest gwarancją, że Atmele nie dadzą się łatwo zepchnąć do narożnika. Więc póki co postanowiłem pokombinować z odwróceniem logiki współpracy NANO <> ESP na ESP <> NANO z przesunięciem zadań rozdzielanych na oba procesory.

I tak ESP8266 chciałbym zrobić odpowiedzialnym za całość spraw komunikacyjnych z światem zewnętrznym na poziomie Internetu łącznie z pełną komunikacją z BLYNK. Atmel zaś robiłby to w tym czym jest najlepszy - w zarządzaniu peryferiami. Połączenie obu na poziomie sprzętowego seriala pozwoli na wykorzystanie wszystkich dotychczasowych moich płytek praktycznie bez zmian. Ba można poważnie pomyśleć nad fizycznym rozdzieleniem procesorów do różnych oddalonych lokalizacji  i wykorzystania do połączenia dowolnych łączy, po których bez problemu da się zaimplementować serial.

Zagadnienie jest frapujące choć wobec błyskawicznie zmieniającej się procesorowej rzeczywistości może stać się czysto akademickim zajęciem. Ale co tam .....

Najważniejszym problemem jest przyjęcie jakiegoś protokołu komunikacji, który z jednej strony nie zablokuje dzisiejszych funkcjonalności a z drugiej będzie na tyle szybki wydajny by nie odczuć różnicy w działaniu tak zmienionego duetu. Dobrze byłoby mieć jeszcze jakiś samo nakręcający się upside z takiej konfiguracji ale o tym będziemy myśleli potem. Na początek założę najprostszą komunikację szeregową typu nr_pin,dane. Przy tych odległościach problem zakłóceń praktycznie nie występuje.
Nic prostszego niż przesyłanie stringów pewnie nie wymyślę więc na początek ramka wyglądać będzie tak
Vxx:ww          xx - nr vPinu  ww - wartość    : separator
i tyle. Zakładam przesył danych jedno argumentowych - włączona funkcja SPLIT we właściwościach vPinow. Zobaczmy jak to zadziała. Dla jeszcze łatwiejszej obsługi na razie przyjmę następujący przydział vPinów
0 - 4  vLED
6 - 25 zmienne typu integer
25-31 zmienne typu string
Potem może pomyślimy nad uniwersalizacją przydziałów choć gdy do wykorzystania mam 128 vPinów rozbudowa i komplikacja kodu może nie mieć sensu.

Kod dla NANO



Kod dla ESP8266


I o dziwo wszystko działa. Choć trochę trzeba było pododawać do płytki by można było równolegle programować i NANO i ESP-01. Co ważne instalacja portable Arduino IDE pozwala pracować równolegle na dwu aplikacjach i znakomicie przyspiesza implementację.

Z ciekawszych fragmentów kodu polecam funkcje związane ze zmienną  typu String. To dzięki nim analiza odbieranego kodu  jest prosta i przyjemna.

str.charAt(0) - zwraca znak z pozycji 0 stringu str
str.substring(1, str.indexOf(':')) - wycina kawałek stringa od znaku na pozycji  1 do znaku ":"
data = str.substring(str.indexOf(':') + 1) wycina kawałek stringa od znaku po ":" do końca
data2 = strdata2.toInt() - zamienia string na licznę typu int jeśli string zawiera cyfry

Jedyny problem był z funkcją  serialEvent()   Odbiera ona znaki ze sprzętowego seriala w przerwaniu - i działa bardzo ładnie ale tylko na NANO. Z jakiegoś powodu nie działa na ESP choć powinna bo serial ESP też działa na przerwaniach. Dodałem więc funkcje  myserialEvent(), która jest cyklicznie wywoływana w pętli LOOP. Trzeba będzie poszperać jak to zrobić elegancko na przerwaniu.

Opisany sposób instalacji BLYNK w ESP8266 i połączenie go serialem z procesorem NANO ma jeszcze jedną fajną cechę - można w ten sposób obsłużyć BLYNKiem każdy dowolny procesor posiadający port serial np całą rodzinę PICów, dla których nie została zaimplementowana biblioteka BLYNK.

A to już całkiem nowy i ciekawy temat ......

cdn .....