GUI za programerje mikrokontrolerjev – 2. del

Oddaljen dostop brez znanja objektnega programiranja

GUI-O za lokalno povezavo po kablu ponuja USB in Ethernet, za krajše razdalje Bluetooth in BLE ter za oddaljen dostop standardno povezavo preko interneta. Android naprava se povezuje preko WiFi ali enega od GSM protokolov, na strani mikrokontrolerja pa je najenostavnejša povezava preko WiFi modula.

Način uporabe GUI-O aplikacije oziroma sam ASCII protokol je enak na vseh komunikacijskih vmesnikih. Za lokalni dostop je vpis potrebnih podatkov na BT modulih in v GUI-O aplikacijo enostaven in razumljiv. Nekoliko se zaplete pri uporabi internetnih protokolov, vendar brez skrbi. GUI-O od vas ne zahteva poglobljenega znanja o samih protokolih. Izven vašega znanega razvojnega okolja za programiranje mikrokontrolerja ni potrebno spreminjati kode. Za vas so vse naredili GUI-O programerji.  Osnovno vodilo pri razvoju GUI-O je bilo: uporaba primerne standardne rešitve ter kolikor se le da enostaven in avtomatiziran vpis potrebnih specifičnih podatkov. Programerji aplikacije so izdelali zaključen SW, ki ga boste samo uporabili. Da pa boste razumeli, čemu so namenjene osnovne nastavitve, pa je spodaj kratek opis internetnega protokola.

Ko bo izdelek narejen, bo končni uporabnik odprl GUI-O aplikacijo ter po navodilih iz same aplikacije vpisal potrebne podatke za WiFi dostop in niti najmanj ne bo potreboval nobenega znanja o protokolih in rešitvah.

Standardna internetna povezava dveh ali več končnih naprav v novodobnem IoT je preko MQTT strežnika ter istoimenskega protokola. Za potrebe GUI-O komunikacije lahko uporabite GUI-O MQTT strežnik, ali pa seveda s spremembo podatkov katerikoli vaš ali tretji, na primer Mosquito strežnik. Dostop do strežnika je preko podatkov, glej spodaj poglavje: IoT podatki. Najenostavneje je, da začnete z GUI-O strežnikom, saj so na vseh primerih zanj že vpisani potrebni podatki. Ni namen tega članka, da v detajle razlagam MQTT protokol, vendar kljub vsemu nekaj osnov ne bo škodilo.

MQTT (angl. Message Queue Telemetry Transport Protocol) omogoča preprosto implementacijo in objavljanje obvestil v različne teme s pred definirano obliko. Komunikacija poteka preko sheme objavi/naroči (angl. Publish/Subscribe), kjer je za prenos podatkov potrebna implementacija osnovnih ukazov PUBLISH in SUBSCRIBE. GUI-O na MQTT strežniku uporablja MQTT 3.1.1 protokol z visoko stopnjo varnosti (SSL/TLS  Secure Sockets Layer / Transport Layer Security). Sporočila za posamezne uporabnike oziroma naprave se ločijo na osnovi unikatnih id žetonov. Žetoni so v bistvu teme za objavljanje in naročanje, ki ustrezajo Protokolu MQTT v3.1.1.

GUI-O aplikacija omogoča povezovanje preko MQTT strežnika, kjer je namen povezave izključno postavitev komunikacijske poti in ne hranjenje podatkov na strežniku za kasnejše obdelave. Postavitev komunikacije je kolikor se le da avtomatizirana ter končnemu uporabniku skrita. Na strani GUI-O aplikacije so podatki v nastavitvah, generirajo pa se z algoritmom uparjanja (Direct Device Pairing). Podatki se lahko generirajo tudi ,ročno’ z dodajanjem uporabnika (generiranjem podatkov samo na GUI-O strani komunikacijske poti) ter prenosom le teh v kodo WiFi modula. Seveda je za uporabnika priročnejši avtomatiziran način. Podatki na strani WiFi modula se hranijo v samem modulu in se vpišejo z algoritmom uparjanja:

ime omrežja (SSID) hišnega WiFi modema – vpiše uporabnik s postopkom uparjanja s strani GUI-O.

geslo (Password) hišnega WiFi modema – vpiše uporabnik s postopkom uparjanja s strani GUI-O.

Nastavitev podatkov za komunikacijo preko interneta do MQTT serverja (MQTT broker settings) – vpis v izvorno kodo WiFi modula ter možnost spremembe nastavitev v strani GUI-O.

