sobota, 31 grudnia 2016

Flashowanie ESP-01 i innyh ESP8266

Lenistwo - cecha niewątpliwie pozytywna 

Zawsze doceniałem pozytywną rolę jaką w naszym  (mówię o facetach oczywiście) życiu odgrywa lenistwo. Czasami nabyte czasami wrodzone - ale na szczęście immanentnie związane z pierwszo i drugorzędowymi cechami określanymi jako męskie.
Nie będę tu wymieniał epokowych wynalazków ewidentnie związanych z tą piękną cechą - dość powiedzieć, że dzięki zmywarce wielu mężów uniknęło rozwodu a nawet polubiło zmywanie naczyń!

Dotyczy to każdego bez wyjątku obszaru naszego życia. Trzy zasadnicze pytania stawiane przed wykonaniem każdej pracy są kluczem do dominacji mężczyzn w świecie
- czy ta praca musi być zrobiona?
- czy to ja muszę ją zrobić?
- czy muszę to zrobić właśnie teraz?
Nikt z nas nie lubi sytuacji gdy choćby na jedno z tych pytań należy odpowiedzieć twierdząco.

Ale niestety zdarzają się sytuacje wymagające naszego oderwania się od ulubionej czynności - przebywania w pudełku z napisem NIC ( polecam znakomitą konferencję Marka Gungora na ten temat) - i zrobienia czegoś konkretnego. Nawet w tak przyjemnym działaniu jak hobby są czynności lekko frustrujące, które próbujemy za wszelką cenę minimalizować.

U mnie taką czynnością jest konieczność flashowania mikrokontrolerów. Nieodmiennie przy kolejnych próbach wgrywania nowego softu do posiadanych kości coś idzie nie tak. A to problem z zasilaniem, a to pomyłka połączenia Tx z Rx, a to nie ta wersja softu a to tysiące innych drobiazgów uniemożliwiających szybkie i bezproblemowe zakończenie tej w końcu technicznej czynności. Marzeniem jest aby wszystkie kupowane mikrokontrolery posiadały aktualne, najnowsze oprogramowanie (bootloader). Ale to marzenie - zwłaszcza w przypadku zakupów w Chinach. Tak było  ze wszystkimi kupionymi ESP-01 - żaden z nich nie nadawał sie do zastosowania z oryginalnie wgranym softem. Tak jest również z kupowanymi w Chinach Arduino NANO - standardowy bootloader uniemożliwia włączenie sprzętowego watchdoga bo ten go po prostu bezpardonowo wiesza procesor. Flashowanie ma jeszcze jedną fajną cechę - możesz szybko pozbyć się programowanego układu gdy coś w procedurze wgrywania pójdzie źle - procesor jest sprawny ale praktycznie głuchy na wszelakie próby komunikacji.

Do tej pory moduły ESP programowałem zewnętrzną przejściówką USB/RS232. Polubiłem te z układem CH340  bo ani razu nie wywinęły mi numeru przy instalacji sterowników czy w czasie pracy np. zawieszając komputer. Wszystko więc co pracuje z CH340 jako łącznik USB z mikrokontrolerem ma u mnie fory. Przyjściówek mam kilka i takie tylko z wyprowadzonym Rx i TX i takie z dodatkowymi liniami DTR CTS, na napięcia 5v i pozwalające dołączyć układy 3V3.
Wszystkie one spisują się bez zarzutu ale wymagają każdorazowo uwagi przy podłączaniu do programowanego układu by czegoś tam przez przypadek nie spieprzyć.

Od czasu gdy nabyłem drogą kupna D1mini z fantastyczną funkcją automatyki ustawień portów GPIO0 i RST przy inicjalizacji wgrywania programu  (oczywiście z wykorzystaniem układu CH340) sprawa nie dawała mi spokoju. Chłopaki z WEMOS problem rozwiązali bardzo sprytnie




Dwie dodatkowe linie DTR i RTS wyjściowe z adaptera sterują tranzystorami zwierającymi GPIO0 i RST do poziomu niskiego przy odpowiedniej kombinacji poziomów DTR i RTS. Tabelka wyjaśnia działanie tych kluczy. Oczywiście kolektory obu tranzystorów mają jeszcze dopięte rezystory podciągające do napięcia zasilania.
By wprowadzić moduł w stan oczekiwania na transmisje nowego softu trzeba zmieniać sygnały DTR i RTS w odpowiedniej sekwencji. To zapobiega przypadkowej inicjalizacji ESP przy stanach przejściowych np. podczas włączania komputera.

Postanowiłem i ja  uprościć i przyspieszyć sobie pracę  z oprogramowywaniem ESP-01 hurtowo wykorzystywanym w praktycznie każdym projekcie sterowania z BLYNK. Szczególnie gdy ilość przeprogramowań lawinowo wzrosła od chwili wdrożenia układu dwuprocesorowego NANO<>ESP-01 z BLYNKiem instalowanym w ESP8266.

Zrobić samemu programator ? Brrrrrrr

Aliekspress zachęca do kupienia czegoś takiego

Niestety z opisu nie wynikało jasno jak ten wynalazek działa - widoczny przełącznik niby ma opcję PROG ale jakoś nie znalazłem drugiego przycisku RST. No i kosztuje toto aż 5$

Z 1,5$ (z dostawą do domu) kupiłem więc prostszy model

 To "czysty" CH340 ze stabilizatorem 5/3V3 i ze wszystkimi potrzebnymi rezystorami polaryzującymi ESP-01. Mnie pozostaje jedynie podłączyć elementy wymuszające stan 0 na GPIO0 i RST przed rozpoczęciem wgrywania nowego softu.

Można to zrobić bez żadnego przycisku (reset i ustawienie GPIO0 sygnałem DTR)




 jednym przyciskiem - zero na GPIO0 trwa dłużej niż na RST dzięki kondensatorowi na bramce Q2 co jest warunkiem koniecznym do inicjalizacji bootloadera



lub dwoma......



Pytanie za 10 pkt - jaką wersję wybrałem?



I życie stało się prostsze ..........

a ciąg dalszy dobrze  gdyby nastąpił w jeszcze ciekawszym jak mniemam 2017 r.
Czego sobie i wszystkim życzę......

poniedziałek, 26 grudnia 2016

Arduino.cc i Arduino.org znowu razem

Czy konkurencja jest dobra?


Z zasady nie komentuję bieżących informacji związanych z moją ulubioną platformą ARDUINO IDE ale news o połączeniu sił Arduino.cc i Arduino.org nie powinien zostać bez echa.
Połączenie to pewnie niezbyt trafne określenie - z pierwszego oglądu widać, że na platformie programowej Arduinno.cc wchłonął Arduino.org. Po połączeniu na obu portalach można pobrać najnowszą wersję Arduino IDE 1.8.0, która jest tak naprawdę kolejnym upgrade Arduino.cc


 

I chyba nie ma się czemu dziwić. Od jakiegoś czasu CC wyraźnie przodował  w implementacji kolejnych funkcjonalności i rozszerzeń programu. Moim zdaniem brak możliwości wgrywania zewnętrznych płyt do Arduino.org pozbawił go jakichkolwiek szans na skuteczne współzawodnictwo z konkurentem. A przecież ogromną siłą Arduino IDE w ostatnim czasie była możliwość programowania pojawiających się co i rusz nowych płyt - w tym ulubionej przeze mnie płyty z ESP8266. Włosi okazali się sprytniejsi w biznesie od Amerykanów, przejęli rynek produkcji modułów Arduino i uprzedzili ich rejestrując znak poza Stanami Zjednoczonymi. A amerykanie skutecznie rozwijali oprogramowanie. Więc niby poco to połączenie? Tak naprawdę jak nie wiadomo o co chodzi. .....
Wygrała moim zdaniem komercja. To i dobrze i źle. Dobrze bo będą pieniądze na dalszy rozwój systemu. Źle bo kogoś może skusić możliwość zarabiania na darmowym do tej pory ruchu miłośników i entuzjastów Arduino. Co prawda już zapowiedziano powołanie fundacji Arduino mającej czuwać nad non-profit rozwojem tej platformy ale raczej nie należy mieć złudzeń. Prędzej czy później (raczej niestety prędzej) pojawią  wersje PRO programu Arduino IDE oferujące funkcje zbliżone do ATMEL Studio ale z zachowaniem obecnej łatwości programowania, kompilacji i wgrywania.

Opis historii rozejścia się założycieli i historii rejestracji znaku towarowego Arduino  można poczytać tu>>>>>> .

Czas pokaże co z tego połączenia wyniknie

cdn.......




piątek, 23 grudnia 2016

Własne klocki LEGO - odcinek II

