Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai kar Méréstechnika és Információs Rendszerek Tanszéke
Holcsik Tamás
Növényházi adatgyűjtő- és vezérlőrendszer tervezése Diplomatervezés
KONZULENS EREDICS PÉTER BUDAPEST, 2013
2
Hallgatói nyilatkozat Alulírott Holcsik Tamás, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy autentikált felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé. Kelt: Budapest, 2013. 12. 09.
..................................................................... Holcsik Tamás
3
Összefoglaló Majd ezt még megfogalmazom mikor nagyjából kész
4
Abstract I will fill this page up, when it's almost done
5
Tartalomjegyzék 1. 2.
Bevezetés.............................................................................................................................. 6 Gyári megoldások................................................................................................................. 7 2.1 Wadsworth EnviroSTEP.............................................................................................. 7 2.2 Growtronix................................................................................................................... 7 2.3 Szenzorok .................................................................................................................... 8 2.4 Hőmérsékletmérő......................................................................................................... 9 2.5 Páratartalom érzékelő .................................................................................................. 9 2.6 Szélerősségmérés....................................................................................................... 10 3. A rendszer felépítésének terve............................................................................................ 10 3.1 A modulok közötti kommunikáció ............................................................................ 12 3.1.1 RS-485 .............................................................................................................. 12 3.1.2 CAN busz.......................................................................................................... 13 4. Hardver............................................................................................................................... 15 4.1 Mikrovezérlő-család kiválasztása.............................................................................. 15 4.1.1 Az STM32-es mikrovezérlő.............................................................................. 16 5. A modulok részletes bemutatása ........................................................................................ 18 5.1 Vezérlőmodul ............................................................................................................ 18 5.1.1 Tápegység ......................................................................................................... 19 5.1.2 Ethernet-illesztő ................................................................................................ 20 5.1.3 Kijelző illesztés................................................................................................. 21 5.1.4 SD kártya .......................................................................................................... 22 5.1.5 CAN busz illesztés............................................................................................ 22 5.2 Szenzormodul ............................................................................................................ 24 5.3 Kiegészítő modulok................................................................................................... 26 5.4 IO modul.................................................................................................................... 29 5.4.1 Kimeneti fokozat............................................................................................... 29 5.4.2 A modul tápegysége.......................................................................................... 31 5.5 Tápegység és akkutöltő.............................................................................................. 32 6. A nyomtatott áramköri lapok megtervezése....................................................................... 32 7. Modulok élesztése .............................................................................................................. 33 8. Szoftver .............................................................................................................................. 34 8.1 Fejlesztőkörnyezet ..................................................................................................... 34 8.2 Programozó hardver................................................................................................... 34 8.3 Operációs rendszer..................................................................................................... 35 8.3.1 Control_Task..................................................................................................... 36 8.3.2 Communicaton task .......................................................................................... 36 8.3.3 uIP_Task ........................................................................................................... 36 8.3.4 uIP_periodic_Task ............................................................................................ 36 8.4 Fájlkezelés ................................................................................................................. 36 8.5 Ethernet kezelés ......................................................................................................... 38 8.5.1 uip TCP/IP stack ............................................................................................... 38 8.5.2 Weboldal ........................................................................................................... 39 8.5.3 Webszerver funkciók ........................................................................................ 40 8.6 Grafikus kijelző ......................................................................................................... 40 8.7 Menürendszer javítani ............................................................................................... 42 8.8 CAN busz kezelés...................................................................................................... 44 9. Összefoglalás...................................................................................................................... 48 10. Irodalomjegyzék............................................................................................................. 49 11. Függelék......................................................................................................................... 50
6
1. Bevezetés A mai kor megköveteli, hogy a növényházakban termesztett növényeknek minél optimálisabb körülményeket teremtsünk a termés optimalizálására, a körülmények biztosításának egyik lehetősége a növényház automatizálása. A illetve megépítendő rendszer egy valós alkalmazási célra készül, egy jelenleg is működő (szobatermosztátokkal vezérelt) növényház ajtóinak nyitását és zárását fogja végezni a különböző szenzorok által mért adatok szerint. A megtervezése során elsősorban
a
megbízhatóságot
illetve
az
univerzalitást
tartottam
a
kiemelt
szempontokként. A növényház kifejezés takarja mind az üvegház, illetve mind a fóliasátor kivitelezést, a dokumentációban a könnyebb érthetőség érdekében általában üvegházként hivatkozok a növényházra.
7
2. Gyári megoldások Munkámat gyári megoldások áttekintésével kezdtem, hogy képet kapjak arról hogy milyen fizikai mennyiségeket szoktak mérni az eszközök, illetve a felépítésükről szerezzek információt.
2.1 Wadsworth EnviroSTEP Ez egy egyszerűbb és kisebb tudású üvegházvezérlő [1]. Önálló működésű, mikrokontroller vezérlésű, hálózatba nem köthető.
1. ábra
Főbb jellemzői: Csak analóg szenzorokat tud kezelni, illetve rendelkezik 4 digitális bemenettel egyéb kapcsolók érzékelésére. 12 relés, illetve 2 darab 0-10V-os analóg kimenettel rendelkezik, az adatokat 15 percenként képes menteni, és 7 napra visszamenőleg tárolja azokat. Bővíthetősége annyiban merül ki, hogy kapható hozzá szélsebességmérő modul, illetve egy olyan modul amelyen keresztül egy számítógéppel tud kommunikálni.
2.2 Growtronix Számítógép alapú rendszer [2], egyszerűbb vezérlések megvalósítására. A vezérlést maga a PC-n futó szoftver végzi, a számítógéphez RS232 porton csatlakozik, maga az eszköz tápegysége. A tápegység modulra lehet felfűzni az összes eszközt, szabványos CAT5 kábelekkel működik a rendszer, de nem ethernet alapon. Egyszerre maximum 29 eszközt kezel, lánc struktúrát megvalósítva.
8
2. ábra
2.3 Szenzorok Kutatásom során, illetve az eddig megismert rendszerek alapján az alábbi mennyiségek függvényében működnek a szabályzók -
hőmérsékletérzékelés (hűtés, fűtés, szellőztetés)
-
páratartalom mérés (szellőztetés)
-
talajnedvesség mérés (locsolás)
-
fényerősség mérés
-
CO2 szint mérés
-
talaj PH mérés
-
szélerősség mérés
-
automatikus tápanyag adagolás
Ezek közül a jelenlegi alkalmazás szempontjából első közelítésben a hőmérsékletmérést, páratartalommérést, illetve a szélerősségmérést tartom fontosnak megvalósítani, de meghagyom a lehetőséget későbbi bővítés során a többi beépítésére. A piacon kapható szenzorok egy része vagy komplett egységként kapható (pl.: termosztát), vagy valamilyen rendszerhez csatlakoztathatóan. Ezek lehetnek ipari szabványt használó (pl .: analóg, RS-485 ) komplett modulok, vagy önmagában álló integrált áramkör.
9
2.4 Hőmérsékletmérő Jelen alkalmazásban a legideálisabb valamilyen integrált áramkört beépíteni, és ezt majd a szenzormodul illeszti a rendszerhez. Abban az esetben viszont, ha például víz, vagy talaj hőmérsékletét kellene mérni, akkor célszerűbb valami gyárilag tokozott megoldást használni. Ezek a szenzorok általában hagyományos termisztorok, így a szenzormodult úgy kell kialakítani, hogy ezt tudja kezelni. Üvegházi alkalmazás céljára általában elegendő a 0,5 °C felbontás is, így a szenzor
kiválasztását leszűkítettem az ilyen pontosságú eszközökre. A levegő
hőmérsékletének mérésére megfelelő egy hagyományosan tokozott integrált áramkör. Általában minden nagyobb félvezetőgyárnak létezik saját hőmérsékletmérő integrált áramköre, többféle interfésszel, így érdemes rászánni az időt a megfelelő kiválasztására. Típus LM75 ADT7301 DS18B20 TMP100
Felbontás(°C) max 0,5 0,03125 0,0625 0,0625
Pontosság (°C) ±2 ±1 ±0,5 ±2
Interfész
Tokozás
Ár(Ft)
I2C SPI 1-Wire I2C
SO8 SOT23, MSOP8 TO92, uSOP8 SOT23
229 1066 1500 990
1. táblázat – A célra alkalmas hőmérsékletmérő IC-k (hu.farnell.com)
A
szóba
jöhető
integrált
áramkörök
az
1.
táblázatban
találhatóak.
Összehasonlításom alapja a maximális felbontásuk, pontosságuk, a kommunikációs protokoll típusa, tokozás és az áruk volt. A táblázat alapján látható hogy a legpontosabb IC-nek a DS18B20 IC kínálkozik, viszont ez a legdrágább. Ha egy kicsit lejjebb adunk a pontosságból, akkor a következő az ADT7301. Ennek az ára már alacsonyabb, és a pontossága is, de az alkalmazás szempontjából még megfelelő. A DS18B20 egyvezetékes kommunikációt használ, amivel könnyebb megoldani azt, hogy ne a NYÁK-on helyezkedjen el, hanem egy 1-2 méteres vezetéken, viszont a kommunikációs protokoll jóval bonyolultabb az SPI-t használó ADT7301 IC-nél. Megemlítendő, hogy a felbontásuk a kitűzött célt jóval felülteljesítik, de ilyen pontossági osztályban ilyeneket lehet találni. Ezek alapján a rendszerbe ADT7301-et fogok építeni, amikor nem követeli meg a helyzet hogy ne a NYÁK lapon helyezkedjen el az érzékelő.
2.5 Páratartalom érzékelő A páratartalom érzékelőből is létezik szintén ipari szabvány analóg kimenettel ellátott szenzor modul, illetve létezik csak félvezető alapú szenzor IC is. Ahogy fentebb említettem, jelen alkalmazásban a digitális kimenettel rendelkező szenzorokat
10 részesítem előnyben, a digitális környezetbe való könnyebb illeszthetőség érdekében. Mivel a pontosságuk függ a hőmérséklettől, ezért kompenzálásként általában tartalmazzák
a
hőmérsékletérzékelőt
is,
így
akár
meg
lehetne
spórolni
a
hőmérsékletszenzort a rendszerből, viszont ezek pontossága alacsonyabb a kifejezetten hőmérsékletmérésre gyártott IC-knél. Típus
Felbontás %
Pontosság %
Interfész
Ár
HIH6130-021-001
0,04
±4
I2C
3800
SHT11
0,05
±3
I2C
6900
SHT25
0,04
±1,8
I2C
7500
2. Táblázat – Páratartalom érzékelők
Páratartalom érzékelő IC-kből kisebb a kínálat, valamint az áruk is egy nagyságrenddel magasabb tartományban mozog. Pontosság szempontjából a legjobb a Sensirion gyártmányú SHT25-ös IC, és ennek a legmagasabb az ára is. Ilyen komoly pontossági követelmény viszont nem szükséges, így költségkímélés céljából a Honeywell gyártmányú szenzor lesz beépítve.
2.6 Szélerősségmérés Üvegházi alkalmazásnál fontos lehet hogy figyelje a külső időjárást, és megfelelően reagáljon rá. Ilyen esetre jó példa az, hogy vihar esetén a növények és maga az üvegház védelme esetén az ajtókat, szellőztetőket becsukja, hogy az erős szél ne tegyen bennük kárt. A
szélerősség
mérésére
legegyszerűbb
esetben
használhatunk
kanalas
szélerősségmérőket, amiből a kijövő sebességgel arányos impulzusokat kell feldolgozni. Pontosabb illetve gyorsabb mérésre képesek az ultrahangos szélsebességmérők, de jelenlegi alkalmazás nem követeli meg ilyen pontosságot.
3. A rendszer felépítésének terve Jelenleg a családi házunknál található a kertben egy fóliasátor, amelyben dísznövényeket termesztünk, így a növények számára ideális hőmérsékletet biztosítani kell, amelyet az ajtók nyitásával lehet megoldani. 3 ajtót különböztetek meg, a végeken lévő alsó illetve fölső ajtókat, illetve középen a tetőajtó. Ezek nyitása elektromos úton történik házilag épített lineáris egységek által. Ezek 24V egyenfeszültségről működnek, polaritásváltással lehet az ajtókat nyitni illetve zárni, a lenyitott illetve bezárt állapotot egyszerű végálláskapcsolók érzékelik, illetve szakítják meg az áramot. Mivel a jelenlegi
11 vezérlés hagyományos szobatemosztátokkal van megvalósítva, így fennáll az a probléma, hogy nem lehet tetszőleges nyitási is zárási hőmérséklet tartományokat beállítani, illetve különböző kényelmi funkciókat nem tud megvalósítani a rendszer.
3. ábra - A fóliasátor felépítésének rajza
Ezek alapján az elképzelt rendszer felépítése az alábbiak szerint alakulna: Maga az egész rendszert egyetlen vezérlőegység szolgálni ki. Ez felelne a szenzorok kiolvasásáért, és a beolvasott értékek alapján történne a működtetés. A vezérlő rendelkezne kijelzővel, így grafikus felhasználói felületet nyújtana a felhasználónak, a különféle beállításokért illetve az aktuális fontos paraméterek értékét nyomon követhetné.
4. ábra - A rendszer felépítésének terve
Szenzor modulok feladata a szenzorok buszra illesztése. Ezekre azért van szükség, mert az egyes szenzorok kommunikációs interfésze teljesen más lehet, illetve a nagyobb távolság miatt nem lehetne biztosítani a zavarmentes működést. Az IO modul szerepe lenne a fizikai beavatkozók kapcsolása, ez a busz topológia miatt tetszőlegesen helyen állhat, illetve több darabot is tartalmazhat ha az üvegház felépítése megköveteli.
12 A tápegység látja majd el az egyes szenzorokat illetve vezérlő egységet tápfeszültséggel. Az alkalmazandó 24V-os feszültség kellően magas ahhoz hogy a kábelen lévő veszteség miatt probléma legyen, illetve a 24V törpefeszültségnek minősül, így nincs érintésvédelmi probléma a használata során. Az egyes modulok között egy busz tart kapcsolatot. A típusának kiválasztása során figyelembe kell venni hogy nagyobb távolságot kell áthidalni hibamentesen, és az esetleges bővíthetőség lehetőségéről sem szabad megfeledkezni.
3.1 A modulok közötti kommunikáció A modulok egymással való kapcsolatát valamilyen nagy távolság áthidalására képes vezetékes összeköttetésnek kell biztosítania. Nagyobb távolságra csakis differenciálisan vitt jelekkel lehet biztosítani a hibamentes nagyobb sebességű kommunikációt, ezért ilyen elven működő buszok közül választottam ki két jellemző típust, amelyet összehasonlítottam
3.1.1 RS-485 Az RS-485 manapság [3] az ipari irányítástechnikában széleskörűen elterjedt kommunikációs busz típus. A szabványt az EIA/TIA vezette be. A TIA/EIA-485 szabvány csak a busz fizikai felépítését, meghajtó áramkörök felépítését definiálja, miközben a buszon megvalósított kommunikációs protokollt nem. A hálózatot csavart érpárral lehet kialakítani, és ajánlott csakis lánc alakzatban felépíteni, a reflexiók kiküszöbölése érdekében. A busz végein található 1-1 darab a vezeték hullámimpedanciájával megegyező lezáró ellenállás.
5. ábra - RS485 busz felépítése
13 Az RS-485 ös hálózat szabvány szerint maximum 32 eszközből állhat maximum egy buszon,
illetve hátránykán említhető meg az is, hogy semmilyen hardveres
támogatás nincs a buszon való kommunikáció lebonyolítására. A busz egyik végén található meg az az ellenállásosztó, amellyel a busz közösmódusú előfeszítését valósítja meg. Ez azért szükséges hogy a feszültségszintek a vevők komparálási szintjéhez megfelelően illeszkedjenek.
3.1.2 CAN busz A CAN buszt [5] a Bosch cég fejlesztette ki, és a nyolcvanas évek végére lett belőle ipari szabvány. Eredetileg autóipari alkalmazások céljára készült, mivel ilyenkor kezdtek megszaporodni az autókba épített különböző elektronikus segédberendezések (ECU, ABS...) és a köztük lévő gyors kommunikációt biztosítani kellett. Fizikai felépítését az ISO11898–as szabvány ismerteti. A buszt felépítését tekintve egy csavart vezetékpár alkotja, amelyet differenciálisan hajtanak meg az eszközök. A csavart érpár biztosítja a külső elektromágneses elleni zavarvédelmet, a differenciális jelvezetés pedig a közösmódú zavarok elleni védelmet biztosítja.
6. ábra - CAN busz felépítése
A busz a végeken találhatóak a lezáró ellenállások, amelyek biztosítják, hogy ne legyenek reflexiók a vezetéken. A szabvány szerint a buszokra csatlakozó eszközöket node-oknak nevezik, a buszra láncszerűen csatlakoznak közvetlenül, hozzávezetések nélkül. (hosszú hozzávezető kábelek reflexiókat okoznának). A CAN busz multimasteres, a busz arbitrálás hardveres úton van megoldva, minden CAN üzenet elején. Későbbi fejlesztés során így lehetőség van arra, hogy akár több vezérlőegység legyen egy buszon (pl ha több fóliasátron keresztül van vezetve a busz, és néhány szenzormodul, illetve IO modul közös). Alapkiépítésben ez nincs
14 kihasználva, mert a vezérlő egyszerre csak egy modullal kommunikál, és a kérés után vár a válaszra. Az összeköttetés maximális hosszát elsősorban az átviteli sebesség határozza meg, a korlátozás oka a kábelen történő jelterjedés véges sebessége. 1Mbit sebességgel kb. 40m az áthidalható sebesség, de a sebesség drasztikus csökkentésével több mint 1000 métert át lehet vele hidalni.
Egy CAN adatcsomag felépítése az [] ábrán látható (forrás). A csomag eleján található meg a csomag azonosítója, amely segítségével az arbitrálás végrehajtódik. Minél kisebb a cím annál nagyobb a prioritása, mivel a buszon a 0 szint dominál. A cím küldésekor a küldő node figyeli hogy a kiadott jelszintnek megfelelő adatbit található-e a buszon, abban az esetben ha ez nem stimmel, akkor csomag ütközés jönne létre, emiatt felfügeszti a csomag küldését, és vár addig amíg fel nem szabadul a busz. Az aznosító után követeznek a vezérlőbitek, illetve a csomag hosszát jelölő DLC byte. A DLC jelenti hogy az utána következő adatbitek közül mennyi jelenti az adatmezőt. Az adatmező után következik a 15 bites ellenőrző összeg, amely segítségével el lehet dönteni a csomagról hogy keletkezett-e valamilyen sérülése a csomagnak. A fentiek alapján arra a következtetésre jutottam, hogy az én célomra a CAN busz lesz a legideálisabb. Fő előnyei a hardveres kommunikációs támogatás, és a nagy átvihető távolság, továbbá mivel manapság ez egyre jobban elterjedő szabvány, ezért a hasznos ismeretekre tudok szert tenni a fejlesztés folyamán A busz fizikai megvalósítása hagyományos CAT5 UTP kábellal fog történni, ennek a hullámimpedanciája megfelelő a CAN busz számára is. Mivel a kábel 8 eres, a fennálló szabad vezetékeken át lehet vinni a modulok számára a 24V-os tápfeszültség. .
15
4. Hardver 4.1 Mikrovezérlő-család kiválasztása A megfelelő mikrovezérlő kiválasztása egy nagyon fontos lépés a rendszer szempontjából, a kapcsolástechnikát meghatározza a mikrovezérlő családja, illetve előre kell gondolkozni, hogy később a szoftverfejlesztést milyen eszközökkel lehet megoldani. Az első fontos döntési kérdés az volt, hogy 8 bites vagy 32 bites mikrovezérlő kerüljön beépítésre. A 8 bites mikrovezérlők jellemzően maximum 20MHz-es sebességgel működnek, amely itt a szenzor modulnál bőven elegendő lett volna, viszont, általában CAN interfészt nem tartalmaznak, vagy amelyekben megtalálható, azok jellemzően olyan áron beszerezhetőek, mint egy 32 bites mikrovezérlő. Továbbiakban a jövőre gondolva célszerű, ha ugyanaz a fejlesztőkörnyezet van használva és ugyanazt a szoftveres library-t használja a rendszerbe épített összes mikrovezérlő, abban az esetben, ha a később debuggolni kell. A vezérlőmodulba egy LCD kijelző kerül beépítésre, ezért célszerű olyan típust használni, amely tartalmaz valamennyi hardveres gyorsítást, hogy lehetőleg minél gyorsabban lehessen frissíteni a kijelző tartalmát, ezzel a felhasználói élményt nem rontja el, és készülék egy gyorsan működő rendszer benyomását kelti. Az alkalmazott kijelzővel párhuzamos 16 bites buszon lehet kommunikálni, tehát olyan vezérlő kell amely erre képes. A 32 bites mikrovezérlők közül egyre jobban elterjednek a Cortex-M mag alapú mikrovezérlők, ebből jelenleg a legkönnyebben talán a Cortex-M3 mikrovezérlőkkel lehet megbarátkozni, mert sok dokumentáció fellelhető hozzá. Fejlesztőkörnyezetből létezik hozzá open source alapú, programozó illetve debugger eszközből is hasonló a helyzet. A jelenleg beszerezhető családok közül az NXP, ST, illetve az ATMEL gyártmányúak jöhettek szóba, de ebből kiestek számomra az NXP gyártmányúak mert azokon nincs párhuzamos kimenet, emiatt a kijelző frissítési sebessége nagyon lassú lenne. Végül az ST gyártmányú mikrovezérlők mellett döntöttem, mert ez rendelkezik a fentebb a kijelző meghajtásához alkalmas memória interfésszel [1].
16
4.1.1 Az STM32-es mikrovezérlő Az áramkörökbe az ST Microelectronics által gyártott STM32-es 32bites családba tartozó mikrokontrollereket építettem be. Közös jellemzőjük, hogy mindegyikben az ARM által kifejlesztett Cortex-M3 maggal rendelkeznek. Ez a mag egy viszonylag új fejlesztés, elsősorban a 8bites mikrovezérlők konkurenciájaként lett kifejlesztve. Alacsony tápfeszültségűek és áramfelvételűek, de komolyabb számítási teljesítménnyel rendelkeznek a 8bites változatokhoz képest. Órajelüket tekintve 100MHz felett változatuk is létezik, az ár és teljesítmény arányuk sokkal kedvezőbbek a 8bites változatokhoz képest.
A mikrovezérlő belső felépítése a XXXX ábrán látható. Megfigyelhető hogy nagyobb sebességű eszközök egy busz mátrixon keresztül kapcsolódnak egymáshoz és az AHB buszhoz. Ennek a busz mátrixnak az a lényege hogy közvetlen tudnak egymással kommunikálni a magasabb sebességű eszközök, és nem az AHB buszt
17 használják. Így meg lehet valósítani azt, hogy míg a DMA periféria adatokat másol valamilyen periféria felől a belső SRAM-ba, addig CPU a Flash memóriából hozhatja fel a következő utasításokat. Az alacsonyabb sebességű perifériák az APB1 és APB2 buszokon találhatóak meg, közötti található az AHB-APB híd, amely automatikusan működve továbbítja a eszközök között az adatokat, és oldja meg a busz arbitrálást. A legtöbb perifériához lehet DMA-t rendelni, így sokat lehet gyorsítani, illetve automatizálni a megoldandó feladatot főleg hogy képes periféria-periféria közötti adatátvitelre is. Például megoldható egy AD konvertálás eredményét felhasználva közvetlenül kitöltési tényezőt állítani egy Timer PWM modulján. Az egyes perifériák energiatakarékos módját úgy biztosítják a mikrovezérlőben, hogy a meghajtó órajelüket le lehet tiltani. Ilyenkor a beépített CMOS tranzisztorokra jellemzően megszűnik a dinamikus áramfogyasztás, és csak a nagyon alacsony statikus áramfogyasztás
marad meg. Mivel alaphelyzetben minden periféria kikapcsolt
állapotban van, inicializálásuk előtt be kell kapcsolni a hozzájuk tartozó órajelvezetéket az órajelmodulban. Az órajel ellátást az alábbi ábra szemlélteti
18 A mikrovezérlőben alapvetően 4 db oszcillátor található. Egy 40kHz-es LSI, amely csak a watchdog illetve a belső Real time clock-ot tudja meghajtani. A real-time clock meghajtására megtalálható az LSE oszcillátor amely az elterjedt pontos külső 32.768 kHz-es kvarc kristály meghajtására használható. Maga a processzor járhat a belső 8MHz-es (HSI) oszcillátorról, vagy külső 4-16MHz-es kvarc kristályról (HSE). Ezekhez az oszcillátorokhoz lehet rendelni PLL-t is, amellyel a külső kvarc frekvenciáját fel lehet szorozni. A felhasznált STM32F103C6T6 illetve STM32F104VC mikrovezérlők maximum 72MHz-en működtethetők, de a szenzormodulokban csak 12MHz-en járnak, a központi vezérlőpanelba épített pedig 48MHz-en. A PLL által felszorozott órajel hajtja a processzor magot, illetve az AHB buszra tartozó perifériákat. Az APB perifériákra kerülő órajelet akár osztani is lehet, ha szükséges, de az APB1 perifériánál maximum 36MHz-en működhetnek az eszközök.
5. A modulok részletes bemutatása Mivel a modulok kapcsolási rajza A4-es méretű, ezért ezek a jelen beszámoló függelékében találhatóak meg, itt alább csak a modulokra jellemző lényeges kapcsolási részleteket emelem ki és mutatom be. Az egyes modulok kapcsolása között bizonyos áramköri részletek megegyeznek, ezáltal gyorsabb volt a fejlesztés, és kevesebb fajta alkatrészt kellett beépíteni.
5.1 Vezérlőmodul A vezérlőmodul szolgál a szenzormoduloktól való adat lekérdezésére, illetve ezek alapján az IO modul(ok) vezérlésére. Követelményként tartalmaznia kell ethernet interfészt hogy távolról menedzselhető lehessen, rendelkezzen megfelelő méretű LCD kijelzővel, illetve megfelelő memóriával, hogy lehessen tárolni mérési eredményeket.
19
7. ábra - Vezérlőmodul blokkvázlata
5.1.1 Tápegység A tápegységnek kell előállítania a mikrovezérlő, illetve a különféle egyéb perifériák 3.3 V-os tápfeszültségét az egész rendszer 24V-os feszültségéből. Ismerve azt, hogy a kijelző háttérvilágítása illetve az ethernet vezérlő fogyasztja a legtöbbet összesen (kb. 300mA) ezért csakis valamilyen kapcsolóüzemű feszültségszabályzó jöhet szóba, hogy kicsi legyen a veszteség. Erre a célra a Microchip MCP16301-es, viszonylag új integrált áramkörét [5] használtam fel. A dokumentációja szerint képes akár 96%-os hatásfokkal működni, kis méretű SOT23-6 tokozással rendelkezik, magas a kapcsolási frekvenciája, emiatt kis méretű és értékű induktivitást lehet beépíteni. 600mA áram leadására képes, tehát így az áramkör céljait teljes mértékben kielégíti.
8. ábra - 3.3V-os tápegység
A tápegység sorkapcsokon kapja meg a 24V-os tápfeszültséget, védelemként található rajta egy SMJ33A típusú 33V-os túlfeszültség-levezető, az IC védelme céljából. Az IC hagyományos step-down elven működik, a kimenőfeszültséget az R7 és R8-ból felépített feszültségosztóval lehet beállítani a kívánt tápfeszültségre, amely itt a
20 jelen esetben 3.3V. Érdekességképpen a kapcsoláson szereplő D2 és C6 által alkotott kapcsolás szolgáltatja a beépített N-csatornás kapcsolótranzisztor számára a Gate feszültséget.
5.1.2 Ethernet-illesztő A specifikáció szerint az áramkörnek rendelkeznie kell ethernet interfésszel, a távoli számítógépes kapcsolat biztosítására. A mikrovezérlő kiválasztásánál az egyik nagy dilemma a beépített ethernet vezérlő, vagy a kijelzőhöz való memória interfész, mivel ebben a családban nem volt olyan típus, amelyik mindegyiket támogatta volna. Végül az a típus lett felhasználva, amelyikben nincs ethernet interfész, így ezt egy külső megoldással kellett megvalósítani. Ennek összesen annyi hátránya van, hogy valamennyivel lassabb mintha beépített vezérlő lenne, de mivel a jelenlegi felhasználás nem kritikus sebességre, és árban körülbelül ugyanannyiba kerül az ethernet vezérlő, mint maga az ARM-hoz való fizikai interfész IC. Választásom a Microchip ENC28J60as típusára esett [7]. Ezt elterjedten használják beágyazott rendszerekben, így kellő támogatás is rendelkezésre fog állni a szoftverfejlesztés során.
9. ábra - Ethernet illesztő
Az ethernet vezérlő SPI buszon kommunikál a mikrovezérlővel, ugyanarra a buszra van kötve mint az SD kártya, továbbá rendelkezik egy interrupt kimenettel a mikrovezérlő felé, amelyet elsősorban a beérkező ethernet csomag jelzésére használ.
21 Az IC-hez szükséges még csatlakoztatni az ethernet kábel meghajtásához szükséges illesztő transzformátort, ebből létezik RJ45-ös csatlakozóba épített változat, így ilyen lett beépítve, helytakarékossági célból.
5.1.3 Kijelző illesztés A kijelzőben található egy SSD1289-es vezérlő IC, aminek köszönhetően a kijelző saját memóriával rendelkezik, elegendő csak akkor képet feltölteni a kijelzőre, amikor valami változás történt, nem kell egyfolytában frissíteni. A kijelzővezérlő párhuzamos 16 bites buszon kommunikál a mikrovezérlővel. A mikrovezérlő rendelkezik párhuzamos kimenettel is, ezért akár közvetlenül is meg lehetne oldani a vezérlést, de ennél sokkal kifinomultabb, ha a beépíett FSMC1 modulon [9] keresztül kommunikálunk
a kijelzővel.
Ennek
köszönhetően
a kijelző
egy bizonyos
memóriacímen lesz elérhető, így DMA műveletekkel gyorsan és automatikusan lehet frissíteni a képernyő tartalmát. A
vezérlőmodul
kezelését
alapértelmezetten
a
kijelzőbe
beépített
érintőképernyővel lehet végezni. Lényegét tekintve két elektromosan vezető műanyag rétegből áll, amelyek alaphelyzetben egymástó elszigetelve vannak egymástól. Érintés esetén ezek egy ponton érintkeznek, így egy-egy ellenállásosztó alakul ki.
10. ábra
Ha erre a két-két ellenállásosztóra feszültséget kapcsolunk, és a másikból olvasunk, majd megfordítva ugyanezt végigcsináljuk, akkor megkapunk két feszültséget, amelyek az X és az Y koordinátával arányos. Ezt a műveletet a mikrovezérlő GPIO kimeneteivel, illetve AD konverterével meg lehet oldani, de maga a kijelzőmodul a jelen esetben tartalmaz egy ADS7843 típusú érintőkijelző vezérlő IC-t. Ez önmagában 1
Flexible Static Memory Controller
22 elvégzi a mérést, így csak az ADC értékeket kell kiolvasni. Rendelkezik egy TP_IRQ kimenettel, amely abban az esetben aktív, ha éppen meg van érintve a kijelző, ezt így megszakítással le lehet kezelni, és a megfelelő koordinátákat ismerve műveleteket lehet végezni a grafikus felületen
5.1.4 SD kártya Mérési adatok tárolására, illetve a kijelzőn és a weblapon használandó grafikák tárolására szükség van valamilyen nagyobb kapacitású memóriára. Ez lehet valamilyen Flash alapú memória IC, vagy lehet használni SD kártyát. Manapság az SD kártyák ára nagyon alacsony, illetve könnyű őket kezelni, valamint cserélhető, ezért ezt terveztem bele.
11. ábra - SD kárya illesztése
Az SD kártyákat lehet az egyszerű SPI interfészen keresztül kezelni, illetve létezik egy gyorsabb, 4bites párhuzamos kommunikációs módja is, de annak nincsen hozzáférhető dokumentációja, így a jelenlegi alkalmazásban SPI módos kezelés szerint van bekötve. A mikrovezérlőhöz a MISO, MOSI, SCK jeleken csatlakozik, illetve még az M_CS kiválasztó jellel. Ezen a buszon található meg az ethernet vezérlő is így ezen osztozkodva egyszerre csak az egyik eszközzel lehet kommunikálni.
5.1.5 CAN busz illesztés A CAN buszhoz való vezérlőt beépítve tartalmazza a mikrovezérlő, így csak a buszmeghajtót, a fizikai réteget kell hozzátervezni. Ilyen meghajtó, a Texas Instrument SN65HVD230-as integrált áramköre [8], amely biztosítja a megfelelő teljesítményt a busz meghajtásához, illetve a sebessége is elegendő jelen alkalmazáshoz.
23
12. ábra - CAN busz meghajtó
Az IC mikrovezérlővel a TXD és az RXD lábon csatlakozik. Küldés során, ha a TXD alacsony szinten van, akkor a kimeneten a CANH és CANL vezeték domináns2 állapotban van, magas TXD szint esetén recesszív állapotban. Az RXD láb ehhez megfelelően, akkor van magas szinten, ha recesszív szint van a CAN buszon. Az IC képes 3.3V-os tápfeszültségről működni, kialakítását és feszültségszintjeinek határát tekintve az 5V-os tápfeszültségről működő CAN buszokkal is kompatibilis. Bár a meghajtó IC a dokumentáció szerint rendelkezik busz felőli túlfeszültségvédelemmel, a biztonság kedvéért beépítésre került egy NXP gyártmányú PESD1CAN típusú, kifejezetten CAN buszra kifejlesztett túlfeszültség levezető dióda. A
kapcsoláson
található
R11
és
R12
ellenállás
valósítja
meg
a
hullámimpedanciás lezárását a kábel felé. Az értéküket a kábel hullámimpedanciája határozza meg, de célszerű a végleges beszerelés után ellenőrizni a jelalakokat a buszon, szükség esetén korrigálni rajta. Nem minden modulba kell beépíteni a lezáró ellenállásokat, csak a busz két végén lévő eszközbe.
2
Domináns állapot: a CANH láb magas szinten van, a CANL lába alacsonyan, a recesszív állapot esetén magas impedanciás állapotban vannak a kimenetek. Ilyenkor a buszon a CANH és CANL lábak ugyanazon a feszültégen vannak, jellemzően VDD/2
24
13. ábra - Vezérlőmodul, kijelző nélkül
A modul egy 104x65mm méretű NYHL lemezre fért rá. A méretét elsősorban a beépített kijelző modul méretei határozták meg. A kijelző távtartókkal van rögzítve a vezérlőmodulhoz, és hosszú tüskesorral csatlakozik az alatta lévő áramkörhöz. A távtartó hossza akkora hogy a kijelző alá beférjen az Ethernet csatlakozó. A modul a tápfeszültséget és a CAN buszhoz való csatlakozását sorkapcsok biztosítják.
5.2 Szenzormodul A szenzormodulok kisméretű áramkörök, feladatuk jellemzően a különböző interfésszel rendelkező szenzorok illesztése a CAN buszra, így egységes felületet biztosítva a vezérlőmodul számára, ezáltal a vezérlőmodulnak sokkal egyszerűbb lekérdezni a szenzorok által mért adatokat.
25
14. ábra - A szenzormodul blokkvázlata
A szenzormodulba egy STM32F103C6 típusú mikrovezérlő van beépítve, ez rendelkezik 32kbyte FLASH memóriával 8kbyte RAM-mal, CAN, SPI, I2C interfésszel, illetve AD konverterrel, így a célnak tökéletesen megfelel, könnyen beszerezhető és olcsó mikrovezérlő. A modult tápfeszültséggel a fentebb megismert MCP16301-el felépített tápegység látja el. Ide szintén szükséges volt a kapcsolóüzemű tápegység, a hatásfok biztosítása és a hőtermelés minimalizálása miatt. A szenzormodul szintén az SN65HVD230-as CAN illesztővel tart kapcsolatot a busszal, és itt is megtalálható a túlfeszültség védelem.
15. ábra
A modul csatlakozó kiosztása a 9. ábrán látható, rendelkezik I2C és SPI lábakkal, illetve mindegyik láb használható analóg bemenetnek, így csak a szükséges kisméretű NYÁK lemezt kell elkészíteni és hozzácsatlakoztatni. A szenzormodul a szenzoroktól való adatgyűjtésen kívül másra is alkalmas. Ilyen alkalmazás lehet például LED-ek
26 meghajtása, vagy nyomógombok olvasása, illetve egyszerűbb kijelző vezérlése is. A jelenlegi fóliasátorban is mutatnia kell majd aktuális hőmérsékletet, ellenőrzés céljából.
16. ábra - Szenzormodul
A modul méretei 42x30 mm. A tápfeszültség és busz csatlakozása ugyanúgy van megvalósítva mint a vezérlőmodulnál. A szenzorokhoz való csatlakozás egy 90°-os tüskesorral van megoldva, így a kiegészítő panelt majd egyszerűen csak rá kell dugni.
5.3 Kiegészítő modulok A szenzormodulok szoftvereinek fejlesztése során első szempontból a kommunikáció elindítása volt a fő cél, a további fejlesztés során szükség volt az egyes kiegészítő áramkörök elkészítésére.
17. ábra - Kiegészítő szenzorpanelok
Az előbbiek alapján a szenzormodulok önmagukban csak a kommunikációt biztosítják, az egyes érzékelőket egy külön panelon kell csatlakoztatni hozzájuk. Tesztelési célokra készült LM75-ös hőmérő IC-vel is modul, de az alkatrészenkénti szórással nem voltam elégedett, így végül a Honeywell gyártmányú HIH6131-es kombinált hőmérséklet és páratartalom mérő került beépítésre. A hozzá tartozó áramkör egyszerű, a
27 szenzormodultól a tüksesoron keresztül kap tápfeszültséget illetve ezen a csatlakozón keresztül csatlakozik az I2C buszra.
18. ábra - A szenzormodulhoz csatlakoztatva
További kiegészítő a távirányító modulnak nevezett áramkör, amely a szenzormodulhoz csatlakozik. Ennek a feladata a rajta lévő energiatakarékos LCD-vel a növényházban a hőmérséklet mutatása, továbbá a kezelőgombok segítségével az ajtók állásának a manipulálása. A segítségével lehet üzemközben az ajtókat kinyitni vagy becsukni karbantartás stb. céljából. úgy hogy ne kelljen a vezérlőmodulon állítgatni.
19. ábra - Távirányító panel
Az utolsó modul a szélerősségmérőhöz tartozó illesztőmodul. A szélerősséget egy egyszerű kínai forrásból származó kézi szélsebességmérő átalakításával készítettem.
28
A működési elve azon alapszik, hogy található benne egy ventillátor szerű propeller, amelynek a forgó részén elhelyeztek egy apró mágnest, és a készülékházban pedig egy érzékelő tekercset. Ebből az eszközből csak a műanyag ház van felhasználva, és külső elektronika végzi a feldolgozást. Forgás során feszültség indukálódik a tekercsben, és ennek a frekvenciáját méri az eszköz.
Ugyanezt az elvet felhasználva, egy kis áramfelvételű rail-to-rail műveleti erősítővel a tekercsen keletkező feszültséget felerősítem kb 100x erősítéssel, majd a műveleti erősítő kimenetét kapacitív csatolással egy schmitt trigger inverter bemenetére kötöm, amelynek a bemenetét fél tápfeszültségre húztam ellenállás osztóval, ennek eredményeképp négyszögesíti a műveleti erősítő jelét. Ezt felhasználva a szenzormodul
29 csatlakozóján a mikrovezérlő megkapja interrupt jelként, amelyet frekvencia méréssel vissza tudja alakítani szélsebesség értékké.
5.4 IO modul Az IO modul szerepe a rendszerben a különféle végrehajtóegységek vezérlése, illetve néhány általános IO kimenetet biztosítani a külvilág irányába. Így későbbi fejlesztések esetén fel lehessen ezeket használni, mielőtt új modult kellene tervezni. A modulból egy rendszerben több is megtalálható, abban az esetben, ha a növényház felépítése megköveteli.
20. ábra - Az IO modul blokkvázlata
Felépítését tekintve a mikrovezérlő ugyanaz, mint a szenzormodulban, mivel itt sincs túl nagy követelmény a beépített perifériákkal szemben, itt is tartalmaznia kell a CAN modult, illetve mivel szükséges mérnie a 24V-os tápfeszültséget, ezért tartalmaznia kell egy AD konverterrel is rendelkeznie kell.
5.4.1 Kimeneti fokozat A fóliasátor ajtóit 24V-os DC motorral rendelkező lineáris egységek mozgatják. A mozgás irányát a motorokra adott feszültség polaritásával lehet megváltoztatni, a lineáris
egység
mozgási
tartományait
végállás-kapcsolók
megszakítják a motor áramellátását végálláshoz érés esetén.
érzékelik,
amelyek
30
21. ábra
Az irányváltást a jelenlegi felépítésben nagyáramú relék végzik, mivel ezek az eddigi évek során bizonyították alkalmasságukat, ezért ezek továbbra is beépítve maradnak. Az áramkörnek ezeknek a meghajtását kell megoldania. A relék az autóelektronikában használatos szabványos váltó relék, 12V-os meghúzó tekerccsel rendelkeznek, és maximum 200mA-t vesznek fel, és 30A-t képesek kapcsolni.
22. ábra - Kimeneti fokozat
Mivel biztosítani kell azt, hogy a jelenlegi felépítéssel kompatibilis legyen az új áramkör, ezért a reléket „felülről” kell meghajtani, tehát +12V-ot kell szolgáltatni a kimeneten a relék kapcsolásához. Ezt áramköri szempontból P csatornás FET-ekkel lehet a legkönnyebben megvalósítani. A kapcsolás szerint a mikrovezérlő az SW vezetéken keresztül hajtja az N csatornás FET-et, aminek hatására, ha H szintet kap, akkor a P csatornás FET Gate-jét lehúzza a földre, így az vezetni kezd és megjelenik a kimeneten a 12V. Az alkalmazott FET IRFR5505 típusú, amely képes leadni 18A-t így a feladat szempontjából többszörösen túl van biztosítva, de cserébe olcsón beszerezhető típus. A kimenet üvegcsöves biztosítóval túláram ellen védve van, illetve a kimeneten még található egy védődióda, amely a relé kikapcsolásakor keletkező feszültséglökés ellen véd a megfelelő polaritással.
31
5.4.2 A modul tápegysége Mivel az egész rendszer 24V feszültségről működik és a relék 12V működtető feszültségűek, biztosítani kell működtető feszültséget a megfelelő terhelhetőséggel, ezért kapcsolóüzemű tápegységet építettem az áramkörbe. A tápegység egy LM2576-12 típusú IC-vel van felépítve, ez akár 3A-rel is terhelhető, ha a megfelelő terhelhetőségű induktivitás van mellé építve. A jelenlegi alkalmazásban maximum 1A-es terhelés alatt kell teljesítenie, ezért ide tökéletesen megfelel.
23. ábra - 12V-os tápegység
A 3.3V-os tápfeszültség egy egyszerű lineáris feszültség stabilizátorral van előállítva abból az okból kifolyólag, hogy a mikrovezérlőn kívül csak a CAN transceiver található a 3.3V-os ágon. Az összes fogyasztás az adatlapok alapján kb. 15mA környékén alakul, így bőven elegendő hőtermelés és áramfelvétel szempontjából egy 100mA-es stabilizátor, a választásom az egyszerű 78L33-ra eset
24. ábra
Befoglaló méretei 68x80mm, a modul szélén találhatóak meg a sorkapcsos csatlakozókon tápfeszültség bemenetek, illetve a vezérelt kimenetek, a tüskesorok közül
32 az egyik a működtető program feltöltésére szolgáló JTAG csatlakozó, illetve a bővítő csatlakozó. A tápfeszültség és a kimenetek az elterjedten használt 5x20mm-es biztosítókkal van védve. Az áramkör sarkain furathelyek találhatóak a későbbi dobozolás
5.5 Tápegység és akkutöltő A tápegység modul célja az egész rendszer tápfeszültségének előállítása. Biztosítania kell a központi vezérlő, a szenzorok, továbbá az IO modul tápfeszültségét. Biztonsági szempontok szerint hálózati feszültség megszűnése esetére is szolgáltatnia kell a tápfeszültséget az ajtók bezárására (például egy komolyabb vihar esetére, amikor áramszünet lép fel), így a szükséges hogy akkumulátorok legyenek beépítve a rendszerbe. Továbbá akkumulátorok alkalmazásával kisebb teljesítményű tápegység beépítése elegendő, mert az ajtók mozgatásához szükséges magasabb áramerősséget ilyenkor az akkumulátorok biztosítják erre az időre. A jelenlegi megoldásban kettő autóakkumulátor soros kapcsolásával van biztosítva a 24V. Az akkumulátorok töltésének a vezérlését illetve felügyeletét az IO modul végzi, az akkumulátor feszültségének figyelésével. Ide még valami sematikus ábra jöhetne
6. A nyomtatott áramköri lapok megtervezése A
kapcsolási
rajzok
megrajzolása
után
lehetett
nekiállni
a NYÁK
lapok
megtervezésének, a fő szempont az volt, hogy csak a szükséges legkisebb méretűek, és könnyen szerelhetőek legyenek az elkészült áramkörök. A felhasznált tervező szoftver az elterjedten használt Altium Designer 10-es verziója volt. Az alkatrészekből amit csak lehetett, SMD kivitelben terveztem a modulokra, passzív alkatrészek a szenzor és az IO modulon 1206-os méretűek, a vezérlő modulon a nagyobb alkatrészsűrűség miatt 0805-ös méretűek, így kényelmesen elférnek. A huzalozás és a furatátmérőket úgy választottam meg, hogy ne számoljanak fel rajzolatfinomsági felárat az áramkör legyártása során. A legvékonyabb vezetősáv szélesség 10mil és a legkisebb furatátmérő 0.6mm. Az egyes moduloknál a kapcsolóüzemű tápegyégeknél figyelembe vettem az alkatrészek elhelyezésénél. és a vezetősávok
rajzolásánál
a
fontosabb
irányelve
betartására.
Az
alkatrészek
33 elhelyezésénél figyeltem arra, hogy a magasabb alkatrészek a felső rétegre kerüljenek, így később a dobozolás egyszerűsödik, és az áramkörök kultúrált megjelenésűek. Az áramkörök tervezése során hasznosnak bizonyult a NYÁK tervező 3D megjelenítési képessége, így képet lehetett kapni arról, hogy minden alkatrész megfelelően elfér-e.
7. Modulok élesztése Az áramkörök összeforrasztása és szemrevételezés után áramkorláttal ellátott tápegységgel ráadtam a tápfeszültséget, és közben mértem a felvett áramerősséget. Normál esetben mindegyik modulnak 100mA alatt kell hogy fogyasszanak, el nem indított szoftverrel. Az áramerősség megmérése után ellenőriztem a 3.3V-os tápfeszültség meglétét és helyességét, majd, ezek után a mikrovezérlőhöz tartozó programozó hardver csatlakoztatása után ellenőriztem hogy "él"-e a mikrovezérlő. Mivel a működtető szoftver a hardverek elkészülésekor még nem állt rendelkezésre, emiatt a különféle perifériákat lépésről-lépésre lehetett csak tesztelni a szoftver írásával párhuzamosan. A szoftver fejlesztésének előrehaladásával sikerült megállapítanom, hogy minden beépített periféria és hardveres funkció a terveknek megfelelően működőképes.
34
8. Szoftver 8.1 Fejlesztőkörnyezet A felhasznált mikrovezérlő szoftverének a fejlesztéséhez szükséges a megfelelő fejlesztőkörnyezet feltelepítése kialakítása. Az STM32-höz léteznek fizetős, "gyári" szoftvercsomagok, csak ezek próba verzióban érhetőek el szabadon letöltésre, így általában néhány fontos funkciójuk nem érhető el, illetve csak erőteljes méretbeli korlátozással hajlandóak fordítani. Ezen okokból maradtam ingyenesen használható megoldásnál. A cortex-M3-mas mikrovezérlőkhöz többféle ARM-ra portolt GCC fordító található, az én választássom az általánosan elterjedt Mentor Graphics által gondozott Codesourcery G++ lite verziójánál maradtam, a fejlesztés elején, így a szenzormodulokat működtető szoftvert ebben írtam meg, és ebben lett elkezdve a vezérlőmodul is. Később találkoztam a Coocox IDE nevezetű fejlesztőkörnyezettel, és próbaképpen átportoltam a projectet. Használata során kiderült hogy bár néha vannak benne még kiforratlan funkciók, alapjában véve nagyon használható és kényelmes fejlesztőkörnyezet. A legnagyobb előnyét akkor láttam meg, amikor bármilyen különféle speciális beállítás nélkül sikerült a Debug üzemmdot használni. A mikrovezérlőre írt szoftvert C nyelven írtam meg, a fejlesztés során próbáltam minél modulárisabb módon szervezni, hogy később könnyen lehessen módosítani, illetve az általam megírt kódot később máshol is fel tudjam használni. Amiből már létezett előre megírt library, azt próbáltam felhasználni, hogy gyorsabban lehessen haladni a fejlesztéssel. Így használtam a fájlkezelés illetve az ethernet modul kezelését. A grafikus kijelzőhöz egy nagyrészt saját magam által írt library-t használok.. Az egyes szoftvermodulokat alább foglalom össze, komponensenként bemutatva. Az egyes komponensek fontosabb tulajdonságait mutatom be, illetve néhány fontosabb függvén működését.
8.2 Programozó hardver Fejlesztés során a futtatható kód feltöltésére több lehetőség kínálkozik ezeknél a mikrovezérlőknél. Az egyik lehetőség a beépített bootloader segítségével UART-on vagy CAN buszon felmásolni, de ilyenkor nagyon korlátozottak a debuggolási lehetőségek. A fejlesztési célokra ilyenkor a élszerű eljárás JTAG-et használni, vagy újabban SWD portot (LÁBJEGYZET). A fejlesztés során eleinte az OpenOCD szoftver
35 csomaggal használtam egy FT2232-es IC-vel épített USB-s JTAG programozót, de később mikor áttértem a Coocox fejlesztőkörnyezetre, akkor ott már egy olcsó STM32Discovery fejlesztőpanelt használtam, amellyel lehetőség van külső áramkört programozni. Szerencsére az STM32-es mikrovezérlőknél a JTAG lábakra kivezetve megtalálható az SWD programozáshoz használható kivezetések, így csak egy átalakító szalagkábelt kellett készítenem a használatához.
25. ábra forrás: http://www.jann.cc/_images_big/stm32/STM32F0-Discovery_side.jpeg
8.3 Operációs rendszer Komolyabb beágyazott rendszerek esetén célszerű használni valamilyen beágyazott operációs
rendszert
a
különféle feladatok
ütemezésére,
segítségével
nagyon
leegyszerűsödik a rendszer feladatok szervezése. Jelen esetben a választásom az ingyenesen hozzáférhető FreeRTOS operációs rendszerre esett. Az egész rendszerben csak a vezérlőmodulon található operációs rendszer, a szenzormodulokon az egyszerűségük miatt felesleges lenne operációs rendszert használni. Az operációs rendszert jellemzi a moduláris felépítés és a testreszabhatóság, sok mikrovezérlőre készült már el a portolt változata. Jelen esetben STM32-es processzorra már készen megtalálható volt a működőképest változata. Az elindításához szükséges hogy néhány interrupt vektort (!!!melyikeket) átirányítsunk a operációs rendszer számára, majd a megfelelő fordítás paraméterek beállítása után meg kellet írni az egyes taszkokat, és elindítani a feladatütemezőt. A működést alapvetően 4 taszk végzi: - Control_TASK - Communication_TASK
36 - uIP_Task - uIP_periodic_Task
8.3.1 Control_Task Feladata a vezérlőmodul fő funkcióinak a működtetése, ez felel a szenzoroktól kapott adatok és a beállított értékek szerinti, a feltételeknek megfelelő vezérlését a többie moduloknak. Működése során ellenőrzi először hogy az érintőképernyő megvan-e nyomva, ha igen, akkor elindítja a menürendszer kezelő függvényt. Továbbiakban, a CAN buszon beérkezett adatoknak megfelelően vezérli az IO modult. és a taszk végül frissíti a kijelzőn lévő megjelenített adatokat. A menürendszer kezelése közben az TCP/IP stack működése fel van függesztve, mivel egy buszon található az SD kártya és az ethernet vezérlő, és a menürendszer SD kártya kezelése össze tudott akadni, továbbá nem indokolt hogy ezt a két funkciót egyszerre tudja működtetni. 8.3.2 Communicaton task Ez a taszk felel az adatok küldéséért és fogadásáért a CAN buszon. Mivel az egyes modulok úgy működnek, hogy különféle lekérdezésekre válaszolnak csak, maguktól adatokat nem küldenek, ezért a ennek a taszknak a feladata az, hogy periodikusan lekérdezgesse a modulokat. További feladata kimenő adat esetén, hogy megfelelő írás parancs kiküldése a szenzor számára, az adatokkal. Ennek akkor van szerepe példul, amikor az IO modulnak küldi ki az ajtók nyitását vagy zárását, illetve az akkumulátor töltés engedélyezést.
8.3.3 uIP_Task Ez a taszk felel az ethernet csomagok kiolvasásáért az ethernet vezérlőből. Ha volt beérkező csomag, akkor eldönti hogy IP vagy ARP csomag jött, majd ezeket feldolgozza. Abban az esetben ha keletkezett válasz akkor az ethernet vezérlőnek továbbadja a csomagot, amely elküldi a hálózat felé.
8.3.4 uIP_periodic_Task A taszk feladata nyitott TCP kapcsolatok esetén ARP csomagok küldése a hálózatra 500ms ismétlődéssel (TCP keep-alive), illetve 10 másodpercenként az ARP tábla frissítése.
8.4 Fájlkezelés A kijelzőn megjelenített grafikák tárolása a beépített SD kártyán történik. Mikrovezérlős környezetben jelenleg talán a legegyszerűbben megvalósítható nagyobb
37 méretű adatok tárolására a könnyű cserélhetőség, és kezelés szempontjából. A kártyán az elterjedt FAT32-es fájlrendszer található, mivel mikrovezérlővel ez egy viszonylag kis erőforrás igénnyel kezelhető megoldás, és megvan az előnye, hogy fájlokat lehessen kívülről számítógépről rámásolni, ha nincs arra szükség hogy mikrovezérlő írjon a kártyára. A fájlrendszer kezelését a mikrovezérlős körökben a jól elterjedt és bevált FatFS könyvtár végzi. A driver C nyelven írdott, réteges szervezésű. Az adott rendszerhez való portolásáhioz elegendő csak az alacsonyszntű függvényeket a hozzáigazítani az alkalmazáshoz, ebből adódólag gyakorlatilag tetsőleges háttértár típuson működőképes.
Konfigurációs lehetőséget biztosít arra, hogy ha kevesebb
erőforrással rendekező mikrvezérlőn alkalmazzák, akkor a nem használt funkciókat, függvényeket ki lehet kapcsolni, ezáltal memóriát lehet spórolni. A réteges felépítését az alábbi ábra szemlélteti
26. ábra - forráS?
Az alsó szinten találhatóak meg az alacsonyszintű driverek, jelen alkalmazásban itt szükkséges hozzáigazítani a mikrovezérlő SPI busz kezelő függvényeihez, mivel az SD kártya ezen a buszon található meg. Ez az alacsonszintű működtetés az alábbi 5 alapvetű föggvényre épül disk_initialize() Háttértár inicializálása disk_status() Háttértár státusz lekérdezése disk_read() Egy blokk olvasása disk_write() Egy blokk írása disk_ioctl() Vezérlő parancsok küldése Ezek a függvények biztosítják az alapvető interfészt a felsőbb szintű funkcióknak, illetve ezek határozzák meg hogy milyen hardvert is kezel a library. Szerencsére STM32-re létezett már előre portolt változat, így elegendő volt a mikrovezérlő
38 kivezetéseit definiáló sorokat hozzáigazítani a jelen áramkörhöz. A driver felasználja a DMA-s átvitelt az SD kártyáról a memóriába történő olvasás során, így használatával nagy sebességkülönbséget lehetett észlelni. Az alapszintű driver beállítása után történhet maga a könyvtár használata. A meghajtó inicializálásához elegendő meghívni a disk_initialize(), a fájlrendszer inicializálásához a f_mount() függvényeket. A gyökérkönyvtár megnyitásához lehet hasznáni a f_opendir() függvényt. Mindegyik függvény rendelkezik hibakezeléssel visszatérési értékként, így hiba esetén a megfelelő képet lehet kapni ahibáról és segítséget nyújt az elhárításában. Ezek után tetszőlesen lehet fájlműveleteket végezni a meghajtón.
8.5 Ethernet kezelés A vezérlőrendszer távoli menedzsmentjét legegyszerűbben valamilyen ethernet alapú megoldással volt célszerű megoldani. Manapság már nem olyan bonyolult ez a feladat, mivel a mikrovezérlő gyakorlatilag perifériaként tartalmazzák az ethernet vezérlőt. Mivel ebben a rendszerben nem fő feladatnak szántam az ethernet kapcsolatot, és inkább a a kijelzőt meghajtó memória interfészre tettem a hangsúlyt, a felhasznált mikrovezérlőben nem található ethernet modul, így egy különálló ethernetvezérlőt kellett használnom <ez madnem jo, de a HW helyre kell irni. 8.5.1 uip TCP/IP stack Az áramkörbe épített ENC28J60-as ethernet vezérlő meghajtását végzi az uip TCP/IP stack. Ez a stack az Adam Dunkels által kifejleszett LWIP (lábjegyzet) egyszerűsített változata. Sokkal kevesebb RAM memóriát használ fel a működéséhez, cserébe viszont a csomagok összeállítása sokkal bonyolultabban történik, és sok funkció csak korlátozottan működik. A stack működtetéséhez elegendő biztosítani az ethernet vezérlőhöz tartozó csomag küldő és fogadó függvényt. Bejövő adatcsomag esetén ellenőrzi a csomag típusát és annak megfelelően dolgozza fel. Lényegében bejövő csomag esetén meg kell hívni a stack magasabb szintű feldolgozó függvényét (ipin....) Ennek futása során egyre alacsonyabb szinten feldolgozza, és biztos hogy véges idő múlva visszatért. Visszatérés után az egyetlen feladat azt ellenőrizni, hogy keletkezett-e valamilyen elküldendő ethernetes csomag az adat bufferban, nem nulla adathossz esetén meg kell hívni az ethernet vezérlő csomag küldő függvényét. A jelenlegi alkalmazásban külön operációs rendszer taszk-ként fut az TCP/IP stack. A stack elindításához csak az Ethernet vezérlő alapszintű felkonfigurálása szükséges, ezt minta kód segítségével a C nyelv adottságaiból kifolyólag viszonylag könnyen meg lehetett tenni. Ebben a fázisban
39 van megadva a ethernet illesztőnek a MAC címe, illetve a szükséges IP konfiguráció, jelen alkalmazásban statikus IP címet használ, de a stack képes lenne DHCP segítségével saját IP címet kérnie. 8.5.2 Weboldal A megjelenítendő weboldal a mikrovezérlőben van letárolva a belső Flash memóriában. Ebből kifolyólag célszerű volt minimalizálni a weboldal méretét, és célirányos egyszerű weboldalt fejleszteni. HTTP lekérdezés esetén ellenőrzi hogy a kért fájl megtalálható-e a memóriában, sikeres lekérés esetén továbbítja a kliens felé, ellenkező esetben hibakezelésként a szabványos 404-es hibát adja vissza.
A weboldalon alapvetően a rendszerre jellemző szenzorok által mért értékeket láthatjuk, ezek közé tartozik a hőmérséklet, páratartalom, akkumulátor töltöttség, szélerősség, illetve az ajtók állapota Ezek táblázatos formátumban találhatóak meg. A távoli vezérléses funkciókat úgy valósítja meg a webfelület, hogy a beállított határértékek módosítására is lehetőséget biztosít ugyanúgy mint a menürendszerben. Így módosítani
40 lehet hőmérséklet, páratartalom, és szélerősség határértékeket. További funkcióként a webfelületről le lehet állítani az automatikus, időjárás szerinti működést, és a honlapon lévő vezérlő gombokkal lehet az ajtókat manuálisan zárni illetve nyitni, olyan esetben lehet erre szükség ha valami nagyobb vihar közeleg és emiatt be akarjuk zárni biztonsági okoból az ajtókat. 8.5.3 Webszerver funkciók Adatok megjelnítését egy CGI
(Common Gateway Interfae) alapon működő
megoldással végzi. A megjelenítendő HTML oldalra el kell helyezni egy megfelelő szöveges tag-et. Küldés során amikor beolvassa a tag-et, akkor lefuttat egy előre definiált függvényt, amelynek a kimenetét küldi el a kliens felé szöveges formátumban, majd folytatja az oldal további küldését. Ezt a funkciót úgy használom ki, hogy előállítok egy javascript adattömböt, amelyet elküldök a kliensnek, majd miután az egész html oldalt megkapta, akkor egy általam írt javascripttel frissíti a weblapon található mezőket. Adatok továbbítása a szerver felé a beágyazott rendszernél megszokott módon lekérdezés segítségével történik. Ez a rész ilyen módon hiányzott a webszerver funkciói közül,emiatt kiegészítést kellett tenni. A lekérdezésnél a weboldal.shtm?valtozo=ertek lekérdezéssel lehet a különféle változók értékeinek módosítására. Lekérés esetén a szerver ellenőrzi a cím végén a '?' karakter utáni részt, ebből megfelelő szöveges interpretálással frissíti a hozzátartozó paramétert a rendszerben. Ezt felhasználtam paraméterek beállítására, illetve HTML gombok funkcióinak a megvalósításához. Ezekből látható hogy beágyazott webszerverek esetén az weboldal tartalma szorosan kapcsolódik a megvalósítandó funkciókhoz, így a weboldalt célszerűbb a Flash memóriában tárolni, mert gyakorlatilag csak fejlesztés folyamán alakul ki a végleges változat.
8.6 Grafikus kijelző A kijelzőhöz a gyártó szolgáltatott inicializációs beállításokat, és egy függvényt amivel pixelenként lehetett rajzolni, az összes magasabb szintű grafikus megjelenítést magam írtam meg. A kijelző a mikrovezérlő FSMC (flexible static memory controller) buszához csatlakozik. A nagy előnye ennek, hogy a kijelzőre íráskor nem a GPIO lábakat kell kezelni, hanem a kijelző egy bizonyos memóriacímen lesz elérhető, így az adat küldés
41 leegyszerűsödik egy pointernek való értékadásra, illetve használhatóvá válik a DMA periféria is a még gyorsabb adatátvitel segítéséhez. Ennek megfelelően a kijelző az alábbiak szerint van memóriacímhez rendelve #define LCD_BASE ((uint32_t)(0x60000000)) __IO uint16_t * LCD_REG = (uint16_t *) (LCD_BASE); __IO uint16_t * LCD_RAM = (uint16_t *) (LCD_BASE +(1<<17));
Látható hogy más címen található a kijelző memória és regiszter címe, ez a valóságban úgy jelenik meg hogy a RAM-ba íráskor a kijelző Resgister Select lába mags szinten van, amivel jelezve van hogy adatot kap a kijelző, amikor alacsony, akkor regisztereket címez meg. A kijelző használatához előtte inicializálni kell, ehhez az SSD1289-es kijelző meghajtó IC adatlapja nyújt segítséget, az alábbi függvényismételt meghívásával lehet konfigurációs regiszterekbe írni beállításokat, így lehet a kijelző méretét, orientációját, címtartományát illetve egyéb jellemzőket beállítani. void LCD_WriteReg(uint16_t LCD_reg_addr, uint16_t LCD_Reg_value) { *LCD_REG=LCD_reg_addr; *LCD_RAM=LCD_Reg_value; }
Ezek alapján konfigurálás után a kijelzőn való megjelenítéshez be lehet állítani a kezdő címet, majd a memória írás parancs után a kijelző a pixelek színkódjának megfelelő színű képpontot jelenít meg, és a címet automatikusan növeli. Így, egy címbeállítás után használni lehet a DMA-t nagyobb képek megjelenítéséhez. Ezek alpján leegyszerűsítve az albbiak szerint történik egy képernyőpont megjelenítése void LCD_pixel() { LCD_WriteReg(0x004f,xpos); //x cim LCD_WriteReg(0x004e,ypos); //y cim *LCD_REG=0x22; //memoria iras parancs *LCD_RAM=color; //pixel szin }
Ezek alapján meg lehetett írni a megfelelő függvéneket amelyekkel magasabb szintű ábrázolsát lehet megvalósítani, például vonalak, téglalapok körök ábrázolása. Mivel a kijelző nem rendelkezik karakter generátorral, ezt szoftverből kellett megvalósítani. Ehhez az ASCII karaktertábla bitmintáit le kellett tárolni a mikrovezérlő Flash memóriájában, és onnan megjeleníteni. Két féle betűtípus készült, egy 8x10 pixel és
42 19x24 pixel méretű betűtípus. A grafikus felület megvalósítására további függvényeket kellett megírni. A grafikus felletet alkotó képek illetve ikonok az SD kártyán találhatóak meg szabványos .bmp fájlformátuban. A megjelenítéshez kiolvassa a fejlécet, és az ott található adatok alapján történik a képtartalom további megjelenítése
8.7 Menürendszer javítani A vezérlőmodul kijelzőjén alapvetően a főképernyő látható.
A menürendszert saját készítésű menükezelő működteti. Több szintűen épül fel, megírása közben fontos szempont volt hogy minél univerzálisabb legyen.
43
27. ábra - A menürendszer felépítése
Innen belépve a főmenü következik, a jobbra/balra nyilakkal lehet végiglépni a különböző főbb menüpontok között.
28. ábra - főmenü
Az egyes menüpontokon belül található még egy kiválasztó almenüpontok. Ezeket a menüpontok számának függvényében dinamikusan átméretezi mind a sávok mérete, mind a karakterméret szempontjából.
44
29. ábra - kiválasztó almenü
A legalsó szint az egyes paraméterek beállítását szolgálja. Ebből a menüpontból létezik egy illetve két paramétert állító változat. A rendszer felépítése és működése szempontjából az különböző paramétereket számszerűen megadhatóak, így elegendő volt így megoldani a kezelést.
30. ábra - Beállító almenü
8.8 CAN busz kezelés A rendszer moduljai CAN buszon kommunikálnak egymással, A beépített mikrovezérlők tartalmazzák a CAN vezérlőt, így csak a fizikai réteget kell számukra biztosítani, ezek itt a TI gyártmányú SN65HVD230 típusú illesztők lettek. A mikrovezérlőben lévő CAN vezérlőt indulás után be kell konfigurálni. A CAN buszon a
45 modulok egymással egy előre meghatározott közös baudrate-el kommunikálnak egymással. A hardvert szükséges a megfelelő sebesség beállítással elindítani, A buszon figyelembe véve a rendszer méreteit, és az átvinni kívánt adat mennyiségét, bőségesen elegendő 125000 baud körüli sebesség. Ezt az alkalmazott STM32-es mikrovezérlőben az alábbiak alapján lehet kiszámítani:
Feltételezve hogy 24MHzes periféria órajel áll rendelkezésre, 125000 baud-os sebesség a fenti képlet alapján számolva néhány próbálkozás után az alábbiak szerint áll elő. BRP előosztó =7+1, tehát a tq időkvantum 0.3333usec, ha az első bitszegmens idejét 15-re (BS1) a másodikat 8-ra (BS2) választjuk, akkor az egész bit idő 8usec-re áll elő, ami alapján a baudrate 125000. Maga a CAN buszon történi adattovábbítás úgy működik, hogy étre kell honi egy CanTxMsg típusú struktúrát, amelyben szükséges kitölteni a StdId cím mezőt, a DLC adathosszat és az adathosszban jelzett számú Data bájt típusú adatmezőket. Ezek után egyszerűen csak meg kell hívni a CAN_Transmit() függvényt, és ezzel az adatot továbbítja a buszra. Adatfogadásához az egyik lehetőség hogy lekérdezéssel ellenőrizzük, hogy valamelyik vevő oldali FIFO-ba érkezett-e érvényes adat, vagy automatikusan a megszakításkezelő függvényben dolgozzuk fel. A beérkezett adat hasonló felépítésű CanRxMsg típusú struktúrában elérhető ha meghívjuk a CAN_Receive() függvényt. A rendszer működésénél a követelmények alapján megfelelőnek bizonyult az egyszerűbb
lekérdezés-válasz
kommunikáció.
Magasabb
szintű
CAN-buszos
kommunikációt nem valósítottam meg a rendszeren. A kommunikáció ilyen formájában
46 ügyeltem arra, hogy úgy legyen felépítve az adattovábbítás, hogy esetlegesen elvesző csomag esetén se álljon le a rendszer. Az üvegházvezérlő rendszernél létrehoztam egy CAN eszköz cím adatbázist, amelyben az egyes modulok címei találhatóak meg. Ezek alapján az egyes eszközök címei, és a hozzájuk tartozó adatmezők jelentései az alábbi táblázatok alapján alakultak: Modul neve
STDID
DLC
DATA0
DATA1
DATA2
DATA3
Külső pára+hő szenzor
0x91
1
CMD_READ
×
×
×
Belső pára +hő szenzor
0x89
1
CMD_READ
×
×
×
Távirányító modul
0x88
1
CMD_READ
×
×
×
Távirányító modul
0x88
4
CMD_WRITE
InTemp
InTempFract
State
Szélerősség szenzor
0x92
1
CMD_READ
×
×
×
IO_modul
0x93
1
CMD_READ
×
×
×
IO modul
0x93
1
CMD_WRITE
DoorState
Battery_chg
GPIO
3. Táblázat
A fenti táblázatban látható a moduloknak küldött csomagok CAN adatmezőinek a tartalma. Látható hogy a legtöbb modulnál csak egy egyszerű olvasás kérés található (CMD_READ = 0x01), amelyre általában csak egy környezeti változó a válasz. Némely modulnál adatokat is lehet küldeni, ezt a CMD_WRITE (0x02) paranccsal lehet megtenni, ilyn parancs például a távirányító modulnál a megjelenítendő hőmérséklet a kijelzőn, vagy a LED-ek állapota. Az IO modulnál ilyen módon lehet kapcsolni az ajtókat működtető reléket, illetve az akkumulátor töltőt, valamint a GPIO lábakat. Modul neve
STDID
DLC
DATA0
DATA1
DATA2
DATA3
Külső pára+hő szenzor
0x91
4
OutTemp
OutTempFract
Humidity
TimeStamp
Belső pára+hő szenzor
0x89
4
InTemp
InTempFract
Humidity
Timestamp
Távirányító modul
0x88
1
ButtonSt.
×
×
×
IO modul 1
0x93
Ubatt
UbattFract
BattChSt
×
Szélerősség szenzor
0x92
Windspeed
×
×
×
4. Táblázat
Az előbbi lekérdezésekre adott válaszcsomagok tartalmát a xxxxxx táblázat tartalmazza. Ezek a CMD_READ parancsra küldött válaszok. Hő és páratartalom mérő 2 darab található a rendszerben, az egyik a fóliasátran kívüli hőmérsékletet méri, a másik a belsőt. A hőmérsékleti adatokat úgy küldik el hogy az egész részt jelentő bájtot illetve a tizedestört után található 1 tizedes jegyet külön, majd egy egyszerű 8 bites TimeStamp értéket, esetleges későbbi felhasználásra. A távirányító modulnál a rajta található gombok megnyomása esetén a gombok állapotát tartalmazza a csomag, míg IO
47 modulnál az akkumulátor feszültségét illetve az akkutöltő állapotát tartalmazza a csomag.
48
9. Összefoglalás Munkám során sikerült egy rendszer felépítésének tervét létrehozni, amelynek segítségével hardver és szoftver követelményeket tudtam meghatározni. Majd ezekből kiindulva megterveztem és beüzemeltem a hardver modulokat. A fejlesztés folyamán lépésenként egyre összetettebb feladatokat sikerült megvalósítani a rendszerrel, míg eljutott a követelményekben meghatározott szintre. Ezek alapján a rendszer alkalmassá vált hogy a rendeltetési helyén tudja teljesíteni a célját. A rendszer fejlesztése során hasznos ismeretekre tettem szert mind az összetettebb hardverek fejlesztése terén, mind a komplex működtető szoftver megírása területén. A fejlesztés során több buktatóba sikerült belefutni, ezek közül az eredetileg beletervezett
CAN
busz
meghajtó
IC
(MCP2555)
nem
működött
3.3V-os
tápfeszültségről, amelynél az adatlap olvasása során átsiklottam, ezt a problémát az SN65HVD230-as IC használata oldotta meg. Továbbiakban vezérlőmodulban használt mikrovezérlő FMSC moduljának inicializációs példakódjában talált hiányosság miatt, /wait jelre vált a kijelzőtől a processzor, amely ilyet nem szolgáltat, emiatt néha befagyasztotta a futást, és a Debug funkció ezt nem tudta kimutatni. Továbbfejlesztés céljából a webfelületen megfelelő minimalista javascript használatával grafikonokat lehetne elhelyezni az elmúlt időszakról, illetve az SD kártyára lehetne naplózás céljából hőmérsékleti adatokat menteni.
49
10. Irodalomjegyzék ez még erőteljeen hiányos, ki kell bővíteni a szöeg alapján.... [23]
ELM-Chan FatFS http://elm-chan.org/fsw/ff/00index_e.html
[21]
The FreeRTOS project http://www.freertos.org/
[12]
The uIP 0.9 ReferenceManual (2013 november) http://www.cs.tut.fi/~sulo/harjoitustyo/btweb/uip-0_9-refman.pdf (2013 november)
50
11. Függelék
51
52
53
54
55
56
57
58
Erre az 1-2 oldalra még NYÁK tervek jönnek mondjuk
