Aki programozott már valamilyen PC-n, vagy netán szerveren futó alkalmazást, az hozzá van szokva bizonyos kényelmi szolgáltatásokhoz. Például ahhoz, hogy a program bármikor le tudja kérdezni, hogy mennyi is az idő. Nos, itt egy nagyon limitált eszközhöz van dolgunk, ami ezt mérsékelten képes csak szolgáltatni.

Mit ad nekünk a környezet?

Maga a futtató környezet elég kevés dologra képes, mivel meglehetősen közvetlen a hozzáférésünk a processzor szolgáltatásaihoz. A tipikus Ardu feladatok nagy része megoldható azzal, amit a proci tud, nevezetesen azt tudja megmondani ha kérdezzük, hogy mennyi ideje fut. Ezt milisec pontossággal szokás használni és egy 32 bites változóban kapjuk meg az értéket. Ezt tudja a millis() metódus. Ha egy kicsit utánaszámolunk, akkor a következő jön ki ebből:
- 1 másodperc alatt a számláló 1000-et ugrik..
-> 1 perc alatt 60.000-et.
-> 1 óra alatt 3.600.000-et
-> 1 nap alatt 86.400.000-et.
- 32 biten a legnagyobb ábrázolható szám 4.294.967.295
-> ebből az következik, hogy kb. 49,7 naponta ez a számláló túlcsordul és megint 0-ról kezd számolni.

Ez így elsőre elég tragikusan hangzik, de ha ezt tudjuk előre, akkor tudunk ezzel kalkulálni. Nyilván ez az eszközkészlet teljességgel alkalmatlan arra, hogy meg tudja mondani az eszköz, hogy hány óra hány perc van, arra meg pláne, hogy hanyadik hó hanyadika! 

Mit adnak nekünk a lib-ek?

Nem meglepő módon más is szembesült már a problémakörrel, így született rá rengeteg megoldás. Én ezek közül az egyik "gyári" megoldást favorizálom, a TimeLib.h nevűt. Ez egy olyan könyvtár, amit helyből ismer az összes fordító, így telepítést nem igényel. (A csomag része egy Time.h header fájl is, de mivel ez annyira általános név, hogy ebből több lib gyűjtemény is tartalmaz ugyanilyen nevűt, ráadásul ez nem tartalmaz semmi mást, mint azt, hogy "#include TimeLib.h" sort, így egyszerűbb és megbízhatóbb a TimeLib.h használata.)

Lássuk ez mit is tud! Itt van a hivatalos dokumentációja: https://playground.arduino.cc/Code/Time
A leg lényegesebb funkcióknak elég lényegre törő nevet sikerült találni: hour() minute() second() millis() day() weekday() month() year(). Ezek mind úgy működnek ahogy az ember elsőre gondolja: ha mindent lekérdezek, akkor egy pontos időt tudok kirakni. Ami még jó ebben a lib-ben, hogy minden metódusnak van olyan változata is, aminek be lehet adni a now() hívás kimenetét, ilyenkor nem az aktuális órát, percet, stb adja vissza a hívás, hanem a paraméterként kapott időpillanatból számolja ki, hogy mennyi is az annyi. Vannak még olyan funkciók, amik segítik a 12/24 órás számítást, illetve a hónapok és a hét napjainak a szöveges megjelenítését (angolul) de ezek szerintem egy beágyazott rendszerben nem annyira fontosak. Ami viszont fontos még, hogy ez a lib honnan is fogja tudni, hogy mennyi a pontos idő? Hát onnan, hogy van setTime(t) függvénye, aminek vagy egy átadunk egy time_t típusú változót, vagy a másik overload-olt alakját használjuk: setTime(hr,min,sec,day,month,yr).

Ez mind nagyon kényelmesnek tűnik, 2 apró bökkenő van csupán:
1. Minden indulás vagy RESET után újra be kellene állítani az időt, mivel a háttérben ugyanazt a rendszert használja, amit az első fejezetben taglaltam, ha pedig nincs tápellátás, akkor ugye nincs időmérés sem!
2. Ezek a kis gépecskék a legritkább esetben rendelkeznek olyan felhasználóbarát felülettel, ahova könnyen be lehetne adni az időt...

Mit ad nekünk az RTC?

Ezzel el is jutottunk oda, hogy mire jó az RTC! Az RTC a Real Time Clock nevű alkatrészcsalád angol nevének rövidítéséből ered. Ilyen alkatrész nagyon sok helyen van, például a PC-kben is szokott lenni, de mint külön részegységet nem veszi senki figyelembe, a BIOS-on keresztül lehet hozzáférni általában. Mivel az Arduino dedikáltan és felvállaltan az olcsóságról szól, így ezt sem építik be a gépbe, mivel nagyon sok olyan alkalmazás van, ahol teljesen lényegtelen mennyi is a pontos idő.