Duży może więcej....

 Od chwili zmuszenia ESP8266 do pracy nie mam już problemów z dostępnością pamięci w małym ATMELu-328. Największy kod BRAMA4 obsługujący wszystko co do tego czasu zaimplementowałem w domowym IoT zajmuje niecałe 20KB. Przerzucenie BLYNKa do ESP-01 dało jeszcze jeden pozytywny aspekt - cały system automatycznie przechodzi w stan pracy autonomicznej przy braku połączenia z siecią lub serwerem BLYNK. W porównaniu z BLYNKiem  zainstalowanym w NANO praktycznie przejmującym  kontrolę nad procesorem przy braku połączenia taki stan to spełnienie  marzeń.

A więc 80MHz  traktor dzielnie ciągnie wózek inteligentnego domu. ESP-01 nie ma jednak żadnych dodatkowych portów możliwych do swobodnego wykorzystania toteż szansa na obciążenie jego taczki  jest już niewielka. Ale gdy pomyślę, że dla powiększenia pamięci NANO wydałbym 10-20 zł to rozwiązanie z dodatkowym ESP-01 (1,6$) jako rozszerzeniem pamięci programu wydaje się super optymalne. A wszystko to niejako przy okazji instalacji WiFi bez, której cała zabawa w IoT pozbawiona jest sensu.

ESP-01 pracuje u mnie jak wzorcowy SLAVE pod komendą z małego NANO przejmując na siebie całą obsługę BLYNK i WiFi. A wszystko to jest sterowane banalnie prostym protokołem opartym na stringu.
"Kxx:yyy" gdzie  K >komenda   xx > nr vPin   :  > separator   yyy > dane
i to wszystko czego potrzebuje ESP-01 by poprawnie komunikować się z BLYNK i wykonywać zlecone mu zadania

Cóż więc takiego robi nasz chińczyk:




Wszystkie procedury związane z połączeniem z BLYNKiem są w programie głównym.
BLYNK_WRITE_DEFAULT() (30-39) odczytuje po resecie i wysyła do NANO wszystkie zapamiętane stany vPinów.
 Blynkwrite(String str2)  (41-67) przetwarza otrzymane z NANO komendy na polecenia BLYNK lub wykonuje je wewnątrz ESP-01.
Na końcu programu mamy procedury migania ledami dla celów kontrolnych. Program główny wygląda nader skromnie.

   


ESP-01 odpowiada przede wszystkim  za nawiązanie i obsługę połączenia WiFi. Ale nie zobaczymy tego w kodzie programu. Wszystko odbywa się na poziomie sprzętowym a niezbędne komendy do uruchomienia całej procedury zajmują jedynie kilka linijek (205-227).U mnie więcej bo dodana została  dodatkowo procedura zmiany domyślnych nastaw logowania do WiFi. Idea opisana jest tu>>>> ale próba implementacji tej funkcjonalności w programy BRAMA kończyła się niepowodzeniem przez brak pamięci w NANO. Dopiero układ dwuprocesorowy pozwolił mi ponownie wrócić do pomysłu i to z pełnym sukcesem. Aktualna biblioteka pozwala zmienić dane logowania WiFi przy użyciu terminala BLYNK i jednego vPrzycisku. Nowe dane logowania zapamiętywane są w EEPROMie.



Biblioteka "transmit.h" spełnia funkcję identyczną do tej w NANO tj. obsługuje łącze serialowe dla wymiany danych z drugim procesorem. Nic tu specjalnego nie ma poza odbiorem w poolingu danych z RS232 i sprawdzeniem poprawności odebranego kodu. To skromne zadanie wzbogaciłem o możliwość "podglądania" odbieranych i wysyłanych danych na serialu i terminalu ESP. By nie zaśmiecać transmisji i nie generować nadmiernego ruchu w domowym internecie funkcje podglądu są zdalnie załączane vPrzyciskami V32 i V33. Taki sam mechanizm został dodany do NANO stąd dwie dodatkowe zakładki w aplikacji telefonu służące jedynie celom testowym. Baaaaardzo przydatna funkcjonalność.

Teraz kilka tygodni testów i zobaczymy co jeszcze trzeba będzie dodać lub poprawić

Przed nami święta więc

Spokojnych Pogodnych Świąt Bożego Narodzenia

I czekamy na cd .....



piątek, 16 grudnia 2016

NANO do D1 mini > "nie chce mi się z tobą gadać"

Czy dedukcja może zastąpić porządny oscyloskop?


Dziś miała być druga część tasiemca o własnych bibliotekach ale zdecydowanie wygrał temat na wskroś elektroniczny. A było to tak ....

Pięknie działający i bajecznie prosto dający się zaprogramować D1 mini postanowiłem użyć jako moduł uruchomieniowy w połączeniu z NANO. Idea była prosta - łączymy oba moduły po serialu a programujemy je i podglądamy przez znajdujące się na obu modułach konwertery USB/serial typu CH340. Dwa moduły - dwa USB - dwa Arduino IDE (CC i ORG) - dwa monitory seriala. Czyli pełna praca równoległa. W teorii bajka - w praktyce ....

Najsampierw próba wgrania do D1 mini ESPowej części kodu BRAMA 3,5 skończyła sie tym co zawsze - moduł ESP pięknie resetuje się co 10 sek pokazując stary (2013r.) SDK. Nic prostszego jak wgranie nowego firmware. Nic prostszego tylko jakie adresy bloków są właściwe dla ESP-12F (4MB flash) Tabela w dokumentacji SDK nie daje 100% odpowiedzi



Adresy dla bloków 512+512 czy 1024+1024?. Wybieram na początek 512+512.
Pytanie drugie - jeśli moduł D1 mini programuje się w Arduino IDE na prędkości 921600 to jak go zaprogramować za pomocą ESP_DOWNLOAD_TOOL_V2.4 kiedy ten ma prędkość max 576000 ?


Uruchomiłem na prędkości 576000 - działa! co więcej działa też na niższych prędkościach. Dziwy jakieś czy co?

Szybko więc wgrywam nowy firmware (opis w poprzednich postach) dogrywam drugą część programu BRAMA 3,5 - i znowu sukces - na porcie seriala cyklicznie pojawiają się komendy do sterowania LEDem w NANO i radośnie miga vLED w aplikacji BLYNK.

Zadowolony z siebie przyłączam płytkę BRAMA3 z modułem NANO i .... kicha. A w zasadzie pół kichy. W jedną stronę chyba coś działa - oba LEDy na płycie NANO migają  ale aplikacja BLYNK pokazuje coś innego - brak komunikacji z NANO via ESP.

Dobrą godzinę zajęło mi szukanie uszkodzenia. Wyraźnie był jakiś problem w komunikacji z NANO do ESP (D1mini). Nie miałem pojęcia czy błąd jest programowy czy sprzętowy. Monitor seriala NANO pokazywał na wyjściu prawidłowe ciągi komend do ESP natomiast monitor seriala ESP pozostawał dziewiczo czysty jakby nic do niego nie dochodziło. A przecież o tylko 5 cm druku na płytce pomiędzy Tx NANO a Rx ESP i 10 cm kabelka łączącego gniazdo ESP-01 na płytce z modułem D1 mini. Połączenie jest a komunikacji nie ma! Niemalże jak w małżeństwie .....

Zrobiłem więc test wersji działającej - z działającego modułu BRAMA 3 wstawiam ESP-01 i dogrywam do NANO poprzednią wersję programu - to działa. Już jest nieźle. Wgrywam więc poprzednią wersję programu do D1. To samo - połączenie  jest ale układy nie słyszą się wzajemnie.
Dziwne bo przecież D1 mini to ten sam procesor co ESP-01 a po drodze na pin Rx na złączu obu modułów nie ma niczego  - oba moduły mają  galwaniczne połączenie tego pinu z wyjściem  mikroprocesora.

Skończyłoby się pewnie na pruciu ścieżek gdyby nie natchnienie. Na płytce BRAMA3 po drodze z NANO do ESP  zastosowałem dzielnik dopasowujący poziomy napięć (z 5 -> 3V3) obu procesorów.




 I choć po drodze pomiędzy pinami NANO i ESP nie ma nic innego niż ten mój dzielnik to jednak na oby końcach dzielnika oprócz pinów procesorów dopięte są piny CH340 z szeregowymi opornikami. Po stronie NANO przyłączony CH340 nie ma żadnego znaczenia - wyjście Tx NANO ma wystarczającą wydajność  i poziomy napięć w tym punkcie napewno są prawidłowe i w stanie 0 i 1. Po stronie ESP sprawa jest bardziej złożona. Na wejściu Rx ESP do napięcia z dzielnika 1k/2k dodawane jest jeszcze poprzez rezystor 470 om napięcie z wyjścia Tx CH340 znajdującego się na płytce D1 mini. Napięcie w punkcie Rx zależy więc nie tylko od stanu wyjcia Tx NANO ale też od stanu wyjścia Tx  CH340. Jakie napięcie naprawdę panuje na tym pinie podczas transmisji serialem  jest nie do pomierzenia żadnym miernikiem - potrzeba już do tego  oscyloskopu. Ale zapewne albo poziom 1 albo poziom 0 wykracza poza dopuszczalne granice i ESP nie dekoduje prawidłowo przesyłanych serialem bajtów.

