Ok, zatem mamy już sprzęt, mamy działające połączenie z komputerem, czas zatem na wielką i bogatą w konsekwencje decyzję: co dalej? A dokładniej mówiąc: jaką platformę wybieramy do pisana programów? Decyzja ta jest o tyle istotna, zwłaszcza dla początkującego użytkownika, że idą za nią totalnie różne przyzwyczajenia i zupełnie inna filozofia pracy z modułem. Zatem, co mamy do wyboru? O tym będzie można poczytać za chwilę, ja jeszcze tylko uprzedzę, że spis, który przedstawię będzie z lekka tendencyjny, bowiem pisać go będę z własnej perspektywy, czyli z punktu widzenia osoby, która wyboru już dokonała. niemniej wady i zalety każdego języka postaram się w miarę swych możliwości przedstawić rzetelnie. A póki co, na zachętę i dla udekorowania wstępu zdjęcie chyba najpopularniejszej odmiany ESP8266, czyli ESP-12

• SDK

Nazwa to skrót od Software Development Kit i w założeniach twórców ESP8266 miała być podstawową bazą do komunikacji z tym urządzeniem. Zgaduję tu trochę, ale z lektur różnych stron wyszło mi, że moduł ESP powstał nie jako samodzielny procesor, a raczej jako inteligentny interfejs wireless do wykorzystania przez inne systemy, a SDK służyć miał po prostu do komunikacji z tymże modułem, nie jest to ściślej mówiąc żaden język programowania, a raczej zbiór komend terminalowych AT, przy pomocy którego można się z modułem porozumiewać. Nowozakupione moduły ESP przychodzą z SDK na pokładzie i jedyne, co trzeba tu zrobić, to jak najszybciej usunąć to w diabły, zastępując czymś innym, bardziej… otwartym dla użytkownika, powiedzmy. Co prawda przeszukując internety znalazłem kilka śladów po osobach, które usiłowały coś rzeźbić bezpośrednio w SDK, ale co tu dużo mówić… kondolencje wypada złożyć, ubierając je w jakieś ciepłe słowa w stylu „że też ci się chciało” czy „musiało ci się strasznie nudzić” i temat na tym zakończyć 🙂

• ESP8266 BASIC

Do każdego procesora istnieje jakiś język typu Basic, więc nie mogło go zabraknąć i tutaj. Basic, jak sama nazwa wskazuje, jest „basic”, czyli prosty do bólu i zwykle ubogi w możliwości też do bólu. I choć może nie jestem właściwą osobą do narzekania na ten rodzaj języka (z uwagi na to, że w AVRowym Bascomie całkiem sporo, myślę, że dość zaawansowanych programów zrobiłem), to jednak w tym przypadku Basic został ograniczony do jednego tylko rodzaju zastosowania, czyli do zabaw z ESP jako urządzeniem zdalnym, z poziomu przeglądarki internetowej. Jeśli komuś to wystarczy, to myślę że może to być dobrym wyborem z uwagi na ogromną prostotę tej platformy. Jedyne, co trzeba zrobić, to po podłączeniu konwertera wgrać firmware „Basic” przy pomocy firmowej aplikacji, która właściwie wszystko zrobi za nas, w tym, na samym początku zmieni nasz ESP w accesspoint wifi, do którego normalnie można się podłączyć dowolnym laptopem i z poziomu przeglądarki internetowej przeprowadzić dalszą konfigurację. Cała dalsza obsługa procesora, pisanie programu, jego testowanie, uruchamianie odbywa się w oknie przeglądarki, a z modułem się łączymy tylko przez wifi, więc nie musimy do niego nawet podchodzić. Do prostych zastosowań myślę, że idealna sprawa. Jeśli zaś celem będzie coś więcej, niż zrobienie sterowanego z komórki włącznika, przeszkodą może się okazać mizerne wsparcie i dość ubogie możliwości języka.

Zainteresowanych platformą ESP8266 BASIC odsyłam na stronę jej twórców: https://www.esp8266basic.com/

• ESP Easy