RTC-ből sok fajta van, de mind elég hasonlóan működik: egy IC a lelke mindnek (na nem mindnek ugyanaz az egy típus) ami tulajdonképpen arra van kitalálva, hogy folyamatosan számoljon, olyan pontosan ahogy csak tud. Mivel a cuccnak akkor is működnie kell, ha nem kap tápellátást, így szokott lenni egy gombelem is rajtuk. Hogy az alkatrész meg tudja mondani mennyi az idő, ezért egyfajta buszt kell még rajta elhelyezni, amivel tud majd a mi kis gépecskénk kommunikálni vele.

A képeken az egyik legprecízebb típus látható, a DS3231. Amiért ezt szeretjük, az 3 dolog:
- I2C buszon kommunikál. (Erről terveztem egy posztot majd.)
- Tényleg nagyon pontos.
- Olcsó. (1 dodó alatt van az Alin.)

A buszt most nem részletezném elég annyi, hogy egy szabványos kommunikációs protokollt használ, amire egyszerre több más eszközt is fel lehet fűzni. A pontosságának a titka a belső hőmérő. A dolgot úgy kell elképzelni, hogy a képen látható IC-ben benne van egy quartz kristály, amiről a gyártó pontosan tudja, hogy milyen frekvencián rezonál. Szobahőmérsékleten. Ám ha változik a környezet hőmérséklete, akkor változik a kristály rezgésszáma, ami ahhoz vezet, hogy pontatlan lesz az óra! Ha 32 kHz helyett mondjuk 32.001 Hz jön létre a valóságban, akkor ez azt jelenti, hogy minden 32.000-ik másodpercben már egyet csal a számlálás. Vagyis durván perenként 2 ms-ot. ez már óránként 0,12 másodperc! Ez elég sok, mert bár minimális az eltérés, amiből kiindultunk, de egy hónap alatt már ez is durván másfél percet jelenthet! Ennek a pontatlanságnak a kiküszöbölésére építettek egy hőszenzort az IC-be, ami korrigálni tudja ezt a pontatlanságot, vagyis ha sokat volt melegben a szerkezet, akkor időnként levon egyet a saját számlálójából, míg nagy hidegben hozzáadogat. Elég okos kis cucc, nem? Ami nekem hiányzik róla az a gombelem egészségének ellenőrizhetősége: nem tudjuk hogy jó-e még az elem, vagyis hogy mi fog történni, ha elveszíti a tápot az alkatrész. Lehet jól fog tovább számolni, de lehet meghal. Annyit tud még a cucc, hogy meg tudja mondani magáról, hogy pontos-e az idő, amit visszaad: vagyis ha elveszti a tápot majd ismét magához tér, akkor (ha megkérdezzük) meg tudja mondani hogy pontos-e, vagy az elem hibája miatt teljes hülyeséget kapunk vissza.

Végeredmény

Ami az egésznek a végső tanulsága: a felsorolt dolgokat könnyedén egybe tudjuk gyúrni. A TimeLib-nek van egy olyan nagyon okos funkciója, hogy periodikusan képes egy ún. SyncProvider-t kérdezgetni, hogy mennyi az idő. Ez lehet egy RTC, vagy GPS, vagy akárt NTP kliens is. (Ezekről majd később még fogok értekezni.) Esetünkben könnyen összehozható, hogy a rendszer mondjuk percenként (vagy akár óránként ha úgy szeretnénk) megkérdezze az RTC-nket és ehhez állítsa a saját belső "virtuális óráját". (setSyncProvider(getTimeFunction) és setSyncInterval(interval) metódusok kellenek ehhez.)

A szokásos probléma, hogy "nem nagyon van könnyen kezelhető felhasználói felületünk" pedig kiküszöbölhető egyszerűen: építeni kell egy olyan eszközt, amibe ha bedugjuk az RTC-nket, akkor azt internetről beállítja nekünk rajta az isőt. Ezután a már helyesen ketyegő RTC-t át lehet dugni a felhasználás helyére, ahol nem is kell legyen egy árva gomb se. Ezt a beállító-eszközt is be fogom majd mutatni, de ahhoz vagy wifi, vagy Ethernet modul fog kelleni, netán egy olyan Ardu típus, ami már eleve Wifi-vel van szerelve - mondjuk egy NodeMCU.

Pár hónapja jót mosolyogtam a Telekom egyik reklám-akcióján: link
Nagyon egyszerű dologról van szó, egy bazi nagy gomb, amit ha megnyomsz elkezd csörögni a telefonod. Imádott drága nejem gyakran keresi a telefonját, nem ritka, hogy megkér "Csörgess már meg légyszi!"

Ezt ugye nem tűnik annyira bonyolultnak megvalósítani az Arduino eszközeivel. Egész pontosan ESP8266 alapú rendszerre gondoltam, amit beépítek egy viccesen hatalmas gombba:

Ezt kivételes nem Aliról rendeltem, mert ott nem találtam, vagy csak nagyon drágán! E-bay viszont jó választásnak tűnt, most épp várom, hogy megérkezzen a projekt legdrágább alkatrésze! :)