Stawiam na błędy poziom 0 na wejściu Rx. Problem po zdiagnozowaniu prawdopodobnej przyczyny da się łatwo rozwiązań zastępując rezystor 1 k diodą ( najlepiej diodą shottkyego bo ma mniejszy spadek napięcia) skierowaną w stronę NANO. Dzięki temu niski stan na wyjściu Tx NANO wymusi niski stan + 0,5-0,6 V na wej Rx ESP8266. Zakładam, że tolerancja napięć seriala ESP mieści się w granicach 0 = 0 - 1/3 Vcc   1 = 2/3 - 1 Vcc.  Dioda powinna więc wymusić prawidłowy stan 0.

Po dolutowaniu diody ESP zaczął odbierać informacje z NANO choć dioda przepuszcza prąd dokładnie w odwrotnym kierunku niż kierunek przesyłania informacji - a jednak to działa. Niemalże jak w małżeństwie .....

Wniosek z powyższego doświadczenia jest jeden - trzeba zacząć zbierać do świnki na porządny oscyloskop. Oscyloskopem problem zostałby zdiagnozowany w minutę!

Plan na dziś można uznać za  wykonany
- dwa moduły NANO i D1 mini spięte razem działają - OK


- dwa programy Arduino IDE z programami dla NANO i ESP pracują równolegle - OK


- dwa monitory seriali na COM9(NANO) I COM15(ESP) działają - OK


Czyli stereo i w kolorze .....
I to by było na tyle ...........

sobota, 10 grudnia 2016

Własne klocki LEGO - pierwsze prywatne biblioteki

Każdy śpiewać może trochę lepiej lub trochę gorzej...


Podzieliłem byłem swój program BRAMA na dwie części (opis tutaj) pomiędzy ESP i NANO. To niebywałe jak taki niewinny zabieg ułatwia "panowanie" nad tworzonym kodem.
Stworzenie wąskiego gardła jakim jest serial do wymiany danych pomiędzy modułami znakomicie porządkuje sprawę zmiennych choć na pierwszy rzut oka powinno to utrudniać a nie ułatwiać pisanie nowego kodu. Ale  takie ograniczenie w sposób naturalny zmusza do porządku i dyscypliny w zawiadywaniu zmiennymi. Ogranicza swobodę (a wręcz swawolę) jaką mamy wewnątrz programu kiedy chcemy przesłać informację z jednego segmentu do drugiego. Mogę to zrobić przecież na 1000 i jeden sposobów. I robię. Przez to mapa wektorów przesyłanych informacji pomiędzy programami/funkcjami ww programie (gdyby ją stworzyć) wyglądałaby pewnie jak kłębowisko poskręcanych kabli pod moim stołem. Zapanowanie nad tym jest możliwe do pewnego momentu. Potem trzeba z mozołem śledzić drogę przesyłu takich sygnałów i co one tam po drodze robią lub powinny robić. To konieczność wielokrotnego przeskanowywania całego kodu programu by prześledzić całą ścieżkę od początku do końca i to bez żadnej gwarancji że czegoś tam po drodze nie przeoczyłem.

Stworzona sztucznie "wąska rura" przesyłu danych to rodzaj wiązki z ładnie poukładanymi kablami łączącego pomiędzy sobą różne urządzenia. Nie trzeba już podążać za każdym pojedynczym sygnałem - wystarczy popatrzeć jakie bloki łączy stworzony kanał i jaki rodzaj sygnałów mamy w wiązce. Jeśli jeszcze w jakiś logiczny sposób ponazywamy te sygnały to ich obróbka po obu stronach wiązki znakomicie się upraszcza. Jedyny problem to wybór "szerokości" kanału przesyłowego tak by w przyszłości nie trzeba było pruć całej wiązki by dołożyć jeszcze jeden potrzebny kabel.
Sądzę że właśnie taką funkcję spełniają w programie STRUKTURY i trzeba będzie się nimi zająć na poważnie. Najpierw jednak trzeba nauczyć się dzielić program na niezależne bloki i umieć je wzajemnie skomunikować.

Na pierwszy ognień poszedł kod BRAMY3 nazwany dla niepoznaki BRAMA 3 1/2. To kod oparty na podziale zadań pomiędzy NANO i ESP-01. NANO odpowiada za sterowanie peryferiami a ESP za komunikację z BLYNK. Połączenie obu mikrokontrolerów dokonuje się za pomocą sprzętowego seriala na obu modułach. Robi to wszytko co poprzednie BRAMY:
- symuluje pilota bramy garażowej i sygnalizuje stan otwarcia bramy
- symuluje wszystkie piloty oświetlenia w domu i na zewnątrz
- steruje pompą obiegu CO
- steruje kotłem CO równolegle do bezprzewodowego termostatu
- mierzy temperaturę
- miga ledami i ma inne nieistotne bajery
Kod jest mocno rozwojowy w tej strukturze więc pewnie będziemy do niego wracać jeszcze nie jeden raz.
Po podziale kodu na dwa osobne procesory postanowiłem dodatkowo poszatkować kody na funkcjonalne biblioteki.To taka zabawa/wprawka ale i test czy stosowanie własnych bibliotek w czymkolwiek pomaga przy tak niewielkich (400-600 linii) kodach.

Część zainstalowana w NANO składa się z części głównej kodu zapisanej na chwilę obecną jako brama3v7.ino i wydzielonych bibliotek  "klaw.h", "transmit.h" "dallas.h"  "pompa.h" "piec_co.h"  Nazwy wskazują funkcje programu jakie zostały w nich skupione.
Wszystkie biblioteki znajdują się w podkatalogu głównego programu brama3v7.ino dlatego wywołuje się je poprzez #include "klaw.h" w nawiasach "" a nie w < >.


Program główny brama3v7.ino


W programie głównym są umieszczone podstawowe pętle programu SETUP ( ze wszystkimi ustawieniami początkowymi programu) i LOOP (zminimalizowana do trzech funkcji - obsługi w poolingu timera, odbioru z 433 MHZ i odbioru z RS232).  Zostawiłem też tutaj programy błyskania ledami kontrolnymi na płycie głównej i w aplikacji BLYNK, czytanie stanu przełącznika, testowanie komunikacji z ESP i jego ewentualne resetowanie.

Oznacza to, że NANO pozostało wiodącym procesorem w systemie - kierującym i nadzorującym w całości jego poprawne funkcjonowanie.Pytanie kto nadzoruje NANO jest jak najbardziej uzasadnione. Jeśli NANO padnie lub się zawiesi - na dziś  niestety - powiesi się cały system. Ale to jest tylko stan przejściowy. W następnych ćwiczeniach praktycznych NANO zostanie przeformatowane poprzez wgranie nowego bootloadera tak by uruchomić można było na nim sprzętowy watchdog zawarty w ATMEGA328. Na dziś ze względu na błąd w bootloaderze watchdog wiesza cały procesor. Dodam też być może krosowe sprawdzanie NANO przez ESP i powiadamianie o awarii do aplikacji BLYNK. Ale to przyszłość.

Na razie w programie głównym pozostawiłem wszystkie wywołania procedur uruchamianych zmianą stanów vPinów w BLYNK (66-110) by mieć to wszystko w jednym miejscu i łatwo kontrolować modyfikacje. Chwilowo jest tu też sterowanie i kontrola otwierania bramy (130-155) ale i ona pewnikiem trafi do swojej biblioteki.

