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
Brak komentarzy:
Prześlij komentarz