Mivel én nem egy mobilszolgáltató eszközeivel rendelkezem, így kénytelen leszek a "csörgést" magam implementálni valahogy. Szerencsére nejem telefonja is Androidos, így tervbe van véve egy egyszerű kis programocska Androidra, ami csörögni fog - még ha néma üzemmódban is van a telefon, legalábbis nagyon remélem!

Aki hozzám hasonlóan fejlett nyelvekkel dolgozott korábban, annak az egyik első kérdése: milyen fejlesztőeszközzel lehet ezt a dolgot művelni? Nos, több lehetőség is van, végigveszek párat, amivel személyesen is találkoztam/próbálkoztam.

1. Arduino Web Editor

Ez az egyik legkézenfekvőbb eszköz, több előnye mellett azért vannak hátulütői is. Az arduino.cc oldalon belül válaszd ki a SOFTWARE pontot és már tolja is a képedbe hogy "Try It Now". Természetesen igényel egy gyors regisztrációt.

Előnyei:
- Nem kell telepíteni semmit.*
- Bárhonnan nyitod meg, ugyanott folytathatod, ahol abbahagytad legutóbb. Úgy értem több PC-n is dolgozhatsz ugyanazon a forráskódon.

Hátrányai:
- Nincs kódkiegészítés, kódkiemelés
- Nem jelzi azonnal, ha szintaktikailag hibás a kód, nyomkodni kell a Verify gombot, ami elindít egy fordítást a szerveren.
- Library fejlesztés nem megy benne - vagy legalábbis én még nem jöttem rá hogy lehet elérni, hogy editálhassam a lib-emet, majd rögtön próbálgathassam is.
- Mégiscsak kell hozzá telepíteni valamit!* 

Szóval alapvetően ha az ember csak a kódot akarja szerkeszteni, akkor nem kell telepíteni semmit, de amint fel is akarja tölteni a produktumot egy eszközre, akkor telepíteni kell egy plugin-szerűséget. Ez van Windows-ra és Linux-ra is (valszeg MAC-re is, de ezt nem próbáltam). Tulajdonképpen egy háttérben futó, tray icon-os programról van szó, ami ha csatlakozik egy virtuális soros port, azt ő felismeri és hozzáférést ad ehhez a böngészőből. (Linux alatt lehet gond a /dev/ttyUSB* eszközök hozzáférési jogosultságaival, de aki Linux-ot használ, azon talán nem fog majd ki egy chmod parancs.) Ha ez megvan, akkor az oldal tetején ki lehet választani, hogy melyik soros porton milyen típusú Ardu van csatlakoztatva. Igen, a típust nem tudja automatikusan felismerni a tool, de ezen azért túl lehet lendülni. Figyelem! Az Uno és a Nano szinte teljesen megegyezik a mi szempontunkból, de ha nem jót választ ki az ember, akkor a feltöltés nem fog sikerülni!

2. Arduino IDE

Ez a második legkézenfekvőbb megoldás. Ezt is az arduino.cc oldalról lehet letölteni, természetesen ingyen. Nagyon hasonlít a web-es verzióhoz (talán mert a desktop változat alapján készíthették a web-est?) pár dologban azért van eltérés.

Előnyei:
- Ez egy eredeti, karbantartott és folyamatosan fejlődő eszköz. A hivatalos IDE.
- Nagyon egyszerű telepíteni

Hátrányai:
- Szemben a web-es változattal, itt csak az adott gépen lévő forráskódot lehet szerkeszteni. (Én még nem találtam hozzá SVN/Git/etc kapcsolódást segítő funkciót vagy kiegészítőt.)
- Itt sincs kódkiegészítés, se kódkiemelés
- Szintén a "Verify" gombra kell kattintani, ha le akarja az ember fordítani a forrást, enélkül nem látszik ha szintaktikai hiba van benne.
- Library fejlesztésre szintén nem találtam még jó megoldást benne.

3. Eclipse Arduino IDE

Ezt egy független ember/szervezet fejleszti. Innen lehet letölteni ingyen: http://eclipse.baeyens.it/
Aki szereti az Eclipse-et mint fejlesztőeszközt, az valószínűleg élvezni fogja ebben a munkát.

Előnyei:
- Ez igazából egy Eclipse plugin (vagy plugin gyűjtemény, nem tudom pontosan).
- Van kódkiegészítés, kódkiemelés.
- Lehet vele lib-et is szerkeszteni
- A program el tudja intézni a feltöltést is egy gombnyomással.
- Könnyedén lehet akármilyen Eclipse plugin-t rakni még rá, szóval a verziókezelővel való integrálás is könnyedén megoldható.
- Itt is van soros port-hoz konzol.

Hátrányai:
- Ez egy Eclipse. Van aki nem kedveli, más fejlesztőeszközhöz van szokva, nem állnak kézre a billentyűkombinációk, stb.
- Nyilván nem fogja azt tudni, amit a web-es editor, nevezetesen, hogy mindig ott folytathatod ahol abbahagytad, akárhonnan használod is a cuccot. Ezért persze tud kárpótolni a verziókezelők intergálhatósága.
- Elég bonyolult a saját lib-ek kezelése, build path és egyéb nyalánkságok nagyon meg tudják keseríteni az ember dolgát.