Na początku programu głównego zadeklarowane są moje biblioteki "" ale także niektóre biblioteki systemowe < > znajdujące się w katalogu "libraries" użyte w moich bibliotekach. Nie wiem czemu ale musiałem powtórzyć te deklaracje także tutaj by kompilator nie wyrzucał błędów. Dobrze, że nie następuje dwukrotne dołączenie tych bibliotek przed czym ostrzegają wszelakie kursy programowania - sprawdzone.W programie głównym są też deklaracje portów NANO przydzielonych do różnych zadań (37-42).
Nie ma za to deklaracji zmiennych choć znowu wszelkie kursa poprawnego programowania absolutnie to zalecają. U mnie deklaracja zmiennej następuje w bibliotece, w której jest wykorzystywana. Dlaczego? Deklaracja zmiennej w bibliotece "xxx.h" jest widziana w programie głównym a odwrotnie NIE! Również kolejność wywołania bibliotek ma wpływ na "widzialność" zmiennej w innych bibliotekach. Zmienna by być widziana w kolejnej bibliotece musi być zadeklarowana we wcześniej wywołanej bibliotece.
Jeszcze inaczej jest z deklaracjami i wywołaniami funkcji i procedur. I znowu - procedury (funkcje) zadeklarowane w bibliotekach są widziane w programie głównym. Odwrotnie, by biblioteka mogła wywołać procedurę z programu głównego lub innej biblioteki musi na początku tej biblioteki być predefiniowana. Będzie to widać  w kolejnych bibliotekach.

Biblioteka "dallas.h"


Ta moja biblioteka podoba się mi najbardziej - jest krotka, treściwa i zawiera wszystko do obsługi czujnika temperatury DS18B20. Nawet procedury ustawień początkowych, które winny znaleźć się w pętli SETUP są tu mieszczone w osobnej procedurze setdallas() W lini 2 jest deklaracja nr portu z przyłączonym czujnikiem temperatury. Dodanie obsługi czujnika w nowym programie to

- przekopiowania biblioteki "dallas.h" do katalogu programu
- dopisaniu #include "dallas.h" na początku programu
- ustawienia nowego portu czujnika
- wywołaniu procedury setdallas() w sekcji SETUP
i wszystko
   
Biblioteka "klaw.h"



Biblioteka klaw.h to taki zlepek rożnych funkcji przypisanych do symulacji pilota świateł wszelakich w domu i na zewnątrz za pomocą sterowników ELRO. Zlepek bo oprócz deklaracji wszystkich kodów wysłanych lub odbieranych w paśmie 433 MHz (33-58)' deklaracji tabeli kodów poszczególnych pilotów (64-93) i procedur nadawania i odbioru kodów (94-129) umieściłem tu deklaracje kolorów widgetow BLYNK (12-31). Gdzieś je musiałem umieścić i trafiły tu - najczęściej bawię się kolorami zmieniając parametry przycisków w APP BLYNK. Biblioteka jest usługową wobec innych bibliotek dlatego deklarowana jest jako pierwsza. W liniach 123-125 wywołuję procedury znajdujące się w innych bibliotekach. By były one dostępne, na początku musi nastąpić ich predefinowanie (5-8).  Format predefinicji to deklaracja funkcji zakończona średnikiem - koniecznie!
Deklaracja biblioteki #include <RCSwitch.h> jest oczywista bo z niej korzysta program transmisji 433MHz. Mniej oczywista jest deklaracja #include <Arduino.h>. Bez niej kompilator "nie rozumie" wywołania wielu procedur znamiennych dla ARDUINO IDE np. Serial.print(). Choć w programie głównym takiej deklaracji nie ma to wszystko tam działa a tu nie. Pokręcone to trochę jakoś ....

Biblioteka "transmit.h"




Biblioteka "transmit.h" to protokół komunikacji pomiędzy NANO i ESP-01 oraz wywołanie procedur uruchamianych wysyłanymi z ESP komendami. Na początku predefinicje procedur użytych w programie głównym. Odpowiadają one numerom vPinow, ktore je wywołują. To prosty i czytelny sposób porządkowania katalogu wszystkich funkcji związanych ze zmianami wartości na vPinach.
 Niżej (17-44) procedura void Blynkwrite(String str2) odpowiedzialna za dekodowanie nr vPinu i jego wartości (w postaci Stringa) oraz dowiązanie do niego odpowiedniej procedury wykonawczej. To odpowiednik procedury BLYNK_WRITE(VPin) z BLYNKa.

W linii 21 wydzielam fragment przesłanego stringa zawierający nr vPin a w linii 22 zamieniam string na liczbę. Linia 23 to wydzielenie drugiego fragmentu stringa z danymi dla vPinu. Jak zostanie ona potraktowana dalej (jako INTEGER BOOL lub STRING) zależy już od mojej decyzji w procedurze obsługi vPinu.

Dalsza część kodu to część nadawcza bloku transmisji -  formatowanie stringa będącego komendą dla ESP (56-83). A więc funkcjonalnie odpowiada ona procedurze Blynk.virtualWrite(VPin, Data) z BLYNKa.
Jak widać zdefiniowałem 7 typów komend zależnych od typu przesyłanych do BLYNK danych a więc dane typu:
- tekstowe typu STRING (prefix S)
- liczbowe typu Integer (prefix I)
- sterowanie vLED (prefix L)
- sterowanie kolorem widgeta (prefix C)
- sterowanie opisem przycisku - stan OFF (prefix F)
- sterowanie opisem przycisku - stan ON (prefix N)
- inne komendy (prefix O)
Czemu aż tyle? Niestety TYLKO tyle i to jeszcze nie koniec. Chłopaki z BLYNKa odeszli od pięknej początkowej unifikacji wywoływania wszystkich funkcji widgetów poprzez procedurę Blynk.virtualWrite(VPin, Data). Teraz np. by zmienić kolor trzeba wywołać procedurę Blynk.setProperty(pin2, "color", chardata2); stąd potrzeba osobnych komend wywołujących taką funkcję. Niestety to nie koniec bo widgetów przybywa a z nimi konieczność dodawania kolejnych nowych komend. Ale to przyszłość - na razie to co jest wystarcza mi do obsługi moich programów.

I na koniec (84-116) procedury odbioru i dekodowania stringa przesłanego z ESP serialem. Wszystkie komendy wysyłane przez ESP mają prefix "V' i kończą się znakiem /r /n. Te dwa elementy są znacznikami poprawności odbieranego kodu.

Biblioteka "pompa.h"




Kolejna z opisywanych bibliotek "pompa.h" odpowiada za sterowanie pompą obiegową CO.Na początku tradycyjnie już predefinicje procedur przy czym ciekawostką jest konieczność deklaracji void pompazal(); mimo iż procedura ta znajduje się w tejże bibliotece. Problem w tym, że jest ona wywołana wcześniej (33) niż zdefiniowana (38). Czort wie dlaczego taka kolejność nie wywoluje oburzenia kompilatora w głównym programie  a w bibliotekach jak najbardziej. Dziwne to jakieś ......
Pompę uruchamia bądź czujka PIR (52) lub vPrzycisk w telefonie (45)  na czas odmierzany procedurą void licznikobiegu(). Procedura wysyła kod załączania co 10 sek aż do osiągniecia przez licznik wartości 0. Potem odlicza do wartości ujemnych by kilkakrotnie wysłać kod wyłączenia pompy (ot tak dla pewności). W trakcie odliczania na vPrzycisku wyświetlany jest stan licznika (bajer taki) i zmieniany jest kolor przycisku. Wysyłanie odpowiedniego kodu zał/wył odbywa się w liniach 29 i 40.
Jako extras dodałem widget timer pozwalający ustalić przedział czasu, w którym pompa ma prawo się załączyć od czujki PIR. Obecnie to czas między 7:00 a 23:00. Poza tymi godzinami wejście do łazienki nie generuje sygnału załączenia pompy obiegowej CO. Kąpiel o 4 nad ranem? Bez przesady!

Biblioteka "piec_co.h"





Biblioteka umożliwia ręczne zdalne zadanie temperatury (niezależnie od bezprzewodowego regulatora w pokoju) i wyłaczenie grzania gdy czujnik na module pokaże osiągnięcie zakładanej temperatury w pomieszczeniu w którym znajduje się moduł. Temperatura ustawiana jest co 0,5 oC a regulacja posiada histerezę 0,5 oC. Nie jest to jakieś super dokładne ustawianie temperatury bo czujnik ds18b20 nieźle fałszuje (już wprowadziłem korekcję -3oC) ale nie jest to podstawowy regulator ciepła w domu.
Dwa vPrzyciski w aplikacji telefonu umożliwiają nastawę temperatury odczytywaną na wyświetlaczu na vPinie 17
Procedura pieconoff()  cyklicznie porównuje temperaturę zadaną z rzeczywistą i gdy temperatura nastawiana jest co najmniej o 0,5 oC wyższa - włącza piec migając naprzemiennie kolorami wyświetlacza(36). Maksymala temperatura nastawy to 26oC minimalna 13oC

A tak to wygląda wizualnie w telefonie. O zakładkach monitorów opowiem przy okazji opisu programu w ESP-01.





