Wszystkomający szablon z VIRTUINO dla programów IoT

Nowy system nowe  porządki. Zmiana programu do obsługi domowego IoT wymusiła nieznaczne zmiany w kodzie moich projektów. Przy tej okazji postanowiłem  zrobić także generalne zimowe porządki i stworzyć coś co zawsze planowałem. Do mojej uniwersalnej płytki PCB, na bazie której tworzę kolejne projekty, chciałem dorobić uniwersalny szablon programu.  Będzie to taki kręgosłup wszystkich moich dokonań programistycznym. I o tym traktuje dzisiejszy wpis.

O swojej uniwersalnej płytce dla modułów ESP 8266 wykonanej małymi chińskimi rączkami pisałem już nie raz (np. tu). Sprawdza się znakomicie w kolejnych projektach zdejmując mi z głowy najtrudniejszy element przygotowania kolejnego modułu domowej automatyki - zaprojektowania i wykonania dobrze działającej elektroniki z mikroprocesorem. Druk jest co prawda w archaicznej formie z elementami przetykanymi ale wciąż nie mogę się przekonać do lutowania miniaturowych elementów pod lupą lub mikroskopem. I tak już pewnie zostanie.

Dzięki uniwersalnej płytce w kolejnych projektach większość konfiguracji pozostaje nie zmieniona. Adresy portów z dołączonymi modułami komunikacji 433MHz, LEDy, przełącznik, optoizolowane wejścia itd itd mają swoje stałe przypisanie do portów co znakomicie ułatwia tworzenie oprogramowania. Płytka ponadto zaprojektowana jest i pod D1 MINI i pod ESP01/01S. Ma to odbicie w oprogramowaniu dla szybkiego uruchamiania i testowania urządzenia.

Do takiej uniwersalnej płytki brakowało mi tylko równie uniwersalnego szkicu, który dałby się łatwo modyfikować dopasowując go od konkretnej aplikacji. 

Podstawową ideą było umieszczenie wszystkich potrzebnych funkcji w jednym szkicu. A najważniejszym zagadnieniem było sprawdzenie czy wszystkie te moduły w wersji maksymalnej konfiguracji mogą ze sobą współpracować i czy nie generują błędów wynikających z rywalizacji o szczupłe przecież zasoby mikroprocesora. Drugą sprawą było umiejętne podzielenie całego kodu na osobne pliki tak by program dawał się łatwo konfigurować (ograniczać) tylko do niezbędnych w danym przypadku elementów.

No i powstał taki kod, który umieściłem na github'ie. Składa się on z szeregu moich bibliotek plus sprawdzone biblioteki innych osób . Stworzyłem  więc sobie wszystkomający szablon oprogramowania i w nim rzeźbię kolejne programy. Jak na razie efekty są zachęcające. Uruchamianie kolejnych funkcji IoT idzie nader sprawnie i szybko a ilość pomyłek w kodzie zmniejszyła się znacząco. Wszystkomający szablon wciąż jest i pewnie będzie uzupełniany ale już dziś oferuje potężny zakres funkcji. Do tej pory umieściłem tam następujące procedury obsługi:

• Blok główny z z setup() i main() - praktycznie niezmienny dla kolejnych programów - zbędne biblioteki i związane z nimi  funkcje umieszczane w sekcji setup i main są remowane
• bibliotekę  WiFi_clock.h a w niej
• połączenie z siecią WiFi
• procedury łączności z serwerem zegara NTP
• procedury transmisji danych do INTERNETU za pomocą REST API
• biblioteką z procedurami dla OTA.h
• bibliotekę myWebSocket.h komunikacji z VIRTUINO
• bibliotekę cloud.h do komunikacji z Arduino Cloud
• bibliotekę no433.h obsługi pilotów i urządzeń radiowych w paśmie 433MHz
• bibliotekę dallas.h obsługi czujnika temperatury na płytce
• bibliotekę eeprom.h zapisu i odczytu danych do flash ESP8266
• bibliotekę led.h obsługi ledów i przełącznika na płytce
• biblioteka piny.h pomocnicza biblioteka konfiguracyjna dla VIRUINO na potrzeby konkretnego programu
• biblioteka program.h zawierająca zasadniczy program dla którego tworzony jest cały kod

Podstawowym problemem było wydzielenie poszczególnych funkcji do osobnych bibliotek i takie ich rozmieszczenie w kolejności by wszystkie biblioteki uruchomiły się bez zgłaszania błędów.

Udało się to zrobić choć nie bez pewnych zgrzytów. Najpoważniejszym jest to, iż rozmiar kodu dla pełnej konfiguracji szablonu urósł do ponad 45% zajętości pamięci programu (dla 1MB pamięci flash) i to bez kodu właściwego programu. Nie jest to jeszcze duży problem ale niebezpiecznie zbliżam się do granicy 50%, poza którą nie będzie możliwe stosowanie OTA przy zdalnym wgrywaniu oprogramowania. Pocieszam się tylko, że przypadków mikrokontrolerów z maksymalnie rozrośniętymi  funkcjami  nie będzie w mojej sieci nazbyt wiele.

W najbliższym czasie zdam relację jak sprawdza się ten pomysł w praniu o czym niechybnie powiadomi nasz ulubiony ciąg dalszy.