V primeru, da boste uporabili GUI-O MQTT server, so podatki (spodaj zapisani v oklepaju) prednastavljeni tako na strani GUI-O aplikacije, kot v izvorni kodi primerov pred programiranih WiFi modulov. Sprememba podatkov je potrebna samo v primeru, da programer uporabi drug MQTT strežnik. In, Out (Topics) ločijo posamezne komunikacijske kanale med različnimi uporabniki in napravami.

Server name (mqtt.gui-o.com)

User name (gui-o-mqtt-generic)

User password (skrit uporabnikom)

SSL port number (8883)

Client id (Not set)

User: (opcijsko)  – Naprava lahko komunicira z več uporabniki, ko uporabnik proži odzive na napravi, se v komunikacijske stringe dodaja parameter usr:ime

out: (publishTopic) – 32 znakov dolg unikaten string, ki determinira komunikacijo GUI-O -> uP

in: (subscribeTopic) – 32 znakov dolg unikaten string, ki determinira komunikacijo uP -> GUI-O

Naj začnem na strani mikrokontrolerja. Če želite s svojim mikrokontrolerjem povezavo do interneta, morate na UART port priključiti UART/WiFi modul. Seveda lahko kontroler, ki poganja samo napravo, implementira tudi funkcionalnost MQTT protokola, vendar le to v napravo doda veliko kompleksnost. Zato je izvajanje komunikacijskega programa na nek način motnja za delovanje osnovnega programa za podporo napravi. WiFi moduli so običajno na računalnikih in pretvorba signalov v ASCII stringe na UART ni običajna. Tudi sam način vpisa podatkov za dostop do hišnega WiFi modema in podatkov za povezave na internet je predprogramiran na WiFi modulu. Standardnega predprogramiranega UART/WiFi vmesnika z možnostjo vpisa potrebnih podatkov s strani Android naprave na trgu ni. Podjetje Espressif Systems je na trgu z dobro SW podporo in znanima ESP8266 ter novejšim ESP32 modulom. Za ESP8266 je na [1] dostopen SW, ki modul spremeni v UART/WiFi most z vso potrebno funkcionalnostjo uparjanja.

ESP 32 je novejši in zmogljivejši modul in s primerom programa [2] poleg celotne funkcionalnosti za vpis podatkov ponuja tudi programiranje funkcionalnosti naše naprave oziroma zamenja naš mikrokontroler v celoti. Če vam programiranje ESP32 ni ovira in je naprava enostavna, je to primerna rešitev.

Kot sem že omenil, podatki  In, Out (Topics oziroma unikatni žetoni) ločijo posamezne komunikacijske kanale za različne naprave in uporabnike. Če želite maksimalno poenostaviti program na strani WiFi modula, uporabite primer [3], ter ročno generirajte žetone v aplikaciji GUI-O:  Settings -> Quick pair -> IoT devices -> New . Generiran par podatkov Out: , In: ročno prenesemo v izvorno kodo WiFi modula. Ravno tako  v izvorno kodo vpišemo tudi SSID in Password  vašega WiFi modema. Vsi ostali podatki so že vpisani.

Zgoraj naveden primer vpisa potrebnih podatkov (SSID, Password, In:, out:) v WiFi modul ni primeren za izdelek, ki ga razvijate z namenom prodaje na trgu. Od končnega uporabnika ne moremo pričakovati izvajanje zgoraj navedenih postopkov generiranja podatkov in ročnega prepisa podatkov v izvorno kodo ter nalaganje kode v modul. Naprava mora podpirati avtomatiziran vpis podatkov na kar se da prijazen in intuitiven način.

Eden od mogočih načinov je, da uporabnik podatke preko nekega vmesnika vpiše v samo napravo. Naprava pa potem prenese podatke v WiFi modul. Naprava mora vsebovati primeren uporabniški vmesnik, ki omogoča vnos in prikaz ustreznih stringov ter prenos teh podatkov v WiFi modul. Generiranje unikatnih žetonov je na strani aplikacije GUI-O, kar pomeni, da se ročnemu prepisovanju dolgih številk ne morete izogniti. Seveda mora tak način podpirati sama naprava – vsebovati mora nek lokalni uporabniški vmesnik. To je relativno kompleksen način na obeh straneh tako na uP napravi, kot na WiFi modulu in to samo za generiranje in vpis specifičnih podatkov.

Mislim, da vam je že jasno, da to ni pravi način reševanja problema. Radi bi vpisali podatke, pa nimamo vmesnika. Rešitev je v uporabi procedure uparjanja (Direct Device Pairing), ki je primerna za vse naprave.