Uff. To najdłuższy post i najdłuższy wygenerowany do tej pory kod. A to dopiero pierwsza część umieszczona w NANO ...........więc cd niewątpliwie musi nastąpić .........


środa, 7 grudnia 2016

Arduino NANO ładuje akumulator

Inteligentny prostownik sterowany z telefonu

Za dużo już tych zabaw z oprogramowaniem mikroprocesorów. Robota czysta i przyjemna - fakt - ale nie ma to jak żywa elektronika. A że trafił się temat więc ....

Budowa prostownika do akumulatorów ołowiowych w obecnej dobie zakrawa na mały żart. Wybór dostępnych na rynku  modeli od 50 zł do ..... bez ograniczenia dla kieszeni zniechęca do podejmowania jakichkolwiek wysiłków typu DIY. No chyba, że stary prostownik się rozsypał i pozostały po nim ciekawe resztki. Wyrzucić szkoda naprawiać bez sensu - pozostaje tylko zagospodarować to co sprawne. Mam więc co najmniej obudowę, transformator i kable. Może nawet bezpiecznik przeciwzwarciowy o ile jest sprawny. Resztę inteligencji się dorobi.


 
 Na początek jakiś schemat - polecimy standardem


 Typowy prosty regulator z MOSFETem  - żadnych zbędnych elementów. Ekstras to ACS712- halotronowy moduł Arduino do pomiaru prądu. Resztę musi załatwić już "inteligentne" NANO. Nie wrysowuję go bo dam płytkę z projektu BRAMA w której poupycham elementy polaryzacyjne do wejść analogowych i sterowanie polówką. Dokładny schemat i wartości elementów będą powstawały sukcesywnie - na razie puszczam gołębia do Chin z zamówieniem części (ACS, MOSFET, mostek prostowniczy - łącznie 3$ + darmowy transport - jak ja to lubię!). Przed nowym rokiem pewnie nie dotrą więc będzie czas pomyśleć nad szczegółami.

No i trzeba poszperać za jakimś oscyloskopem. Tu na czuja nic się już nie zdziała.

A więc do roboty......

sobota, 3 grudnia 2016

D1 mini - ESP8266 profesjonalnie

Inni mogą (jednak) lepiej


Po prawie 50 dniach (chiński rekord długości czasu dostawy) dotarł - D1 mini
Nie ma dwóch zdań - robi wrażenie swoją profesjonalnością wykonania. Za 2,5$ w pełni wypasiona płytka z większością potrzebnych bajerów - pełne USB, stabilizator 3V3, przycisk reset, polaryzacje pinów. Słowem wszystko co potrzeba by odpalić samodzielnie procesor z WiFi bez konieczności dokładania czegokolwiek.



Przy niej mój moduł wygląda trochę jak ubogi krewny z chińskiej polskiej wioski.



Może trzeba będzie do D1 podpiąć przełącznik na GPIO 0 dla celów programowania a może nie. Moduł zaprojektowany dla LUA ma działać podobnie do Arduino - podczas procedury zapisu kluczowe porty (GPIO 0 i RST) mają być odpowiednio spolaryzowane przez linie sterujące  seriala znajdującego się na płytce D1. Czy zadziała to w Arduino IDE - zobaczymy -  D1 mini można wybrać z listy dostępnych modułów więc jest szansa.

Piękne jest również to, że chłopaki z WEMOS El. nie kombinowali przy przetworniku USB/serial i zastosowali poczciwego CH340 przez co i z driverami nie będzie kłopotu.  Z nowszą D1 mini PRO nie ma już tak dobrze - płytka nie ma wklejonego ESP-12 tylko złożona jest na jednym druku z ESP8266 i 16 MB flash (tak tak 16 x więcej niż ESP-07) a serial to CP2104. Na "szczęście" cena oscyluje w granicach 6-7 $ więc jest poza horyzontem moich zainteresowań.

schemat modułu D1 mini


http://escapequotes.net/wp-content/uploads/2016/02/wemos-d1-mini-shematics.jpg

i pinologia

http://escapequotes.net/wp-content/uploads/2016/02/d1-mini-esp8266-board-sh_fixled.jpg

WEMOS musiał nazwać piny po swojemu więc będzie trochę zamieszania w kodach ale nic to za 2,5$ mogę poświęcić odrobinę czasu na przenumerowanie portów.

A więc do dzieła - coś do niego wgramy. Sprawdzimy co ma w środku


I wynik na porcie


Po raz drugi jestem pod wrażeniem - działo to wszystko tak pięknie i bezproblemowa jak z UNO czy NANO. Podłączasz kabel USB naciskasz "Wgraj" i po chwili program masz w pamięci ESP. Naprawdę po chwili bo transfer z ESP hula z prędkością 921600! Nie widziałem do tej pory takich cudów na RS232. Oczywiście to zasługa USB ale CH340 daje radę i nic się nie wiesza. I ta przyjemność nie naciskania niczego (GPIO 0 RST, GPIO 0 RST, GPIO 0 RST  ...... ) dla zainicjowania wgrywania - bezcenna. Mój moduł ESP jest naprawdę mocno zagrożony. A mam tego 16  szt. Przyjdzie pewnie podarować komu ...

Jeszcze ciekawszy jest poniższy programik (też z przykładów dla D1 mini)


Sam szuka poru w ESP-12 z przyłączonym do niego wewnętrznie LEDem (na płytce ESP-12) . Tu znalazł port na GPIO 2. Naprawdę pięknie i nie trzeba będzie przenumerowywać pinów portów w programie -  wyświetlił 2- ale niestety opisy na portach D1 będą już inne.

I to wszystko za 2,5$. Pięknie być elektronikiem w dzisiejszych czasach
Więc cdn ................





piątek, 25 listopada 2016

BLYNK w (prawie) każdym mikroprocesorze

Mikroprocesorowe klocki LEGO czyli BLYNK<4>ALL

Dwa poprzednie posty zainspirowały tenże. Więc trochę logiki

Założenie
Jeśli mikroprocesor posiada > 8 kB pamięci programu i jakikolwiek interface szeregowy (serial, I2C itp)
Teza
 To dodając najmniejszy i najtańszy ESP8266 - ESP-01 można  nim sterować za pomocą aplikacji BLYNK
Dowód
W zasadzie zawarty jest w dwu poprzednich postach :)

Omówienie problemu

1. W wielu uruchamianych systemach mikropocesorowych do komunikacji z procesorem w konfigurowaniu, normalnym działaniu lub w celach testowych niezbędne jest  zastosowanie jakiegoś wyświetlacza (najczęściej LCD) i jakiś klawiszy czy klawiatury. Możemy to zastąpić lub uzupełnić o nowe funkcjonalności dodając do systemu odpowiednio zaprogramowany układ ESP-01  i komunikować się z systemem mikroprocesorowym poprzez telefon/tablet z IOS lub Androidem. Uzyskujemy nieporównanie bardziej uniwersalną, wszechstronną,  tanią a przede wszystkim zdalną możliwość komunikacji sterowania i nadzoru stworzonym przez nas systemem. Możemy więc zdalnie zmieniać konfigurację, wartości początkowe, i inne dane zmieniające zdalnie działanie systemu. Możemy odczytać online  informacje o dowolnych zmiennych, portach, komórkach pamięci czy rejestrach w systemie.
Oczywiście możemy udostępnić część  tych funkcji użytkownikowi końcowemu jeśli jest to niezbędne w normalnej pracy urządzenia. Ponadto w ramach systemu BLYNK  nasz system może wysyłać nam lub użytkownikowi alerty, informacje czy jakiekolwiek dane na telefon, email, facebook,zbiorczej bazy danych  czy gdzie sobie ustalimy.

To tylko początek możliwości jakie dostajemy dokładając do własnego systemu mikroprocesorowego niewielką (2,5x1,6 cm) i śmiesznie tanią (ok 1,5 $ z dostawą do domu) płytkę ESP z wgraną biblioteką BLYNK i z zainstalowaną w telefonie/tablecie darmową (lub za niewielką opłatą dla dużych projektów) aplikacją BLYNK. I to wszytko co potrzeba by skomunikować dowolny nasz projekt z projektantem lub użytkownikiem (przy czym liczba osób równolegle przyłączonych do systemu jest nieograniczona!)

Jak to wygląda w praktyce?

Na przykład do takiej płyty na etapie projektowania dodajemy nasz ESP (w dolnym lewym rogu)

I zamiast (albo obok) komunikować się z systemem za pomocą wyświetlacza LCD i przycisków na płycie możemy to zrobić tak samo albo i lepiej telefonem/tabletem z każdego dowolnego miejsca na świecie - podkreślmy - za 1,5$ :). Mamy wiec dzięki takiemu rozwiązaniu w telefonie wirtualne przyciski. potencjometry, klawiaturę, wyświetlacze ledy wskaźniki  itd itd a nawet terminal!.