4. Atom + Platform IO

Egy barátom ajánlotta az Atom nevű szerkesztőt, aminek van egy remek funkciója: a képernyő jobb oldalán van egy "minimap", ami megkönnyíti a hosszú forráskódban való navigálást. Ez nagyon jól hangzott, mivel az egész Arduino platform arra van felkészítve, hogy szoftverfejlesztésben kevésbé járatos szakemberek is tudjanak boldogulni, de ennek velejárója, hogy rosszul szervezett kódok burjánzása elég gyakori!

Előnyei:
- Minimap
- Sok plugin, Én ezek közül az egyik legnépszerűbbet próbáltam életre kelteni: PlatformIO.
- Kódkiegészítés és kódkiemelés: nem is lehet kérdés!
- Biztos van még sok, de...

Hátrányai:
- Nekem nem sikerült használható állapotba hozni! Tornáztam rajta pár órát, de egy Hello World-öt sem sikerült fordítani és feltölteni az eszközre.
- Igazából nem is nagyon igazodtam el benne, nem találtam semmit, de ez simán lehet az Én korlátoltságom.

És a konklúzsön...

Még nem találtam meg az ideálist. Ha csak egyszerű kódokat akarok szerkeszteni, akkor a Web IDE-t használom, ha bonyolultabb projektről van szó, akkor... talán IDE, de az sem tökéletes. Ha megtalálom a tökéleteset, majd megírom!

Addig is várom az ötleteket, ha valakinek van jobb ötlete!

Próbálom összeszedni a gondolataimat, hogy milyen projektekben gondolkozok még és ugranak be folyamatosan a tervek...

Van egy nagyon jó kis ledes, kivetítős óránk a hálószobában, amit a fiam sikeresen legyőzött! (Most 88:88-at mutat ha bedugom.)

Ebben van ugyan egy FM rádió, meg képes 2 külön beállítható időpontban ébreszteni, de mi csak és kizárólag azt a részét használtuk, hogy a plafonra képes kivetíteni a pontos időt. Ez egy tök sötét szobában annyira kényelmes dolog, hogy az első nap nélküle szinte fájdalommal jár!

Ez a projekt is egy távoli dolog lesz, mivel a tervem az, hogy kibelezem teljesen és csak az első és a kivetítős LED kijelzőket hagyom meg belőle, a belseje meg egy ESP lesz, ami netről fogja tudni mennyi az idő. (Van tervbe véve NFC kommunikáció is, hogy megmondhassam neki mi a Wifi SSID és jelszó, de ez aztán már tényleg nagyon távoli terv.)

Ebben az igazi kihívás a reverse engineering lesz: ki kell derítenem milyen módon tudom a kijelzőket életre kelteni és utána meg kell építenem újra a belsejét a cuccnak, ami ugyanazt műveli majd mint a gyári panel. A temérdek sok gombot egyelőre ki fogom kukázni, nulla gombos interfésze lesz a terméknek!

Vegyük sorra a dolgokat és hogy miért/mire is jó az Arduino platform. Az Arduino eszközök lelke egy úgynevezett mikrokontroller, ami olyan mint egy nagyon leegyszerűsített számítógép processzor. A legtöbb Arduino lapon az Atmel cég mikrokontrollerei vannak, itt egy összehasonlítás a különböző változatokról: link