Postopek, ki je v priročniku [4] opisan v poglavju: Quick pair (stran 36) in Direct device pairing (stran 38).

Ko iz GooglePlay naložimo in stratamo aplikacijo GUI-O, le ta ponudi startna navodila ter po potrditvi na ekranu zgoraj desno ikono + Add  (slika 1 spodaj) preko katere startamo vse načine povezovanja. Izberemo tretji način IoT (Direct device pairing) (slika 2 spodaj).

Tudi preko Settings menu -> Quick pair -> Direct device pairing  dosežemo isti postopek povezovanja.

Običajni način delovanja WiFi modula je STA (stationary mode).  Pri povezovanju pa se z namenom prenosa podatkov v WiFi modul le ta postavi v stanje, ko deluje kot hišni WiFi modem AP (access point mode). To stanje na WiFi modulu lahko dosežemo na več načinov: prožimo ga lahko s tipko na portu D4 WiFi modula, ali s tipko na sami napravi, mikrokontroler v napravi pa potem odda proti WiFi modulu UART komando«!REBOOT_APrn«. Ko pa se WiFi modul uparja prvič oziroma še nima vpisanih veljavnih podatkov za komunikacijo, pa se le ta po vklopu napajanja avtomatsko postavi v AP način. Torej tipka se uporabi samo pri novi napravi (prvo uparjanje) ali selitvi naprave na drug WiFi modul (ponovno uparjanje – sprememba podatkov).

Z GUI-O aplikacijo se povežemo na WiFi modul: Settings -> Quick pair -> Direct device pairing – ter sledimo navodilom.

Vpišemo ime naprave, ki jo krmili naš mikrokontroler. Zakaj je potrebno ime? V primeru, da GUI-O uporabljamo za krmiljenje več naprav, ob startu GUI-O aplikacija ponudi izbor vseh naprav. Dodajanje naprav se izvaja na isti način, brisanje naprav pa se naredi ročno: Settings -> Connections -> IoT  ob napravah nanizanih v vrsticah izberemo ikono na desni strani (smetnjak).

Vpišemo ime uporabnika (neobvezno), če naprava predvideva več uporabniških vlog oziroma različen vmesnik za različne uporabnike.

Dalje v postopku izberemo SSID hišnega modema ter vpišemo Password za dostop. Ta dva podatka se shranita tako v Android napravi, kot tudi v WiFi modulu (po izvedenem prenosu podatkov) ter uporabita na koncu procedure, ko se povezava naredi preko hišnega WiFi.

Sledi navodilo GUI-O procedure za preklop WiFi modula v AP način, slika 3 spodaj. Tekst uporabnika napoti k branju navodil za uparjanje same naprave, kjer uporabnik najde ime naprave in geslo. Na primeru sta ta dva podatka: guio_MACADR in geslo 12345678. MACADR je fiksen na WiFi modulu ter omogoča izbor pravega modula, če je v bližini več delujočih, geslo 12345678 pa se lahko spremeni v izvorni kodi. Za spremembo glej poglavje spodaj: Spreminjanje programa WiFi modula. Za razvoj in hobi je ime guio_MACADR in geslo 12345678 čisto OK.

Preklop modula v AP način se lahko izvede na več načinov:  Najenostavneje je, če prispajkate tipko S2 na D2 pin proti GND na WiFi modulu (slika 5 spodaj). Pin je priključen na IO4 port ESP8266. Isto funkcionalnost dosežemo s pošiljanjem stringa na UART port WiFi modulu »!REBOOT_APrn«. Modul izvede preklop iz STA v AP način, kar jasno pokaže na LED: v STA utripa s sekvenco 1s/1s, v AP pa 500mS/500mS. Na koncu procedure, ko se modul poveže na MQTT strežnik preko hišnega modula, LED sveti. Ko je modul nov oziroma še ni bil nikoli uspešno povezan na MQTT server (še nima veljavnih podatkov v spominu), se po startu avtomatsko postavi v AP način.

Naredimo preklop WiFi modula v AP način – LED hitro utripa.

Ko pritisnemo tipko v GUI-O za nadaljevanje procesa, GUI-O prikaže omrežja, izberemo guio_MACADR (oziroma morda spremenjeno ime naprave v izvorni kodi). Ta povezava nima dostopa do interneta, na kar nas Android opozori. Povezavo kljub temu ohranimo ter se z ,back’  tipko iz sistema Android vrnemo v GUI-O aplikacijo.