Tu właściwie trudno mówić o platformie do pisania programów. ESP Easy jest softem, który umożliwia budowanie nawet całkiem zaawansowanych projektów metodą ich składania z gotowych klocków. nie zapoznawałem się z tym rozwiązaniem bliżej, więc nie chcę się rozwodzić, by głupot nie pisać, ale wygląda to dość interesująco: oczywiście na ESP trzeba tradycyjną metodą wgrać firmware ESP, podobniej, jak w przypadku ESP Basic nasze urządzenie staje się na krótko access pointem nadającym własną sieć wifi, do której można się normalnie zalogować i dalszą konfigurację robić już z poziomu przeglądarki www. Różnica w porównaniu z Basicem jest jednak zasadnicza: w tym rozwiązaniu nie piszemy kodu. Tutaj mamy graficzny interfejs z możliwością konfigurowania wejść, wyjść, interakcji między nimi i różnych innych cudeniek. Jeśli ktoś boi się pisania kodu i/lub preferuje rozwiązania „klikane”, myślę, że może to być bardzo ciekawą opcją, dzięki której szybko i łatwo zbudujemy nawet całkiem zaawansowane rzeczy.

(źródło: http://www.rwblinn.de)

• NodeMCU

I tu nam powstaje pewien miszmasz, ponieważ w poprzednim wpisie przedstawiłem NodeMCU twierdząc, że jest to płytka developerska, a teraz przedstawiam NodeMCU i mówię, że to platforma programowa. Bo… bo tak. Wszystko się zgadza, NodeMCU to i jedno i drugie. A żeby było jeszcze ciekawiej, jedno nie jest absolutnie od drugiego zależne, można używać płytki NodeMCU bez platformy NodeMCU (korzystając z innej platformy), a można też przy pomocy platformy NodeMCU programować gołe moduły ESP8266. O modułach pisałem wczoraj, dziś będzie o platformie.

Platforma ta bazuje na języku Lua. Jest to język skryptowy, młodszy brat Pythona (czy raczej młodsza siostra – Lua to nazwa portugalska, w tymże języku jest to rodzaj żeński, oznacza zaś ni mniej ni więcej, tylko księżyc 🙂 ), co w skrócie się sprowadza do tego, że w pamięci flash procesora nie mamy skompilowanego programu, tu się nie wgrywa żadnego bina. Szczególną i najistotniejszą cechą tego języka, będącą przy tym jego największą zaletą i zarazem największą wadą jest fakt, że w pamięci procesora mamy program w otwartym kodzie, tak jak został przez nas napisany i jest on przez procesor wykonywany tak, jak skrypt (czyli ogólnie rzecz biorąc, linijka po linijce), z czymś w rodzaju kompilacji przebiegającym w locie, na bieżąco. 

Dlaczego warto wybrać NodeMCU? Bo jest fajny, prosty, a przy tym „wszystkomający”, w internetach jest nieprzebrane mnóstwo poświęconych mu stron, poradników, przykładów i konkretnych realizacji, więc jest się z czego uczyć, jest się na czym wzorować, piękne w tej platformie jest też to, że wszelkie zmiany w programie można robić właściwie w locie, kwestia tylko podmiany zawartości pliku w pamięci, a jeśli trzeba, to pojedyncze komendy można wklepywać ręcznie, wprost w oknie terminala. Dla mnie osobiście plusem języka Lua jest też jego składnia, dość zbliżona formą do tego, co lubię i do czego jestem przyzwyczajony.

A dlaczego NodeMCU wybrać nie warto? Właśnie z uwagi na to, co przed chwilą wymieniałem jako zaletę. Cała platforma językowa jest załadowana do pamięci procesora, co niespecjalnie dobrze wpływa na ilość pamięci pozostającą dla użytkownika, zaś fakt kompilowania programu z postaci skryptowej „w locie” niezbyt dobrze wpływa też na prędkość wykonywania operacji. Są to co prawda ograniczenia, których w większości przypadków nawet nie odczujemy, w internecie znajdywałem pisane w Lua naprawdę duże programy i jakoś działały. Druga rzecz to potencjalna niestabilność. Nie za bardzo wiem, z czego to wynika, ale i czytałem o tym w internecie i sam zdążyłem w trakcie swoich doświadczeń też to odczuć, że program wykonujący się w Lua, zwłaszcza program zapętlony i pozostawiony na czas dłuższy potrafi się z absolutnie niewyjaśnionych przyczyn „wyłożyć”, po czym reset modułu jest niezbędny. Nie jest to regułą, bo gdyby było, język by już sobie dawno zmarł w zapomnieniu, mnóstwo ludzi koduje w Lua i nie narzeka, ale uwag o niestabilności jest w necie wystarczająco wiele, by coś jednak było na rzeczy.
Co jeszcze mi się nie podobało w samej platformie, to jej ubogość. Co prawda pokazane wyżej okno ESplorera, czyli programu będącego dla NodeMCU podstawowym interfejsem użytkownika wygląda raczej jak przeciwieństwo słowa „ubogo”, ale to tylko pozory. Próżno tam szukać choćby głupiej i oczywistej w każdym szanującym się edytorze innych języków programowania kontroli składni. Jedyne, na co tu możemy liczyć to automatyczne kolorowanie słów kluczowych i niektórych typów zmiennych, zaś jeśli strzeliliśmy pomyłkę typu literówka w nazwie zmiennej, czy niedomknięta procedura, to niestety dowiemy się o tym dopiero po próbie uruchomienia programu. I pół biedy, jeśli będzie to widoczny w prawym oknie ESplorera komunikat zwrotny, że cośtam się ze składnią nie zgadza, przy moich pierwszych próbach z Lua, dość regularnie, nawet nie wiem, czy nie częściej mi się zdarzało, że program się  uruchamiał, po czym „szedł w maliny”, co objawiało się np. ustawicznym resetowaniem się procesora w kółko. Gdzie jest błąd – mogłem sobie zgadywać. Jakas pomoc kontekstowa, możliwość podświetlenia słowa kluczowego w kodzie, żeby poprzez prawoklik znaleźć podpowiedź na temat niuansów stosowania tegoż słowa – zapomnij, poszukaj se googlem. Dodatkowy minus to prędkość transmisji szeregowej –  na powyższym obrazku znalezionym w necie jest ustawiona 115200, w sumie nie wiem, jakim cudem, bo moje NodeMCU nie chciało się łączyć na żadnej innej, niż skromne 9600, co w praktyce się przekładało na to, że ładowanie do ESP większego pliku sobie trwało i trwało i trwaaaaaaaaałoooooooooo…. I nie, nie jest to ograniczenie sprzętowe, musi to być kwestia softu, bo sam interfejs między USB a ESP bez problemu pracuje z prędkościami dużo wyższymi, sam w tej chwili używam 512000. Tyle, że już nie z platformą NodeMCU.

Jeśli ktoś chce spróbować swych sił z NodeMCU, to opisów wgrania firmware’u tej platfromy jest w necie mnóstwo, nie będę tego powtarzał, przypomnę tylko to, o czym pisałem wczoraj: jeśli mamy goły moduł ESP8266, to zasilając go wprost z konwertera dodajmy choć dwa kondensatory (100uF + 100nF) na zasilaniu. Albo zasilmy urządzenie z zewnętrznego zasilacza (3,3V!!!). 

I w tym miejscu dochodzimy do ostatniej z omawianych platform programowych, platformy będącej wobec mnie dowodem na prawdziwość starego przysłowia, że tylko krowa nie zmienia poglądów. Pisałem, że nie lubię języka C/C++, bo jako „stary pascalowiec” nie potrafię się przestawić na zupełnie inną składnię, nie rozumiem jej i nie „czuję”? Pisałem! Pisałem też, że nie przepadam za arduino, bo mimo niewątpliwej genialności całej tej platformy, stała się ona dla elektroniki tym, czym aparaty kompaktowe, a potem wbudowane w telefon „cyfrówki” dla fotografii: podobnie jak w przypadku fotografii najczęściej wykonywanym rodzajem fotografii artystycznej jest słitfocia „z dziubkiem”, tak i w przypadku arduino bardzo wiele konstrukcji powstaje metodą ich ulepienia na płytce stykowej i zostawienia w tej formie, robią to ludzie bez opanowanych choćby absolutnych podstaw elektroniki, dla których dobór głupiego opornika do diody led jest wiedzą tajemną, a normalnie narysowany schemat ideowy w przypadku konstrukcji bazujących na arduino stał się już wręcz rzadkością. Pisywałem już o tym wszystkim nieraz i zdania tu nie zmieniłem. Tym ciężej więc przyszło mi zdecydować się w końcu na ostatnią z omawianych platform programowych, jaką jest:

• Arduino IDE for ESP8266

O i to jest właśnie to, co bym tutaj polecał. Pomijając moje osobiste animozje wobec języka C wybór ten ma w sumie same zalety. Wygodna platforma, kontrola składni, pomoc dostępna z menu kontekstowego, bogata biblioteka przykładów i przeogromne zasoby rozwiązań oraz dyskusji nad różnorakimi problemami w internecie. No i przy tym wrażenie robi sama świadomość, że jak się napisze prosty programik do migania diodą LED, to w procesorze będzie siedział tenże prosty programik i nic więcej (z grubsza biorąc), a nie programik wraz z całym kobylastym środowiskiem, w tym wypadku wykorzystywanym w 1%. 
Decydując się na platformę Arduino nie musimy nic wcześniej ładować do ESP, ładujemy dopiero napisany i skompilowany program. I to jest właściwie jedyna istotna niedogodność tutaj: o ile przy pracy z modułem NodeMCU (modułem! nie platformą) załadowanie programu do flasha procesora jest tylko kwestią kliknięcia w przycisk „send”, tak w przypadku gołych modułów musimy niestety wykonywać przy tym całą zabawę ze zwieraniem do masy pinu GPIO0 celem załadowania flasha, odłączaniem go potem i resetowaniem modułu. Nie jest to może bardzo skomplikowane, ale na dłuższą metę, przy pracach uruchomieniowych programu, gdy kod się ładuje i testuje dziesiątki razy, na pewno jest męczące, dlatego mocno bym tu namawiał do zakupienia choć jednego modułu NodeMCU, można sobie na nim testować pisany kod w komfortowych warunkach, a potem już gotowy i przetestowany dopiero wgrać do docelowego modułu.
Być może, zamiast mozolnego zwierania i rozwierania GPIO0 z masą wystarczyłoby wykonać jedno połączenie więcej między konwerterem a modułem i po prostu podłączyć GPIO0 modułu do wyjścia DTR konwertera, ale po pierwsze trzeba by mieć konwerter z takim wyjściem (ten mój później kupiony z CP2303 na przykład DTRa nie ma), po drugie nie jestem pewien, czy to faktycznie będzie działać,  to tylko luźny, nie sprawdzony pomysł.

Okno użytkownika Arduino IDE jest pokazane poniżej (a raczej jego zasadniczy fragment, u dołu jeszcze jest pasek z raportami, na życzenie można włączyć również okno terminala szeregowego), zwłaszcza w zestawieniu z pokazywanym wyżej ESplorerem może zaskakiwać swą ubogością, tu właściwie nic nie ma prócz podstawowych (bardzo podstawowych) przycisków, ale całkiem sporo kryje się pod rozwijanymi menu i jest tam właściwie wszystko, co potrzebne.

Powyższe okno to pokazuje moje wprawki z nauki kodowania w C i jest to oczywiście kamień węgielny początkującego kodera, czyli program do migania ledem. Tyle, że ja go sobie zrobiłem w wersji bez używania pauz i z drugim ledem włączanym i wyłączanym poprzez przerwanie sprzętowe, z jednoczesnym wykluczeniem fałszywych przełączeń od drgania styków przycisku i tym podobnych. Działa! 🙂

Czego mi w Arduino IDE brakuje, a co być może nie jest faktycznym brakiem, tylko wynikiem mojej niewiedzy, to możliwość łatwego operowania wersjami pisanego kodu. W środowisku Bascoma przyzwyczajony byłem do tego, że gdy chciałem szybko sprawdzić jakiś pomysł nie niszcząc jednocześnie tego, co już mam napisane, klikałem w „zapisz jako” i tworzyłem poboczną wersję programu, miałem ją w sąsiedniej zakładce edytora, a fizycznie jako plik wraz z bazową wersją leżała sobie w katalogu projektu. W arduino się tak nie da, tu polecenie „zapisz jako” tworzy cały nowy projekt, z osobnym katalogiem i nową nazwą. Może i ma to sens w przypadku dużych projektów, na które składa się wiele plików, ale mimo wszystko szkoda, że nie można o tym zdecydować samemu. Wystarczyłoby przecież rozbić te polecenia na „zapisz plik jako” i „zapisz projekt jako” albo wręcz w samym „zapisz jako” dodać pole wyboru.

I tyle na dziś, platforma już wybrana, w następnym odcinku może coś napiszę o nauce kodowania 🙂 Ale nie, jak deklarowałem wczoraj, broń Boże nie mam zamiaru pisać jeszcze jednego (którego to już w internecie?) poradnika podstaw kodowania w C, będzie to raczej opis moich perypetii z tematem. Ktoś się może pośmieje, ktoś lepiej obeznany może coś doradzi, a jeśli całkiem przy okazji inny początkujący w temacie dowie się czegoś ode mnie, to i nam (mnie i mojej próżności własnej) będzie z tego powodu bardzo miło 🙂

Zapraszam!