BLYNK – wirtualne piny cz. I

By: | Post date: Sierpień 27, 2017

Mikroprocesor to dobry przykład połączenia dwu światów – realnego z milionami a raczej już miliardami tranzystorów zamkniętych w jednej obudowie i  milionów wirtualnych linii kodu w pamięci procesora. Arduino UNO to bez wątpienia czysty hardware, BLYNK zaś należy do świata wirtualnego.

Opisywałem już jak BLYNK starał się dogadać się ze sprzętem konfigurując zdalnie porty mikroprocesora. Dziś pomówimy o sytuacji odwrotnej – nasza ATmega382 lub ESP8266 spróbuje dopasować się do wirtualnego świata BLYNKa. Czyli rzecz o wirtualnych pinach (VP) w widgetach aplikacji BLYNK i w kodzie mikroprocesora.

Przesłanie informacji z BLYNKa do mikroprocesora (i odwrotnie) w trybie pinów rzeczywistych (cyfrowych bądź analogowych) wymagało od aplikacji w telefonie „znajomości”  portów odbiorcy konkretnego mikroprocesora. To niezbędne by wysłać lub odebrać dane w prawidłowym formacie  akceptowanym przez dany port mikroprocesora. Autorzy BLYNKa skorzystali tu z całej zgromadzonej w Arduino IDE wiedzy o konfiguracjach poszczególnych modułów. Ale taki system komunikacji mocno ogranicza możliwości zarówno aplikacji jak i procesora.

Niestety, ale rzeczywistość mikroprocesorów  jest  bardziej skomplikowana. Oprócz prostych sygnałów analogowo/cyfrowych porty są przekaźnikami dużo bardziej złożonych informacji. Mam na myśli różne protokoły transmisji dostępne w praktycznie każdym współczesnym mikrokontrolerze. Najbardziej popularne to RS232, SPI, I2C, ONE WIRE, itd itd.. I o ile sygnały cyfrowe i analogowe odpowiadają fizycznym wartościom napięć na pinach procesora to treść informacji przesyłanych danym protokołem w żaden sposób nie zależy od fizycznych sygnałów służących do ich przesłania. Potrzebny jest zatem inny rodzaj nośnika pozwalający na wymianę tych informacji miedzy aplikacją w telefonie a mikroprocesorem. W tym celu mamy do dyspozycji tak zwane piny wirtualne (VP).

Piny wirtualne BLYNka to tak naprawdę dobrze znane z programowania zmienne programu.  Ale o ile np.  C++ zmienne mogą przybierać niemalże dowolną nazwę ale muszą mieć dokładnie zdefiniowany typ (byte, int, str) to w BLYNKu jest akurat na odwrót. Piny wirtualne mają ściśle określoną nazwę – Vxxx gdzie x jest cyfrą – ale mogą zawierać praktycznie dowolną zawartość (byte, int, str).

I tak np. jeśli aplikacja w telefonie załadowała do wirtualnego pinu V1 liczbę 65 to program w mikroprocesorze może potraktować to jako:

  • liczbę dziesiętną 65 w formacie int
  • liczbę dziesiętną 65 w formacie duble
  • łańcuch znaków „65” (string)
  • liczbę hex 65 ( 101 dziesiętnie)
  • kod litery A
  • w każdy inny logiczny sposób

Nasz pin wirtualny jest więc swoistym kontenerem za pomocą, którego telefon i mikroprocesor wymieniają się informacjami. Przesyłka jak to przesyłka musi zawierć adresata – jest nim kod AUTH wygenerowany przy tworzeniu nowego projektu  w aplikacji telefonu i umieszczony w kodzie programu mikroprocesora. Serwer BLYNK przesyła informacje pomiędzy urządzeniami o tym samy kodzie AUTH.  Jest tylko jeden problem – w przesyłce brak listu przewozowego określającego zawartość kontenera. Odbiorca sam musi zdecydować jak potraktować zawartość wirtualnego pinu. W systemie BLYNK nie jest to problemem albowiem zakłada się, że aplikację w telefonie i w mikroprocesorze tworzy ta sama osoba więc wie co wysyła.