GUI-O aplikacija generira žetone (topics-e) in ima sedaj vse potrebne podatke, ki jih prenese tudi na WiFi modul. Nato modul pošlje v STA način in le ta se poveže na MQTT strežnik preko hišnega WiFi modema. Tudi GUI-O se poveže na isti strežnik preko WiFi modema ter odda @init dev:rastlinjak usr:rn  @init je zahteva za inicializacijo, dev:rastlinjak – uporabnik je ob startu povezovanja v polje Device name: vpisal rastlinjak (obvezen vpis), User name: svoje ime pa je pustil prazno (opcijski vpis), zato za usr: ni podatkov.

Pozor! Postopek uparjanja se izvaja medtem, ko GUI-O aplikacija prikazuje časovni bar slika 4 spodaj. Postopek se zaključi s sprejemom inicializacije s strani našega mikrokontrolerja.  Dokler s strani mikrokontrolerja ni odgovora oziroma inicializacije, GUI-O prikazuje časovni bar spodaj tudi potem, ko je povezava preko MQTT že postavljena, ter po dveh minutah pokaže obvestilo, da povezava ni bila uspešna. Za uspešen zaključek povezave je potreben minimalen odgovor na @init … npr.:  |TG UID:tg1 X:50 Y:50rn  Prikaže se inicializiran ekran oziroma stikalo na sredi ekrana.

Izbral sem ESP12F WeMos D1 mini. To je WiFi modul na osnovi ESP8266. Modul s hitro dobavo iz Slovenije dobite na: [5]. Na modulu je že vgrajen USB/UART vmesnik HC340, ki je namenjen programiranju in komunikaciji s PC. HC340 UART je povezan na ESP8266. Isti UART bomo uporabili tudi za komunikacijo z našim mikrokontrolerjem. ESP8266 ima samo en UART port z dvosmerno komunikacijo in dodaten diagnostični Tx port kot UART2. To pomeni, da moramo Tx port proti ESP8266 priključiti vzporedno iz mikrokontrolerja in USB/UART vmesnika. Pri izboru modula pazite, da ima le ta med HC340 Tx in ESP8266 Rx upor, na primer 470R. To omogoča, da na modul naložimo SW medtem, ko je naš mikrokontroler odključen, da le ta na Tx ne vsiljuje stanja. Če bo mikrokontroler s Tx priključen na ESP8266 Rx, nalaganje SW na WiFi modul ne bo uspelo. Lahko uporabite samo stikalo S1 na povezavi Tx, ter ga izključite ob nalaganju SW na modul.

S2 je tipka, ki proži prehod WiFi modula iz delovnega STA stanja v AP stanje za uparjanje z našim hišnim modemom in GUI-O aplikacijo. Stanje STA prikazuje počasno utripanje LED, AP pa hitro utripanje. Če LED sveti, to pomeni, da je povezava preko hišnega modema do MQTT serverja narejena. Kratek pritisk na tipko ne deluje. Pritisk za dalj, kot dve sekundi, šele po spustu tipke proži prehod v AP.

Podobne module na osnovi ESP8266 lahko najdete tudi z drugimi imeni v konfiguraciji skupaj s programatorjem ali brez. GUI-O SW in spodaj predstavljen program je primeren za vse module. Za serijski izdelek je primerneje in ceneje uporabiti modul brez USB/UART vmesnika. Z ločenim UART/USB vmesnikom, ki ga uporabimo kot orodje in ni vgrajen na izdelku, naložimo SW na WiFi modul in nato samo modul vgradimo na izdelek. USB/UART vmesnik lahko ponuja tudi 3V3 izhod za napajanje WiFi modula, vendar preverite zmogljivost tega izhoda. Ob startu ESP8266 rabi cca. 250 mA, v delovanju pa cca. 80 mA. Sam sem uporabil ESP01S in ločen programator na osnovi CP2102, kjer sem moral dodati linearni regulator 5V/3,3V.

Programiranje  ESP8266 na modulu WeMos D1 mini

Po navodilih iz strani [6] sem se lotil reševanja. Če še nimate Arduino razvojnega okolja, prenesete IDE iz: [7]. Naložil sem si IDE 2.1.0 ter po navodilih sprogramiral modul brez poseganja v samo kodo.

Prenesite in odpakirajte izvorno kodo WiFi modula: parameters.cpp,  parameters.h, program_ap.cpp,  program_ap.h, program_base.cpp,  program_base.h,  program_sta.cpp, program_sta.h . Odprite osnovno datoteko PairingMQTT.ino.