Lássuk mik is az oszlopok:
- Name: ez a board neve. Mindnek szoktak ezek az olasz csávók nevet adni, hogy ne valami hosszú számsor azonosítsa a lapkákat. Amivel én foglalkozok mostanában az az Uno és a Nano. Ezek a legolcsóbbak, amiket azért még viszonylag egyszerű kezelni/használni. (Vannak ennél is olcsóbbak, de azok már kompromisszumokra késztetik az ember fiát.)
- Processor: hogy milyen "agya" van az adott gépnek. A legtöbb a már említett Atmel gyártótól származó AT kezdetű processzorra épül, de van már Intel és más is.
- Operation / Input Voltage: na ez már talán nem annyira egyértelmű, mint az első két oszlop. Ezek a parányi kis számítógépek a processzoron kívül még pár alkatrészt szoktak tartalmazni, amik közül az egyik a feszültség szabályozó (angolul voltage regulator) nevű alkatrész. Ennek az a feladata, hogy a processzor számára ideális feszültséget állítson elő. Ez a folyamat általában a kicsi és olcsó alkatrészekben veszteséggel szokott járni, így jellemezően egy magasabb feszültségből szoktak alacsonyabb, de stabil feszkót előállítani. A legtipikusabb ilyen alkatrész a 7805 névre hallgató "stabilizátor kocka" amit jellemzően 7-12 V bemeneti feszültségből állít elő stabil 5 Voltot (ez a nevében az utolsó 2 karakter). Szóval ebben az oszlopban azt jelölik, hogy a processzor milyen feszültségszinttel dolgozik, a per jel után pedig, hogy az alaplap bemenetén milyen feszültség tartomány az ideális. Ennek később látjuk majd az értelmét. Az Uno és a Nano is 5 V-on szeret dolgozni, de ennél magasabb 7-9/7-12 Voltokra van szüksége a fesz szabályozójának.
- CPU Speed: ezt talán nem kell sokat magyaráznom, ilyen órajelen dolgozik a processzor. Itt talán mai szemmel nagyon kicsi számok vannak, de ahhoz, amihez ezeket használni szoktuk, illetve használni érdemes, ahhoz ezek az órajelek tökéletesen megfelelőek! A két kedvencünk 16 MHz-en ketyeg, ami azt jelenti, hogy 1 másodperc alatt 16.000.000 ütem zajlik le, vagyis ennyi elemi utasítást képes a processzor végrehajtani.
- Analog In/Out: analóg be és kimenetek száma. Azoknál a változatoknál, amiket én favorizálok analóg kimenetekről nem beszélhetünk, de bemenetei vannak a gépeknek. Hogy ez mi is, azt talán úgy a legegyszerűbb leírni, hogy ezeken a lábakon meg tudja mérni, hogy milyen feszültség van jelen egy adott pillanatban. Vagyis nem 0-1 értéket képes mutatni, hanem mondjuk egy 10 bites számot ad vissza ha lekérdezzük, vagyis 0-1023 lehet az érték. Ez mondjuk jól jöhet ha meg akarjuk tudni mennyire van világos, vagy egy potmétert mennyire állított a felhasználó. A 0 azt jelzi, hogy a bement ugyanazon a feszültségszinten van, mint a "föld", vagyis a táp negatív lába, az 1023 pedig hogy azon a szinten van, mint ami a processzor működési feszültsége (pl. 5 V). Figyelem, itt a processzor üzemi feszültsége jelenti a legmagasabb érzékelhető értéket, nem pedig a board bemeneti feszültsége! Ha magasabb szintet kap, könnyen kijöhet a processzorból a füst, ami hajtja...
- Digital IO / PWM: a digitális ki/bemenetek száma, illetve, hogy ezek közül mennyit lehet PWM módban használni. A mondat eleje talán érthető, ennyi lábról tudja a processzor megmondani, hogy a táp magas sarkához, vagy az alacsonyhoz van közel, azaz 1 vagy 0, illetve ha kimenetként akarjuk használni őket, akkor ezt mi is beállíthatjuk kódból, menet közben dinamikusan. Na a PWM már kicsit bonyolultabb, itt arról van szó, hogy impulzusszélseeég-modulációra képes lábakból hány van. Ezt elég bonyolult elmagyarázni, elvileg tudom mi ez, de használnom még nem kellett. Tipikusan motorok szabályozásához és ledek fényerejének fokozatmentes állításához szoktuk az Arduino világában használni ezt a funkciót.
- EEPROM (kB): ez az elektronikusan törölhető (és emiatt újraírható) ROM mérete. Ehhez talán egy PC merevlemeze áll a leg közelebb, ide tudunk úgy adatot elmenteni, hogy az kikapcsolás után is megmaradjon. Ezeknek az olvasás és még inkább az írása lassú művelet szokott lenni, valamit van egy természetes elhasználódása ennek a memóriatípusnak. No nem kell attól tartani, hogy néhány írás után kuka lenne az egész, de mondjuk az írások száma ezres nagyságrendben szokott mozogni, utána már várható hogy random hibák jönnek elő! Kedvenc típusaimnál ez jellemezően 1 kB (fontos a nagy B betű, ugyanis az ilyen alacsony szintű dolgokban nem ritka, hogy bitben mérnek nem pedig Byte-ban!)
- SRAM (kB): ez mutatja, hogy mennyi RAM-unk van menet közben. Hihetetlen kicsinek tűnik ma már 2 kB-nyi RAM, amikor egy átlagos mobilban is 4 GB van, vagyis 4.000.000 kB! Amire ezeket az eszközöket akarjuk használni, arra viszont általában elég szokott lenni ennyi is.
- Flash (kB): ez is hasonló az EEPROM-hoz, csak ide menet közben nem lehet írni! Ez arra van kitalálva, hogy a programunk lefordított kódja csücsül itt. Ez már 32 kB a nekem fontos gépeknél, ami jelentősen nagyobb szám, mint az EEPROM, vagy a RAM! Ez akkor jöhet jól, ha tudunk dolgokat forráskódba beégetni, ahelyett, hogy a RAM-ban próbálnánk menet közben azokat kikalkulálni és "észben tartani".
- USB: ez csak azt mutatja milyen USB csatlakozó van az adott lapon. ("Regular": Type-B, olyan mint ami az USB-s PC-s nyomtatókon szokott lenni, "mini": mini-B, régen a mobilokon is volt ilyen, ma már nem nagyon használja senki, "micro": micro-B, na ez van manapság szinte minden mobiltelefon aljába építve. További részletek itt: wikipedia) Talán feltűnhet, hogy van amelyiken semmilyen nincs, nos igen, van olyan lap, ahonnan ezt is lespórolták - de itt a spórolás nem a vevő kárára megy! Ha nekem nincs szükségem USB csatoló felületre, akkor tudok egy olcsóbb változatot választani, így magam is spórolhatok. Az USB itt arra van, hogy egy általános PC-s világból ismert soros portot kap az ember. Kezdőknek ez 2 okból is szinte kötelező: ezen keresztül lehet feltölteni a programot az eszközre és ez szolgál arra, amire egy Linux-on a terminal: ide lehet a kódból könnyedén információt kiírni és akár beolvasni is. Továbbá azt érdemes még megjegyezni hogy amikor USB-re van dugva az Ardu, akkor a tápot is onnan kapja!
- UART: ez maga a soros port hivatalos neve (Universal asynchronous receiver-transmitter). Ebben az oszlopban látható hogy az adott termékben hány ilyen soros port van alapból, hardveresen implementálva. Nekem 1-1 van minden lapkán, de elkeseredésre semmi ok, ezeket a funkciókat szoftveresen is el lehet érni, vagyis lehet az embernek több ilyenje is, vagy akár olyan board-okon is lehet csinálni, ahol alapból nincs.

