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
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.
https://youtu.be/q098u1ylYoo
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
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
Brak komentarzy:
Prześlij komentarz