Nato na ločen direktorij prenesete arhiv potrebnih knjižnic: [8] ESP8266_GUI-O_pairing_libs.zip in jih ekstarhirajte do prvega nivoja: ArduinoJson.zip   ESPAsyncTCP.zip  ESPAsyncWebServer.zip  PubSubClient.zip  TaskScheduler.zip  . Vključite potrebne knjižnice od prve do pete: »Sketch -> Include library -> Add .ZIP library…«  Pomaknite se do lokacije, kjer je bil ekstrahiran arhiv ESP8266_GUI-O_pairing_libs.zip,  Izberite knjižnico xxx.zip in potrdite (postopek ponavljajte, dokler ni vključenih vseh 5 knjižnic xxx.zip).

Ko je okolje postavljeno, potrebuje ustrezno podporo za ESP8266: Izberite »File -> Preferences« in dalje v polje Additional Boards Manager URLs: vnesete povezavo: [9].

Izberite »Tools -> Board -> Boards manager…« vpišite v iskalnik ESP8266 ter potrdite »esp8266« by ESP8266 Community .

Potem izberite ustrezen HW »Tools -> Board -> ESP8266 Boards -> LOLIN(WeMos) D1 R1 & mini«

Priključite WiFi modul na USB kabel ter odprite ustrezen port za povezavo:  »Tools -> Port -> COMxx«  (Device manager oziroma Upravitelj naprav vam pokaže številko porta na HC340). Če je vse BP, se SW uspešno prevede in naloži na ploščo (druga ikona zgoraj levo -> puščica (Upload)). Če pa ste modul že priključili na svoj mikrokontroler, pa nalaganje ne bo uspešno, ker sta IC340 (USB/UART vmesik) in vaš kontroler na istem UART portu ESP8266. Med nalaganjem odklopite mikrokontroler oziroma JMP. HC340 ima na Tx priključen upor 470R, kar omogoča vzporeden priključitev dveh UART Tx, ko oddaja samo direktno priključen. Rx signal sprejema naš mikrokontroler in USB/UART na modulu, kar lahko opazujete na Arduino monitorju.

V aplikaciji GUI-O se postopek povezovanja starta z ikono + Add  (slika 1) -> IoT (Direct device pairing)  (slika 2) ali preko Settings menu -> Quick pair -> Direct device pairing . Najprej v prvem delu vnesemo podatke hišnega WiFi ter v nadaljevanju podatke samega WiFi modula v AP načinu. Če sledimo navodilom, ni pričakovati večjih problemov. Izmenjuje se delovanje GUI-O aplikacije ter samega Android operacijskega sistema. S tipko Back se vračamo na GUI-O aplikacijo ter nadaljujemo postopek.

Naj ponovim: postopek povezovanja na sliki 4 zgoraj se zaključi, ko GUI-O preko MQTT strežnika proti napravi pošlje @init dev:rastlinjak usr:rn  naprava pa v obratni smeri tudi preko MQTT strežnika odgovori z inicializacijo ekrana na primer |TG UID:tg1 X:50 Y:30rn . Če odgovora s strani naprave ni, GUI-O ne zaključi povezovanja ter predlaga ponovitev postopka. Pred povezovanjem morate na vašem mikrokontrolerju sprogramirati oddajo inicializacije na sprejet @init.

Če  povezovanje naredite samo na WeMos D1 mini modulu, ki je priključen na USB, morate pred tem v Arduino IDE startati Tools -> Serial Monitor ter preko vmesnika simulirati minimalno delovanje naprave. V vrstico za oddajo vpišite |TG UID:tg1 X:50 Y:30  ter na strani GUI-O zaženete proceduro povezovanja.

Na koncu, po določenem času, ko se naredi povezava preko MQTT strežnika (sliki 4) se začne na monitor periodično izpisovati @init dev:rastlinjak usr:rn . Potem na PC prožimo ENTER (in s tem oddajo že vpisane vrstice |TG UID:tg1 X:50 Y:30rn  ) – na ekranu GUI-O se pojavi preklopnik v sredini ekrana zgoraj. V EEPROM-u WiFi modula so sedaj podatki in po resetu modula se le ta avtomatsko poveže na MQTT server (STA način).

Za ponoven start povezovanja morate na serijski monitor oddati !REBOOT_AP in na LED je viden prehod v AP način (LED utripa hitreje).

Program brez sprememb deluje in podpira polno funkcionalnost povezovanja GUI-O z napravo. Lahko pa ga v kaki funkcionalnosti nekoliko izboljšate ter prilagodite vašim potrebam. Spodaj je nekaj primerov.