Dla jednego projektu dysponujemy 32 VP z możliwością zwiększenia do 128. To dużo. Ale tak naprawdę mamy możliwość przesłania praktycznie dowolnej liczby danych poprzez zgrupowanie ich w string lub tablicę i wysłanie w jednym kontenerze. Jak to zrobić – przy innej okazji. Wirtualne piny mają jeszcze jedną fajną cechę – są dwukierunkowe. Kierunek przesyłania informacji z lub do mikroprocesora dla pinów rzeczywistych definiuje się raz przy starcie aplikacji i zachowują one ten kierunek przez cały okres pracy urządzenia. Natomiast pin wirtualny może być w tym samy czasie wysyłany w obu kierunkach. By miało to jakiś sens muszą istnieć widgety dwukierunkowe tj potrafiące nadawać i przyjmować informacje. I jak się okazuje takich widgetów jest zadziwiająco wiele co jak zobaczymy poszerza niesłychanie możliwości komunikacji telefon/mikropocesor.

Szalenie ważną cechą to, że informacja przesyłana pinem wirtualnym może być zapamiętana na serwerze BLYNK. To kapitalna funkcja przydatna w kilku sytuacjach. W przypadku pinów rzeczywistych ustawianych z aplikacji stan pinu jest aktualizowany jedynie gdy oba programy (w telefonie i mikroprocesorze) są aktywne. W przypadku pinów wirtualnych sprawa się nieco komplikuje. Kontener może być załadowany informacją również w sytuacji gdy druga strona jest nieaktywna. By jej nie utracić serwer BLYNK zapamiętuje ją w swojej bazie danych i przekazuje dalej z chwilą nawiązania połączenia przez nieaktywne wcześniej urządzenie. Twórcy BLYNKa poszli jeszcze dalej – zapamiętywana jest nie tylko ostatnia wartość ale również duża liczba historycznych danych pozwalających na ich wyświetlanie w widgetach typu wykres. Serwer może również służyć jako swoista zewnętrzna pamięć dla danych programu niezanikających po np. resecie mikroprocesora. Te zagadnienia omówimy w osobnym artykule.\r\n

Dość teorii – drobny przykład

Klawisz wydaje się być najbardziej klasycznym elementem jednokierunkowym i to banalnie prostym – styk załączony/ wyłączony. Tak jest w przypadku widgetu z przyporządkowanym portem cyfrowym. Jeśli do widgetu BUTTON dowiążemy pin wirtualny to uzyskujemy dodatkowe, fantastyczne funkcje. Popatrzmy jak to działa w przykładowym układzie z modułem D1 MINI

BUTTON w aplikacji w telefonie połączony został z portem wirtualnym V1. Program w mikroprocesorze odbiera i wysyła różne informacje tym samym kontenerem V1.

A oto efekt.

Bohaterem pokazu jest BUTTON po środku ekranu podpięty do wirtualnego pinu V1. Wyświetlacz w lewym górnym rogu to wskaźnik temperatury z czujnika DS18B20. Niebieski przycisk dowiązany jest do portu GPIO 2 z LEDem na D1 MINI.

Co widać na filmie

  • BUTTON w ustawieniach domyślnych zmienia stan z 0 -> 1. W tym przypadku załączenie BUTTONa załącza diodę LED 1. Wyłączenie przycisku wyłącza LED
  • Ustawienie zmiany stanu z 0 -> 2 załącza LED 2 po naciśnięciu BUTTONa
  • Ustawienie zmiany stanu z 0 -> 3 załącza LED 1 i LED 2 po naciśnięciu BUTTONa
  • Ustawienie zmiany stanu z 0 -> 4 po naciśnięciu BUTTONa zaczyna wyświetlać się bieżąca temperatura z czujnika w polu BUTTON
  • Naciśnięcie klawisza S1 na płytce zmienia opis w polu BUTTON
  • Naciśnięcie klawisza S2 na płytce zmienia opis w polu BUTTON i dodatkowo zmienia kolor widgetu BUTTON na czerwony
  • Zwolnienie przycisku BUTTON przywraca ustawienia początkowe

To tylko sklecona naprędce próbka wariacji jakie udostępnia nam BLYNK w ramach wirtualnych pinów. Bardziej szczegółowy opis możliwości spróbuję przedstawić przy okazji prezentacji kolejnych widgetów.

Dla zainteresowanych – program dla D1 MINI (ESP8266) pozwalający uzyskać powyższe efektu jest tu >>>> i moja biblioteka obsługi czujnika temperatury dallas.h.

4

Dodaj komentarz

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