A másik tervbe vett projekt a ház fűtésének vezérlése. Nem is kérdés, hogy mire ennek a kivitelezéséig eljutok, sok mindent kell végigszívnom. Ez egy meglehetősen tipikus projekt, sokan gondolkodnak ilyesmiben, ez kb az "okos otthonok Hello world-je". (Jó-jó talán a lámpakacsolgatás még ennél is alapvetőbb...)

Kezdjük a kiinduló állapottal, ami pár éve fogadott, amikor a házba költöztünk:
- földszint: padlófűtés és van minden helyiségben radiátor is, de ezt most hagyjuk
- emelet: itt van a kondenzációs kazán, mindenhol radiátorral
- mechanikus termosztát: földszint közepén.

Mint a legtöbb családi ház, a miénk is a tetőn keresztül eresztheti a legtöbb hőt, az pár apróságban tetten is érhető: például azon, hogy sokkal hamarabb kihűl az emelet - mondjuk gyorsabban fel is melegszik. Nyilvánvaló volt, hogy a két szintet nem érdemes egyszerre fűteni, ami a szerencsém volt, hogy a kazán alatt rögtön le volt ágaztatva az emeleti kör, így azt egy "zónaszelep" nevű fűtéstechnikai alkatrésszel könnyedén le lehetett választani. 

Első télen találtam is egy megoldást, amit úgy hívnak Computherm Q8:

Ezt egy fűtésszerelő segítségével (zónaszelep beszerelése miatt kellett) sikerült is üzembe állítani. Mivel a működésével nem voltam teljesen elégedett, azért elkezdtem gondolkodni egy jobb megoldáson. Kritériumok:
- stabil, megbízható megoldás kell: nem szeretnék hideg lakásban ülni és magyarázkodni a nejemnek, hogy miért nem megy a fűtés...
- biztonságos megoldás kell minden szempontból: nyilván nem szeretném, ha felrobbanna a fűtési rendszer, de azt sem, hogy egy kedves orosz/kínai hacker tinédzser vicceskedő hangulátban 40 fokot csináljon nálunk! Az IoT-nek nevezett szakterületen ez egy mostanában még eléggé hanyagolt téma, de talán egy teljesen egyedi megoldás biztonságosabb tud lenni, mint egy boltban vásárolható, népszerű cucc.
- távolról ellenőrizhető, vezérelhető kell legyen: nem hetente, de azért előfordul, hogy pár napra elutazik a család. Ilyenkor le szoktam venni a fűtést 18 fokra, viszont a fenti gyári termosztát-megoldás vagy pár órára, vagy pár (egész) napra képes tartani a program felülbírálását. Így vagy fél nappal hamarabb kezdi a rendszer felfűteni a lakást, vagy hideg lakásra ér haza a család és 2-3 óra kell hogy élhető legyen a klíma.
- legyen könnyen kezelhető: nem vagyok egy UX szakember, de ez a rendszer kézikönyv nélkül nehezen programozható át! Ha viszont nincs az ember néhány gombra és egy cél-kijelzőre kényszerítve, hanem mondjuk egy modern weboldal is rendelkezésre áll, na az már tényleg egy másik világ!
- az emeleti hőfokot a földszintről is lehessen ellenőrizni és könnyedén változtatni: a Computherm rendszerével fel kell menni az emeletre, hogy átállítsa az ember a hőfokot.

Igen, first world problem, de ha már belekezdek, akkor szolgálja ki az igényeimet amennyire lehetséges! Stay tuned..