V program_base.cpp se od vrstice 193 dalje nahaja Program::serialInputHandler() kjer so poleg že navedenega »!REBOOT_APrn« navedeni tudi drugi ukazi za komunikacijo z WiFi modulom. Vsi se začnejo s “!“ . Na “!PINGrn“ modul vrne “!PONG , status’rn“. »!REBOOTrn« modul pošlje v reset. »!CLEAR_PARAMSrn« v modulu briše podatke v EEPROM-u in modul se po resetu postavi v AP mode.

V program_sta.cpp v vrstici 127 se nahaja 500*TASK_MILLISECOND (sekvenca utripanja LED v AP mode sem popravil v hitrejše utripanje)  100*TASK_MILLISECOND  da se status STA 1s/1s močneje loči od AP 100mS/100mS. Če LED gori, to pomeni, da je v STA mode narejena povezava med WiFi modemom in MQTT strežnikom.

V program_ap.cpp vrstica 53 vpišemo poljuben string PSTR(»12345678«). Nar.: PSTR(»JP02_2023«). Če bi vlomilec hotel dostop do naše naprave ter bi jo želel upariti na svoj telefon, mu je to onemogočeno, saj je WiFi modul v normalnem stanju vedno v STA načinu. Za preklop v AP pa potrebuje fizičen dostop do naprave. Geslo je dodatna zaščita, ki deluje v kratkem časovnem oknu v AP načinu.

Če v program_base.cpp vrstica 68 (vpisano ime je sestavljeno iz guio_MAC)

snprintf_P(deviceId, sizeof(deviceId),

 PSTR(»guio_%02x%02x%02x%02x%02x%02x«),

macAddr[0], macAddr[1], macAddr[2],

macAddr[3], macAddr[4], macAddr[5]);

spremenimo v:  snprintf_P(deviceId, sizeof(deviceId), PSTR(»zalivalnik_v2«)); bo ime naprave zalivalnik_v2.

ESP8266 ima en sam UART port, zato je na njem celotna funkcionalnost: nalaganje SW, diagnostični izpisi in delovanje UART/WiFi pretvornika. Ob restartu ESP na port izpiše nekaj informacij s hitrostjo 57600, potem pa aplikacija spremeni hitrost na 115200. Po restartu WiFi modula le ta odda stringe s hitrostjo 74880 baud. Ker sta aplikacija za WiFi modul in naš mikrokontroler nastavljena na 115200, ne sprejmeta znake pravilno. Če boste v config.h  #define _GUIO_SERIAL_BAUDRATE 115200 spremenili v 74880  in seveda tudi na mikrokontrolerju, boste po resetu dobili pravilen izpis. Ne glede na nastavljen Baudrate, se izpis ne zaključi z r. r  naj bi prožil obdelavo in praznil vhodni buffer. Na koncu v spominu ostane ~ld . GUI-O aplikacija starta komunikacijo z  @initnr . Na WiFi modulu se znaki iz GUI-O dodajo v buffer in dobimo ~ld@initnr  . Seveda je komanda napačna in zato izgubljena. To velja samo za prvo oddano zahtevo po resetu WiFi modula. V izogib temu moramo v inicializaciji dodati r. V PairingMQTT.ino v void setup ()   za while (!Serial) { … }  dodamo izpis poljubnega stringa, ki se zaključi z r na primer  Serial.println(123);  in potem bo naš prvi @init nr procesiran pravilno.

Arduino Tools -> Serial Monitor sprejema stringe s strani GUI-O aplikacije (odzive na dotike), ker si USB/UART vmesnik in mikrokontroler delita Rx port (sprejem signalov iz Tx samega WiFi modula). Če želite na monitorju opazovati tudi diagnostične signale (to so preklopi stanj, pomembni podatki) in stringe s strani mikrokontrolerja, odkomentirajte // #define _GUIO_DEBUG v config.h.

Nekaj osnovnih elementov komunikacijskega protokola za sam začetek sem opisal v člankih Sep, Okt, Nov 2021 in Maj 2023. Tu bom samo povzel nekaj bistvenih napotkov. Priročnik in primeri na [10] natančno opisujejo vse elemente in parametre.

Ob vsakem zagonu GUI-O aplikacija, potem ko se naredi povezava, odda zahtevo za inicializacijo @init in nekaj parametrov. Te parametri so namenjeni kompleksnejši uporabi povezovanja več naprav z več različnimi uporabniki. UART interpreter sprejetih stringov v vašem mikrokontrolerju naj odgovori na sprejem prve besede @init ter odda inicializacijski blok stringov.  Če GUI-O ne dobi odziva, se sporočilo ciklično ponavlja, dokler se ne postavi morda porušena povezava.