Jak to wygląda programowo
W programie naszego systemu mikroprocesorowego dodajemy 3-4kB bibliotekę (mam zamiar zmniejszyć ją do 1-2KB) będącą protokołem komunikacyjnym z ESP-01. Poprzez wywołanie odpowiednich funkcji z biblioteki przekazywane są  polecenia, ustawienia i dane wysyłane z aplikacji w telefonie/tablecie lub wysyłane dane  (bity,bajty, liczby formatu int, stringi ) do aplikacji. Z jakim widgetem połączymy te dane to już nasza fantazja. Możliwości są nieograniczone. A mamy do dyspozycji 128 virtualnych pinów do deklaracji różnych zmiennych. A i to nie wszystko bo dołączony do aplikacji pełnowymiarowy terminal pozwala wprowadzać i wyświetlać nieograniczoną ilość danych.

Struktura systemu BLYNK<4>ALL

Wrysowałem tu jedynie część rozwiązania znajdującą się w systemie mikroprocesorowym. Pozostała część przynależna do aplikacji BLYNK (serwer, telefon z aplikacją)   pozostają niezmienione how-blynk-works.
Dowolny mikroprocesor z zainstalowanym  naszym oprogramowaniem coś tam sobie steruje, mierzy czy błyska ledem na porcie. Dodatkowy niewielki kod ma za zadanie sformatować/zdekodować ramkę danych i wysłać/odebrać ją poprzez jakieś łącze szeregowe. Dla ułatwienia całość obsługi komunikacji BLYNK działa w poolingu z poziomu pętli głównej nie ma więc niebezpieczeństwa zablokowania normalnej pracy mikrokontrolera. Co więcej brak połączenia z ESP czy dalej z WiFi lub BLYNK nie ma większego znaczenia dla poprawnej pracy całego naszego systemu - ot przez jakiś czas nasz układ pracuje w trybie autonomicznym.  
Ramka danych jest najprostszą z możliwych.

Vxx:yyyy/r/n
V   - znak początku transmisji i znacznik rodzaju komendy (litery V, S, I, N, F, O itd.)
xx  - nr vPin lub nr komendy
:     - separator
yyy - dane w postaci integer lub string
/r/n  - znacznik końca ramki zamieniany przy odbiorze na znacznik końca stringu /0

Do wysłania jej funkcją Serial.printnl() skłania łatwość śledzenia transmisji i możliwość korzystania z gotowych procedur Arduino.
I to wszytko co potrzeba by skomunikować nasz procesorek ze światem zewnętrznym i skorzystać z dobrodziejstw gotowej aplikacji do zarządzania.
Klocki LEGO to genialny pomysł.

To zaczyna być naprawdę interesujące .......  więc niecierpliwie czekam na cd ...

piątek, 18 listopada 2016

BLYNK z 8051/2 PIC18 68HC908, HCS08 MSP430 - to już możliwe

BLYNK i ESP8622 w natarciu szerokim frontem


Małe ćwiczenie z programowania ESP8266 i NANO dało niespodziewany efekt - możliwość uruchomienia BLYNKa z każdym praktycznie dowolnym mikrokontrolerem. Jedyny warunek to możliwość wpisania do niego kodu do komunikacji z ESP na którym zainstalowany jest BLYNK. I natychmiast  większość opcji oferowanych przez BLYNK jest w zasięgu ręki a nawet obu rąk.
Poniższy program działa w oparciu o transmisję szeregową RS232 ale nie ma żadnych przeszkód by szybko przekonwertować to na np I2C czy SPI. Serial wybrałem tylko z lenistwa - łatwo go podejrzeć dowolnym terminalem by zobaczyć co w rzeczywistości jest transmitowane na łączach z ESP. Co prawda transmisja serialem ma swoje wady ale jest najprostsza do ogarnięcia.

Na dziś mogę zapisywać dane z i do większości BLINKowych widgetów - wszystkich, które do tej pory używałem. Ponadto udało się zaimplementować możliwość zmiany parametrów widgetów - color, label - co jak dla mnie wyczerpuje na razie potrzeby związane z wizualizacją działań w stosowanych mikrokontrolerach. Do czasu kiedy każdy procesor (lub większość) będzie wyposażony w sprzętowe WiFi połączenie z ESP8266 wydaje się na razie najsensowniejszym rozwiązaniem "usieciowienia" naszego procesora. I najtańszym!

To w miarę finalna (powiedzmy ver 0.1.1) oprogramowania dla ESP i komplementarna część, którą należy wgrać w drugi dowolny mikrokontroler. Kod pisany jest pod Arduino IDE i niektóre z funkcji trzeba pewnie przerobić dla konkretnego typu procesora i standardu języka C.

Kod dla ĘSP-01



Kod "wtyczki" BLYNK dla mikroprocesora



To oprogramowanie pisane i testowane jest pod kątem 32 wirtualnych pinów dostępnych w podstawowej wersji BLYNK ale bez widocznych problemów obsługuje wszystkie 128 vPiny.

Zarezerwowane są następujące vPiny:
- nr 0  > dla vLED. Ledy można dodawać też na wszystkie pozostałe wolne vPiny ale pin nr 0 jest tylko do vLED.
- nr 29 > terminal. Widget terminala jest na sztywno ustawiony na tym vPinie.
- nr 30 i 31 > są zarezerwowane dla ESP (vLED i terminal) na potrzeby testowe

A poza tym wszystko jest do dyspozycji programisty.
 Można przesyłać dane typu Intiger komendą BlynkvirtualWrite_int (nrvPin, data) i tupu String BlynkvirtualWrite_str(nrvPin, str). Dane bitowe czy bajtowe przesyła się jako int. Nie implementowałem przesyłania float bo za dużo z tym zabawy w stosunku do korzyści. Do wyświetlania wystarczy sformatować string a do innych operacji przesunąć przecinek by dostać liczbę całkowitą. Może w przyszłości zaimplementuję Double z liczbami ułamkowymi. Na razie to musi wystarczyć.
Stringi nie są niczym ograniczone poza buforem obu procesorów. Dla pewności wstawiłem ograniczenie do 50 bajtów na jednym stringu.
Dla obsługi vLED jest osobna funkcja BlynkvirtualWrite_led(nrvPin, data). "Data" to jasność świecenia vLED - 0 wygaszony 255 max świecenia.
Zmiany parametrów widgetów to głównie zmiana koloru  BlynkvirtualWrite_col(nrvPin, str)
gdzie str musi być zgodna z formatką koloru tj. #FFFFFF. F to dowolna cyfra w HEX.
Osobna funkcja BlynkvirtualWrite_ON(nrvPin, str) i OFF jest przeznaczona dla zmiany etykiet przycisków w stanie ON i OFF. Na razie nie implementowałem zmiany etykiet innych widgetów - nigdy z tego nie korzystałem i sądzę że to zbędny widget-gadżet.

Najwięcej problemów pojawiło się w najłatwiejszym obszarze - komunikacji szeregowej. Funkcja printnl() dodaje na końcu przesyłanego łańcucha znaki CR i NL a nie dodaje znaku końca stringa /0 o czym zapomniałem a czego nie było widać w standardowym terminalu Arduino IDE. Dopiero program RealTerm   pozwolił podejrzeć co naprawdę transmituje się pomiędzy serialami obu procesorów. Gorąco go polecam bo jest naprawdę świetny.

  
 Dzięki niemu w standardowej procedurze odbioru stringa z seriala dodałem zamianę znacznik końca wydruku /r na koniec stringa /0. I wszystko zaczęło działać. No może prawie wszystko. Okazuje się że transmisja po serialu nie jest taka bezbłędna jak sądziłem - pojawiają się tam czasem jakieś dziwne znaki (przesłuchy ? utrata części znaków przy dużej ilości przesyłanych danych?) które mogą zakłócić poprawność odbieranych danych. Temat został wyprostowany poprzez wstępną analizę formatu odbieranej ramki - ale temat jest niewątpliwie do dalszej analizy. Na razie działa bez większych zakłóceń.
Co ważne obserwowany wcześniej w klasycznym układzie NANO<>ESP8266 efekt "zatykania" się transmisji do APP BLYNK szczególnie przy częstej zmianie parametrów widgetów - tu praktycznie nie występuje. Wszystko przechodzi gładko.