Ez az Arduino-világ Hello World-je. Miről is van szó? Minden programozási nyelvben az első program, amit meg szoktak írni a kezdő fejlesztők az egy szög egyszerű példa, ami kiírja a képernyőre, hogy "Hello World!". Mivel az Arduino-nak nincs alapból képernyője, ezért itt a legelső program egy led villogtatását szokta szemléltetni.

A fenti kép azt mutatja hogyan is lehet bekötni egy ledet az Ardu egyik digitális kimenetére. Jól látható, hogy egy ellenállást illik a leddel sorba kötni, hogy tartósabb legyen a megoldás. Amit még érdemes megfigyelni a képen, az a próbapanel használata!

A próbapanel az a fehér lyukacsos dolog, ami nagyon hasznos tud lenni prototipizálásnál. A lyukak úgy vannak összekötve egymással, hogy alul és felül van 2-2 vízszintesen összekötött "sín", ahol a piros a tápfeszültséget szimbolizálja, a kék pedig a 0-t, vagy földet, vagy negatív pólust. Ez persze csak jelölés, mindenki azt dug oda, amit csak akar...
A kettő sínpár közötti lyukak függőlegesen vannak összekötve, de külön állnak a felső és külön az alsó ötösök. Ez azért praktikus, mert egy DIP tokozású integrált áramkört kényelmesen be lehet középre vízszintesen dugni, majd a lábaira könnyen tudunk más alkatrészeket csatlakoztatni a függőleges sínek segítségéve.

Szóval a ledet a kép készítője bedugta úgy, hogy a 2 láb külön-külön függőleges sínre csatlakozik, az egyik sínre rádugta a földet egy úgynevezett jumper kábellel, a másikra egy 220 Ohm-os ellenállást dugott, aminek a szabad végét bedugta a táp sínbe. Itt van egy kis trükk, mert a táp sín itt eleve az Ardu egyik digitális kimenete, de a lényeg talán átjön.

Így néz ki a led bekötés sematikusan. A 13-as számú digitális IO lábra kell a ledet kötni. A sematikus ábra specialitása, hogy az Ardu lábai nem feltétlen ugyanúgy helyezkednek el, ahogy a valósárban, illetve a táp bekötése sem látszik. Ennek az ábrának az áttekinthetőség a lényege, hogy könnyen össze tudja az egyszeri fejlesztő dugdosni a dolgokat.

Lássuk a kódot:

 Elemezzük kicsit a kódot! Ez egy C forráskód. 2 metódus van benne:
- setup: ez egyszer fut le, amikor elindul a gép, tápot kap, vagy valaki megnyomja a RESET gombot. Ide illik minden olyan dolgot berakni, amivel beállítjuk a környezetet.
- loop: ezt a metódust hívogatja a rendszer újra meg újra. Így kell gondolkodni: egy ciklus magja fut le újra meg újra. Itt kell mindenről gondoskodni, úgy mint bemenetek ellenőrzése, kimenetek állítgatása, kommunikáció lebonyolítása, stb.

pinMode: a digitális IO lábakat tudjuk beállítani ezzel, hogy kimenet, vagy bemenet a láb.
digitalWrite: nevéből sejthető is, írni tudunk rá, vagyis ha HIGH-ra állítjuk, akkor tápfeszültség lesz rajta, ha LOW-ra, akkor meg a nullához lesz nagyon közel.
delay: remélem nem kell sokáig magyarázni, várakozás fog történni ha ezt meghívjuk, méghozzá annyi milliszekundum, amennyit paraméterként adunk neki meg.

A delay-hez még jár némi magyarázat: illik kerülni a dolgot Ardu világában. Ennek az az oka, hogy amíg ott várakozik a processzor, addig szó szerint nem történik semmi! Viszont az idő nem áll meg és ami a világban közben történik, arról a proci lemarad! Ebben a primitív példában nyilván nem lehet olyan sok mindenről lemaradni, de egy bonyolultabb kódban előfordulhat, hogy közben a felhasználó megnyom egy gombot, mi meg észre sem vesszük, mert épp várakoztunk! Ennek a helyzetnek az elkerüléséről majd egy másik alkalommal fogok még mesélni.

Az Arduino-val való játéknak is akkor van értelme, ha az ember kitűz maga elé valami célt. Nekem is van pár olyan problémám, amit meg lehet oldani ezekkel az eszközökkel, az egyik ilyen a "Garázs-projekt".

Ezt nem azért hívom így, mert minden mókolás helyszíne a garázs, hanem mert ott konkrét feladatot találtam magamnak. Arról van ugyanis szó, hogy a garázsom kb 8 cm-rel hosszabb, mint a kocsim. Az autóban van tolatóradar elől-hátul, de ezek a rendkívül jó és megbízható szerkezetek általában 20cm-nél kisebb távolságok esetében már piros/felkiáltójeles/folyamatosan sípoló jelzéseket adnak, vagyis nekem nem elég pontosak.

Még évekkel ezelőtt rendeltem egy HC-SR04 típusú ultrahangos távolságmérő eszközt. Sosem használtam, azt se tudtam működik-e és ha igen, hogyan! Most, hogy megérkeztek az ardus dolgok, előkapartam ezt is, pár másik régi cuccal együtt.

Találtam egy egyszerű példát a használatára: link
Itt nem csak hogy kiírja hány centire is van a közeledő tárgy, de két ledet váltogat a távolság alapján: ha egy bizonyos távolságnál közelebb ér valami a szenzorhoz, akkor egyik, különben másik led ég. A kód meglepően egyszerű, a kapcsolás sem bonyolult, hát összedugdostam egy próbapanelon és meg is volt az első váó élmény!

Nyilván ez annyira könnyen ment, hogy szinte alkalmatlan is arra, hogy élesbe bevessem, hát némi továbbgondolás indult el...

Nemrég vágtam bele a dologba én is. Évekig óckodtam az Arduino-tól, valamiért a tudatomban a .Net-es világgal kapcsolódott össze az az Ardu. Mivel én nagyon szeretem az olcsó - akár gagyinak is nevezhető - cuccokat, ezért korábban is rendeltem már az Aliexpress-ről.

Amikor felnyitottam az Ali-t és beírtam a keresőbe, hogy "Arduino", több kellemes meglepetés is fogadott: 
- Egyrészt végtelen mennyiségű dolgot árulnak ott ami a témához tartozik, alaplapoktól kezdve perifériákig, építéshez szükséges dolgokig szó szerint szinte minden megvan itt.
- Másrészt azon döbbentem le, hogy mennyire olcsók ezek a cuccok! Uno 3 USD körül kezdődik, Nano 2 dodó!

Van persze ami itt nincs, de azt meg meg lehet lelni más oldalon, mint E-bay, Gearbest és társaik. Én többnyire Aliról szoktam rendelni, a következő kritériumok megadásával:
- 4-5 csillagos eladókat preferálom
- ha van, akkor ingyenes szállítást is a szűrők közé szoktam rakni
- rendezni pedig ár szerint szoktam.

Sajnos mire ezeket mindet beállítom, addigra adok is magamnak egy kis extra melót: a legolcsóbb tételek gyakran nem azok, amiket én keresek, hanem mondjuk (készülék) házak, kábelek, kiegészítők, stb. Szóval van, hogy az első pár, vagy akár pár-tíz oldalt is át kell ilyenkor lapozni, vagy a keresőkifejezést kell kicsit pontosítani. (Ami a szívás, hogy új keresőszónál újra kell állítgatni a szűrést és a rendezést is. Life sucks.)

Ami nekem eddig van:
- Uno
- Nano
- NodeMCU
- WeMos Mini D1 (még úton)
- Raspbery Pi (A, B+, 3) - de ezek nem tartoznak a tárgyhoz.

Nekem többnyire jó tapasztalatom van a Kínából rendelősdivel, évente 1x szívom be, de akkor sem nagy összegekről van szó. Ami megszokást igényel inkább a szállítási idő: Az átlag 25 nap szokott lenni, de a 60 is előfordul néha!

Rögtön kezdjem egy ego-bejegyzéssel. Nem mintha rólam szólna a blog, de kicsit megpróbálom kontextusba helyezne azokat az írásokat, amik ezután jönnek majd.

Középiskolában tanítottak nekem elektrotechnikát, sőt még érettségiztem is belőle! Ez persze nem azt jelenti, hogy profi lennék, de kicsivel talán több hátterem van mint annak, aki utoljára fizikaórán találkozott Ohm törvényével. 

Miután végeztem az értettségivel - némi szerencsével - programozó matematikusként végeztem el az egyetemet. Nagyon szeretem a szakmám, de néhány privát kalandtól eltekintve nem nagyon volt dolgom alacsony szintű - hardverhez nagyon közeli - feladatokhoz. Világ életemben fejlett programozási nyelvekkel dolgoztam: Delphi (sic!), Java és pár alkalommal script nyelvekkel is találkoztam, mint Python, Bash és barátaik.

Ezeket a dolgokat csak azért osztottam meg, mert a neten úgy látom két irányból érkeznek az Arduino bütyköléséhez az emberek:
- erős hardveres háttérrel: mérnök emberek, akik évek, esetleg évtizedek óta dolgoznak mindenféle olyan dologgal, mint TTL és társaik. Nekik általában a programozás része szokott kihívást jelenteni.
- szoftverfejlesztői háttérrel: mint Én. Annyi előnyöm azért van, hogy tudok pár alapvető dolgot a témában, nem ijedek meg egy DIP16-os tokozású alkatrésztől.
+1 lelkes érdeklődők, háttér nélkül: őket sem szeretném elriasztani, de sok fura kifejezés fog itt röpködni! Hogy mennyire lesz szórakoztató olvasmány a blogom azt majd mindenki maga dönti el.

Jó szórakozást kívánok mindenkinek!