V grobem lahko komunikacijo ločimo na dva tipa ukazov. Inicializacijski ukazi se začnejo z rezerviranim znakom ,pipa’ | , komunikacijska sporočila pa z rezerviranim znakom @.

Za znakom | sledi koda elementa na primer za gumb (button) |BT ter dalje obvezen parameter, ki določa ime elementa UID:bt1. Med tipom parametra in samim parametrom oziroma vsebino parametra je znak : .

Obvezni parametri vsakega elementa so tudi pozicija X:50  Y:50. Parametra določata položaj elementa na zaslonu in sicer v procentih velikosti zaslona X od leve proti desni in Y od vrha proti dnu ekrana.

Vsi komunikacijski stringi se vedno zaključi z rn.

Ime (UID:ime) je lahko poljuben govoreč string, na primer UID:ventil, a se v praksi uporablja z malimi črkami in zaporedno številko zapisana koda elementa: bt1, bt2, bt3 itd.

Tipični parametri so za rotacijo, na primer obrnemo gumb za 90 stopinj (ROT:90) ali spremenimo velikost W:6 kjer 6 pomeni 6% velikosti (širine) ekrana, določimo barvo, senčenje itd.

Nekaj pomembnih podrobnosti

Parameter TXT:“tekst“ je pri elementih z zapisovanjem stringa na ekran. Torej kreiramo inicializacijski ukaz (string), ki vsebuje parameter z vsebino stringa za izpis. Ker se običajno v programskih rutinah za izpis oziroma oddajanje na UART narekovaj uporabi kot začetek in konec stringa je potrebno oba znaka ločiti: V rutini za izpis se znak “ prenese na sam izpis, če pred njim postavimo “ in tako bo zapis v izvorni kodi sledeč: TXT:“tekst“

Če vam programiranje z uporabo “ povzroča težave, lahko znak “ zamenjate z enojnim narekovajem (‘), zvezdico (*) ali tilda (~).  To izvedete z ukazom na začetku inicializacije @gse TSC:xxrn  kjer je xx ASCII koda zamenjanega znaka.

Pri inicializaciji pazite, da je vedno ,master’ podatek v vaši napravi. Običajno naprava deluje, GUI-O pa na mobitelu zaženete, ko želite nekaj videti ali spremeniti. Inicializiran element, ki prikazuje stanje kot je ON/OFF stikala, vrednost drsnika, izpis odvisen od stanja …itd… morate med inicializacijo ali takoj po njej postaviti v stanje same naprave, sicer vam bo inicializiran ekran kazal napačno stanje.

Ko programirate inicializacijski blok ter spremembe sproti testirate na ekranu, na začetek postavite @clsrn (briše vse elemente). Po resetu vašega spremenjenega programa vaša naprava odda blok podatkov na GUI-O, in le ta bo brisal staro inicializacijo ter postavil novo. Sicer bo prijavil napake, da se imena elementov podvajajo. Brisanje HW elementov naredite z @clhrn (senzorji in aktuatorji na Android napravi).

Če delate GUI, ki bo lepo deloval na ekranih različnih formatov, morate definirati format, na katerega so preračunani parametri kot % velikosti ekrana. Na ekranu z razmerjem stranic ASR:0.449671 (vaš telefon) bo GUI segal od roba do roba, na nekem drugem formatu pa se bo izrisala slika definiranega formata, preostali ekran pa se zapolne z BGC:#FFFFFF barvo. ASR podatek dobite na telefonu, če aktivirate ,Developer mode’ tako da se večkrat zapored dotaknete Settings -> info -> Powered by GUI-O version. Startni ukaz:  @guis BGC:#FFFFFF ASR:0.449671.

Med samim delom je zelo priročno, da se vmesnik postavi takoj potem, ko zaženemo aplikacijo GUI-O. S strani same aplikacije to dosežemo s preklopnikom Settings -> Connections -> IoT -> Autoconnect. Da pa končnega uporabnika ne obremenjujemo s tem preklopnikom, lahko ukaz pošljemo ob inicializaciji iz našega mikrokontrolerja s komando @gse IOTAC:1rn . Uporabnik bo tako samo prvič zagnal s tipko, kasneje pa se mu bo inicializiran ekran pokazal takoj po zagonu GUI-O.

Če gradite vmesnik z več ekrani, uporabite CSI:x parameter, kjer je x od 0 do 4 (5 različnih ekranov). Če parameter ne vpišete, se kreira ekran CSI:0 . Med ekrani se pomikate s potegom po ekranu  desno ali levo.  Lahko pa kreirate nov ekran kadarkoli na primer kot odziv na gumb, kjer z ukazom brišete cel ekran ali le del ekrana: na primer brišemo dve tipki in en zapis @cls UIDS:“tg1,tg2,lb1“rn  ter inicializirate novega. Na tak način, ni več omejitev na 5 ekranov ter navodila uporabnikom za pomikanje med ekrani niso potrebna.

Če je inicializacijski blok stringov dolg ter komunikacija počasnejša, se na ekranu vidi postavljanje elementov, ki sledi prenosu podatkov. To je v nekaterih primerih OK, če vas pa moti, pa na začetek bloka zapišite @slsrn ter na konec @hlsrn .

Sedaj pa sledite svojim idejam, odprite priročnik, poiščite želeni element, kopirate in popravite obvezne parametre, preletite tabelo vseh ostalih parametrov in prilagodite element svojim potrebam. Ko kreiranje elementov ter spreminjanje parametrov postane počasno, si lahko pomagate s simulacijo na PC: [11].

Nekoliko kompleksnejši ekran ima obširen inicializacijski blok. UART vmesnik na mikrokontrolerju in modulu običajno zmore tja do 921.600bps, ali celo več, vendar se izkaže, da ceneni moduli ne zmorejo visokih hitrosti, predvsem pa se kmalu pokaže omejen vmesni pomnilnik za zapis stringov. V takih primerih GUI-O javlja napake, ker prejme stringe z manjkajočimi segmenti. Če ste v dvomih, lahko v Developer mode aktivirate Log incoming messages  (Settings menu → Info → 10 krat hitro pritisnemo na Powered by GUI-O version). Vsi dohodni stringi se zapisujejo v datoteko, kjer jih lahko preberete:  /Android/data/com.guio.guioapp/files/in_messages.log. Rešitev problema je v izboru boljšega komunikacijskega modula, nastavitvi nižjih hitrosti komunikacije ali vgradnji časovnih zakasnitev med krajše bloke inicializacije. UART ,sniffer’ med vašim mikrokontrolerjem in komunikacijskim modulom je dobrodošel, ker vam jasno pokaže morebitno napako v vašem SW, kot je na primer ,tipično’ manjkajoč prvi znak pri oddaji inicializacije po resetu mikrokontrolerja. Seveda je to napaka, ki bo moteča ob izpadu elektrike in ponovni postavitvi sistema.

Ko na vašem mikrokontrolerju dodajate UART2, bodite pozorni na razliko med uporabo terminala in oddajo stringov strani računalnika, kot je GUI-O aplikacija. Terminal oddaja znake počasi in običajno so temu prilagojeni tudi programi. Če imate v main() zanki skeniranje UART sprejemnega registra (polling mode), vam bodo pri sprejemanju znakov v paketu (string z definirano hitrostjo prenosa) izpadli znaki, ki jih main() ni ospel prebrati in prenesti v buffer. Če uporabljate klic prekinitvene rutine (interupts mode) za vsak znak, bodo preneseni vsi znaki, bo pa veliko prekinitev bremenilo delovanje ostalih morda nujnih hitrih procesov. UART vmesnik v osnovi ni namenjen komunikaciji med mikrokontrolerji temveč je bil zasnovan za priklop uporabniške konzole na računalnik, kjer ni procesov v realnem času in ima lahko sprejem znaka prioriteto. UART običajno nima buffer-ja in neobdelan (ne prepisan) znak povozi z novo sprejetim. Najboljša rešitev je uporaba DMA (Direct Memory Access). DMA je namenska HW enota, ki jo je mogoče nastaviti v inicializaciji in preko katere UART prenaša znake v spominsko ciklično tabelo. Obdelava in brisanje sprejetih znakov iz tabele pa mikrokontroler lahko izvaja z nižjo prioriteto (ko ima čas) ter s tem ne vpliva na procese v realnem času.

Članek prikazuje pripravo oziroma programiranje modula na osnovi ESP8266 s funkcionalnostjo povezovanja z aplikacijo GUI-O ,Direct device pairing’ ter delovanje kot UART/ WiFi most za prenos ASCII stringov preko MQTT strežnika. Na podoben način lahko preprogramiramo katerikoli WiFi modul in s tem omogočimo internetni dostop do naprav. Funkcionalnost povezovanja se zaključuje med GUI-O aplikacijo in SW na WiFi modulu tako, da ASCII protokol s katerim upravljamo GUI ostane enak, kot pri lokalnem povezovanju (BT, BLE, USB …).