Najpiękniejsza jest objętość kodu w NANO potrzebna do obsługi BLYNK znajdującego się w ESP-01 - 4 kB (13 % pamięci). I to bez żadnej optymalizacji rozrzutnego przecież Arduino IDE.
 Czysty blink BLYNK to prawie 18 kB (60% pamięci). To otwiera całkiem nowe możliwości zastosowania BLYNKa dla procesorów z 16 a nawet 8 kB pamięci programu! ATtiny i BLYNK - oczywiście możliwe choć oczywiście bez sensu.

Jeszcze ciekawszym pomysłem wydaje się stworzenie miniaturowego (wielkości ESP-01) systemu kontrolno-testującego dla dowolnego projektu mikroprocesorowego. Obecnie dla tego celu trzeba stosować rozbudowane wyświetlacze LCD i klawiaturki które umożliwiają "wgląd" do wnętrza programu, ustawienia parametrów,odczytu zarejestrowanych błędów czy uruchomienia testów kontrolnych.  To wszytko można zrobić teraz z klawiatury telefonu a co najważniejsze - z drugiego końca świata. Dla systemów prototypowych po prostu bajka!!! Trzeba na tym pomyśleć bo wydaje się to ogromne rozwojową ścieżką dla zastosowań BLYNKa.


Tyle na razie z frontu walki nad "dziwną" implementacją BLYNKa  cd jak mniemam nastąpi ......


 

piątek, 11 listopada 2016

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 .....

niedziela, 6 listopada 2016

Bezprzewodowy czujnik otwarcia / zamknięcia bramy garażu

O zawiązywaniu buta dżdżownicą

W ładnie działającym sterowaniu bramą garażu brakuje jednego elementu - czujnika otwarcia/ zamknięcia. To niezbędna rzecz jeśli chcemy sterować nią zdalnie. Pierwsze to względy bezpieczeństwa osób. Próba zdalnego zamknięcia bramy otwartej przez kogoś innego może zakończyć się  źle. Standardowa blokada zamykania gdy mechanizm wyczuje opór to za mało. A nie wszystkie bramy szczególnie garażowe mają fotokomórki.
Drugi powód bardziej oczywisty. Sterując z daleka nie mamy pewności czy mechanizm zareagował na komendę pilota. Nie raz zdarza się potrzeba ponownego naciśnięcia pilota by otworzyć bramę czy samochód. Po trzecie czasami dobrze wiedzieć, że ktoś otworzył bramę - ot taka informacja kontrolna np. w domowym systemie alarmowym.
A więc potrzeba czujnika jest . Oczywiście ma to być czujnik bezprzewodowy. I jak zawsze - niedrogi.
Pomysł nr 1
ESP z jakimkolwiek stykiem
Do tego celu wystarczy nawet ESP-01. Ale potrzebny jeszcze zasilacz, obudowa, jakiś styk i dociągnięcie zasilania do miejsca montażu - niby niewiele ale to wykonawczo spory projekt. Na razie na półkę

Pomysł nr 2
Kontaktronowa czujka otwarcia okna / drzwi
Wybór padł na radiowy czujnik otwarcia drzwi / okna od systemów alarmowych np taki. Aliexpress.com. 10 - 12 zł za czujnik z dostawą do domu nie wydaje się dużo.
Czujniki nadeszły - małe zgrabne po prostu ideał.
Tylko mają mały feler - działają w jedną stronę. Czujka wysyła kod jedynie przy rozwarciu magnesu (rozwarciu kontaktronu). Może uda się coś pogmerać w środku by działało w obie strony?



Schemat prosty (powyżej część odpowiedzialna z zwłokę czasową) cały czujnik zrobiony na układzie  EV1527. Niezły chip z możliwością nauki kodu.
Ze schematu wynika że cała idea działania to ładowanie  kondensatora przez dużą pojemność o stalej czasowej kilku sek. W tym czasie otwiera się Q6 a poprzez Q5 podawane jest napięcie na układ i generowany kod. Jest nieźle.
Przerobienie tego na czujnik zwierny zajęło chwilkę - przeniesienie kontaktronu do +VCC i dodanie rezystora 5-10 Mom do rozładowania pojemności. Schemat poniżej


Mam więc dwa ładne bezprzewodowe czujniki  jeden zwierny a drugi rozwierny wysyłające rożne kody. Da się to już zastosować do systemu bramy. Tylko ten montaż dwu osobnych czujników jakoś mi nie pasuje.
Niestety próba upchnięcia obu funkcji na jednej płytce wymaga zbyt dużej ilości przeróbek. Pozostaje wersja nr 2 - zróbmy z dwu czujników  jeden. Wspólne zasilanie, antenka, obudowa i dwie płytki = czujnik zwierno - rozwierny w komplecie.


 I upakujemy wszystko razem w jednej obudowie - miejsca jest dosyć. W górę dumnie sterczy jeszcze dodatkowy rezystor 3 Mom. Niestety nie mam nic miniaturowego w swoich zapasach więc do testów musi tak pozostać.



Magnes jest w odległości działania kontaktronu. Widać sporą rezerwę na ewentualne tolerancję montażu czujnika w docelowym miejscu.

A nagrodę  pozostała mi ekstra piękna antenka 433 MHz, obudowa i baterię na przyszłą wymianę . Co więcej obudowa idealnie pasuje do mojego modułu ESP-07 a więc miejsce na kolejne pomysły urządzeń już jest.



Teraz trzeba tylko zaimplementować czujnik w oprogramowaniu IoT ale to już następną razą.
I dla jasności - nie zadaję sobie pytania czy nie lepiej było kupić gotową czujkę bezprzewodową zwierno-rozwierną. Bo wtedy cały ten blog nie ma sensu :) 

Więc cdn niewątpliwie nastąpi.......

wtorek, 1 listopada 2016

O przewadze zmywarki nad ręcznym myciem garów - biblioteki cd ..

Biblioteka TIMERS.H z daleka i bliska

Jakiś czas temu dotknąłem pobieżnie tematu bibliotek tych genialnych narzędzi programisty I choć to podstawa całej filozofii klocków lego, o której opowiada ten blog to jednak wszystko jest jeszcze przede mną. Zdałem sobie sprawę z tego analizując moją najbardziej ulubioną bibliotekę Timers.h.

We wszystkich programach i tych uruchamianych na Arduino UNO/NANO i tych dla ESP8266 biblioteka Timers.h jest podstawowym zawiadowcą całym programem. Odpowiada zarówno za bezpieczeństwo systemu wymuszając resety ESP i samego Atmela (taki programowy watchdog) i obsługuje główne, zależne od czasu, procedury programu a w tym np. częstotliwość komunikacji z BLYNK.
Jest przy tym nieprawdopodobnie prosta, niezawodna i co ważne - nie wchodzi w konflikt z żadnymi elementami sprzętu czy programu. Po prosu ideał. Ale jak to jest w większością ideałów - dostrzega się to dopiero po czasie .....

Analizując wcześniejsze programy dostrzegam w ilu miejscach przegapiłem możliwość zastosowania tej biblioteki. Zamiast tego pracowicie dziergałem  pętle if....  if .... sprawdzające kolejne warunki liczników zdarzeń.

Świetny przykład  opisu i zastosowania tej biblioteki podał wojtekizk  (pewnie to jego biblioteka choć nie pisze o tym wprost :) ) w programie wytrawiarki. Mamy tu praktyczny przegląd możliwości zastosowania tej biblioteki dla obsługi różnorakich zdarzeń powiązanych z czasem.

Jest tylko jedno ale. Zabrakło tu opisu najważniejszej moim zdaniem funkcji tej biblioteki  - zaszytej wewnątrz funkcji setInterval . Działa podobnie jak funkcja updateInterval ale dodatkowo  zeruje licznik początkowy danego timera co ma kapitalne znaczenie dla nowych zastosowań tej biblioteki.

A biblioteka Timers.h potrafi naprawdę znacznie więcej niż to do czego ją wykorzystywałem do tej pory.

1.Obsługa cykliczna zdarzeń. Najbardziej oczywiste zastosowanie.

#include <Timers.h>
void setup(){
   akcja.attach(0, 1000, zrob_cos_co1sek);  // inicjalizacja procesu
}
 void loop(){
 akcja.process();  //pooling - cyklicznie wywołanie by sprawdzić czy już czas działać
}
void zrob_cos_co1sek() {
//wlasny podprogram do wykonania co 1 sek
}


Wywołanie podprogramu zrob_cos następuje co 1 sek - np będzie to zmiana stanu leda na przeciwny, wyświetlenie wartości odczytanej z czujnika itd itd  Uzyskuję w ten sposób obsługę zdarzeń o częstotliwości dostosowanej do rzeczywistych potrzeb. Umieszczenie programu zrob_coś w pętli głównej  programu spowoduje, że wykonywał się on będzie  (niepotrzebnie) setki lub tysiące razy na sekundę.  Możemy go spowolnić  dodając nieśmiertelne delay(), ale zablokuje to możliwość wykonania innych pożytecznych rzeczy przez procesor. Timers.h rozwiąże ten problem za mnie - odczeka w tle 1  sek nie wstrzymując działania innych fragmentów kodu po czym w odpowiednim momencie uruchomi program zrob_coś.

2.Obsługa cykliczna zdarzeń z dynamiczną zmianą częstotliwości obsługi. To odmiana pkt. 1 pozwalająca na zmianę częstości wywołania programu zrob_cos w trakcie działania programy np. zwiększenia szybkości migania led jako sygnalizacja nowego stanu w procesorze.


#include <Timers.h>
void setup(){
   akcja.attach(0, 1000, zrob_cos);  // inicjalizacja procesu
}
 void loop(){
 akcja.process();  //pooling - cyklicznie wywołanie by sprawdzić czy już czas działać
if (zmiana stanu przycisku)  {
      if (zmiana z 0>1) akcja.updateInterval(0,500); else akcja.updateInterval(0, 1000); 
  }
 
}
void zrob_cos() {
//wlasny podprogram do wykonania cyklicznie
}


 Świetnie nadaje się np. jako wskaźnik błedu/błędów w działaniu programu z wykorzystaniem tylko jednego LEDa. Zaraz implementuję to w nowych programach do sterowania led_OK.

3. Zatrzymanie/ start cyklicznej obsługi zdarzeń. To w zasadzie pkt.2 z z ustawionym czasem obsługi = 0.

#include <Timers.h>
void setup(){
   akcja.attach(0, 1000, zrob_cos);  // inicjalizacja procesu
}
 void loop(){
 akcja.process();  //pooling - cyklicznie wywołanie by sprawdzić czy już czas działać
if (zmiana stanu przycisku)  {
      if (zmiana z 0>1) akcja.updateInterval(0,0); else akcja.updateInterval(0, 1000); 
  }
}
void zrob_cos(){
//wlasny podprogram do wykonania cyklicznie
}


 To świetna sprawa - np. uruchamiam wykonywanie większości procedur głównego programu dopiero po nawiązaniu połączenia z BLYNK ale pozostała część odpowiedzialna za reset ESP czy NANO działa nadal nieprzerwanie.

4 Praca monostabilna - jednokrotne odmierzanie zadanego odcinka czasu. To moim zdaniem jedno z ciekawszych możliwości zastosowań tej do bólu prostej biblioteki

#include <Timers.h>
void setup(){
   akcja.attach(0, 0, zrob_cos);  // inicjalizacja procesu
}
 void loop(){
 akcja.process();  //pooling - cyklicznie wywołanie by sprawdzić czy już czas działać
if (zmiana stanu przycisku z 0>1) akcja.setInterval(0,5000); // zrob cos za 5 sek
}
void zrob_cos()  {
akcja.updateInterval(0,0); //wyłącz timer 
//wlasny podprogram do wykonania jednokrotnie 
}

W momencie PZ następuje jakieś zdarzenie i uruchamiany jest timer na zadany odcinek czasu (koniecznie wywołaniem funkcji setInterval  bo wtedy mamy pewność, że timer odliczy dokładnie zadany odcinek czasu). Po jego upływie timer wywołuje procedurę zrob_cos, która wstrzymuje dalsze odliczanie timera i wykonuje zadany nasz program. Znakomicie nadaje się to do uruchamiania np. pompy obiegowej CO.

Co ważne odcinek czasu na jaki uruchamiany  jest timer może być dowolnie zmieniamy podczas każdorazowego uruchamiania timera a także w trakcie odliczania .
W programie możemy zadecydować  o tym czy kolejny sygnał sterujący w czasie pracy timera  będzie uwzględniony czy nie w procesie odliczania odcinka czasu. Możemy także  sterować zachowaniem timera w zależności od tego czy do zmiany czasu w trakcie odliczania użyjemy funkcji  setInterval   czy też updateInterval . Tym samy dostajemy arcyciekawe możliwości zastosowania biblioteki Timers.h w pracy monostabilnej: 

  1. Praca monostabilna ze stałym czasem - gdy kolejny sygnał wzbudzający timer pojawiający się w trakcie odliczania nie przedłuża odcinku czasu
  2. Praca monostabilna z odświeżaniem czasu - gdy kolejny sygnał wzbudzający timer pojawiający się w trakcie odliczania  przedłuża odcinku czasu o kolejną tą samą wartość.
  3. Praca monostabilna ze zminą czasu - gdy kolejny sygnał wzbudzający timer pojawiający się w trakcie odliczania  przedłuża odliczany okres  nową wartość.
  4. Praca monostabilna ze zminą czasu 2 - gdy kolejny sygnał wzbudzający timer pojawiający się w trakcie odliczania  zmienia odliczany okres. Jeśli timer odliczył już czas nowo ustawianej wartości następuje natychmiastowe wywołanie funkcji zrob_co. Gdy odliczany odcinek czasu jest krótszy niż  nowa wartość, timer "dolicza czas do nowej wartości i wywołuje funkcję zrob_cos.
  5. Praca monostabilna z możliwością zatrzymania timera w trakcie odliczania 
  6. Itd .............

Jak na tak prostą bibliotekę ilość możliwych do wykorzystania opcji rozrasta się imponująco.

Biblioteka ta przypomina mi nieśmiertelny timer NE555 królujący od lat w rożnych aplikacjach częstotliwościowo/czasowych i dla którego wciąż pojawiają  się nowe ciekawe zastosowania.

Z pobieżnego tylko oglądu tej biblioteki widać już jak bardzo potrafi ona ułatwić i uprzyjemnić obsługę wszelkiej maści zdarzeń w tworzonych programach.

Oczywiście nie ma nic za darmo. Wykorzystanie tej biblioteki wiąże się z pewnymi ograniczeniami w programie. Jednak

Nasz program musi pozwolić na wywołanie funkcji akcja.process() w pętli loop na tyle często by nie "przegapić" momentu czasu w którym powinien być uruchomiany podprogram zrob_coś. Jeśli pozostała część programu wykonuje się np w ok 100 ms to wywołanie podprogramu może się w najgorszym razie opóźnić o te 100 ms . Ale dodanie w programie funkcji delay() o czasach rzędu sek lub dłużej całkowicie zaburza działanie tego mechanizmu. A więc stosowanie funkcji delay() lub procedur wstrzymujących obieg programu w pętli głównej jest niedopuszczalne - o ile chcemy mieć pewność, że nastąpi wywołanie procedury zrób_coś w przewidzianym przez nas czasie. Oczywiście taki sam skutek będzie miało wstrzymanie obiegu programu przez program zrob_coś.  
Generalna zasada przy pracy z obsługą typu pooling - często sprawdzać warunek czy działać a jeśli jest spełniony - szybko zrobić co ma się do zrobienia.Często na pierwszy rzut oka nie widać czy dana procedura nie wstrzymuje obiegu programu np w obsłudze czujników przetworników czy modułów komunikacji. Warto taką niesprawdzoną procedurę obsługi umieścić na próbę w pętli głównej i zobaczyć ile razy zostanie ona wywołana w czasie sek. Np.dla czujnika DS18B20 czas przetwarzania pomiaru dla rozdzielczości 12 bitów wynosi ok 750 ms. Jeśli procedura obsługi czujnika wstrzyma obieg programu do czasu uzyskania wyniku pomiaru możemy zablokować sobie cały program tym opóźnieniem. Biblioteka <DallasTemperature.h> pozwala wyłączyć to opóźnienie poprzez wywołanie   sensors.setWaitForConversion(false);
Podobna historia dotyczy przetworników A/C i modułów komunikacji. Wszędzie tam musimy sprawdzić czy nie następuje zawieszenie programu do czasu wykonania przez moduł działania.
W tym kontekście wielką niewiadomą jest BLYNK. W normalnej pracy nie widać w działaniu programu  znaczących opóźnień wynikających z obsługi biblioteki BLYNK.  Ale przy utracie łączności z serwerem lub utracie połączenia wifi cały nasz program się sypie. Opóźnienia wprowadzane przez BLYNK całkowicie dezorganizują pracę np. timera o czasie 1 sek i krótszym.

Ale pomimo tych (przyznajmy niewielkich) ograniczeń biblioteka Timers.h stała się nieodzownym elementem wszystkich moich programów.

Zobaczymy czy po odliczeniu kolejnego odcinka czasu wywoła procedurę ........ cdn();