BLYNK po nowemu – Układy dwuprocesorowe cz. 1

By: | Post date: Październik 1, 2017

Jak nie dać się zdominować w istniejącym układzie?

Tytuł jak raz pasujący do poradnika pracownika korporacji. Na blogu elektronicznym brzmi nieco dziwnie choć jest to bólu prawdziwy. Doświadcza go każdy zadający się z mikroprocesorami. Wielozadaniowość, wywłaszczenia, systemy z podziałem czasu to tylko z pozoru określenia właściwe dla”dużych” systemów jak Windows czy MAC OS. Kto choć raz użył przerwania w mikroprocesorze otarł się o wielozadaniowość. Nawet technika poolingu jest uproszczoną (bardzo uproszczoną) formą systemu z podziałem czasu. Najłatwiej jednak wielozadaniowość – określana tu jako wykonywanie więcej niż jednego zadania w tym samym czasie – uzyskać poprzez zastosowanie w projekcie kilku równolegle pracujących procesorów. W dzisiejszej dobie przy cenach poniżej 1$ za kość to najprostsze i w sumie najtańsze rozwiązanie. I problem równoległej pracy dwóch lub więcej niezależnych procesów w tym samym urządzeniu mamy z głowy. W przeciwieństwie do barszczu dwa procesory w układzie to znakomity pomysł.

To miała być trzecia część trylogii o wieszaniu się BLYNKa przy kłopotach z komunikacją internetową. Ale, że temat ma potężną siłę konstrukcyjnego rażenia wydzielam go do osobnego rozdziału.

Poprzedni wpis pokazał dobitnie spory problem zawłaszczania procesora przez wewnętrzne procedury BLYNKa próbujące przywrócić komunikację w systemie po jej zerwaniu. Możemy sobie z tym poradzić poprzez odpowiedni dobór procedur konfiguracyjnych BLYNKa. Ale efekt nie jest 100% satysfakcjonujący. Program główny wciąż musi uwzględniać, iż istnieją odcinki czasu całkowicie zdominowane przez bibliotekę BLYNKa. Tym samym istnieje niebezpieczeństwo, iż nadchodzące w tym czasie zdarzenia nie zostaną prawidłowo obsłużone.

Najlepszym – moim zdaniem – rozwiązaniem jest użycie w projekcie co najmniej dwu procesorów. Jeden odpowiedzialny za obsługą programu głównego, drugi za komunikację w ramach BLYNKa. Jak zrobić z tego harmonijny związek i co zyskujemy w porównaniu do dwóch singli – szczegóły poniżej i w kolejnych wpisach.

 

BLYNK to sieciowe rozwinięcie Arduino. Brat bliźniak młodszy o dziesięć lat. Ale Arduino nie było zupełnie przygotowane na pojawienie się sieciowego bliźniaka. W wieku szalejącego internetu Włosi nie dostrzegli potrzeby połączenia klasycznego UNO z siecią. Stąd konieczność późniejszego dorobienia protez w postaci shieldów ETHERNET potem WiFi. I tym sposobem prosty moduł Arduino stał się niechcący systemem wieloprocesorowym. W postaci obrzydliwych kanapek – ale wszystko mniej więcej działało. I nagle na fali mody na systemy IoT sieciowość mikroprocesorów stała się wręcz koniecznością. Na szczęście sytuację uratowali Chińczyki wypuszczając na rynek super tani moduł WiFi – ESP8266. Błyskawicznie został dodany do narzędzi Arduino IDE pozwalając na budowę tanich i prostych modułów internetowych mikroprocesorów. BLYNK tylko zagospodarował tę niszę ale zrobił to w sposób genialnie prosty – tak prosty jak całe Arduino.

To podstawowy schemat „sieciowego” Arduino wałkowany na okrągło w internecie na tysiącach stron

Mamy więc klasyczny układ dwuprocesorowy w projekcie – jakiś moduł Arduio i jakiś moduł ESP  połączone serialem  (sprzętowym lub programowym). I oczywiście biblioteki BLYNK standardowo wgrane do UNO, NANO czy co tam lubimy z bogatej palety rodziny Arduino.

Niestety historia rozwoju sieciowego Arduino narzuciła logikę pracy takiego układu. A polegała ona na tym, że słaby i stary technologicznie mikrus – ATmega328 – zarządzał znacznie potężniejszym mikrokontrolerem ESP8266 (tu porównanie obu procesorów). I by było jeszcze zabawniej – robił to (i robi wciąż również w BLYNKu) za pomocą przedpotopowych komend AT. Horror.

Wszystko działa nieźle – do czasu zaniku komunikacji w systemie. Już nie tylko niedostępność serwera BLYNK czy brak połączenia internetowego zawiesza działanie programu głównego w naszej ATmedze. Także utrata komunikacji z ESP skutkuje zwisem całego programu lub czkawką w jego działaniu. A o tym, iż sterowany komendami AT moduł ESP lubi zawieszać się nader często przekonało się już wielu.

Na szczęście procesor ESP8266 został twórczo zaimplementowany do narzędzi Arduino IDE i stał się dostępny dla bibliotek BLYNKa. I w standardowym dwuprocesorowym układzie można przenieść BLYNKa do ESP pozostawiając program główny w ATmega328.

Rzecz wydaje się nieco skomplikowana ale jest nad wyraz prosta w implementacji. Po takiej operacji to nasz program główny decyduje co i kiedy wysłać/odebrać z portu komunikacyjnego. Jeśli z jakiejkolwiek przyczyny komunikacja pomiędzy mikroprocesorami ustaje – nie ma to najmniejszego wpływu na poprawność pracy programu głównego. System niejako automatycznie przechodzi w tryb pracy autonomicznej. Jedyną różnicą w działaniu może ( a nawet powinna) być sygnalizacja problemu komunikacji z otoczeniem zewnętrznym np. wkurzająco migającym czerwnym LEDem lub włączanym okresowo buzzerem.

Takie rozwiązanie w 100% rozwiązuje problem wieszania działa programu w razie kłopotów z łącznością w ramach systemu BLYNK. A dodatkowo, niejako za free, dostajemy kilka niezwykle cennych ekstrasów do wykorzystania w tworzonych projektach.

Ale o tym już inną razą ……

Zdjęcia zaczerpnięto z serwisu michal12r.flog.pl

14

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *