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