DIY naplózási hőmérő 2 érzékelővel: 3 lépés (képekkel)

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:40

Ez a projekt az előző "DIY naplózási hőmérő" projektem továbbfejlesztése. Naplózza a hőmérsékleti méréseket egy micro SD kártyára.

Hardver változások

Hozzáadtam egy DS18B20 hőmérséklet -érzékelőt a valós idejű óra modulhoz, ahol a nyomtatott áramköri lap rendelkezik ezzel az eszközzel; és hozzáadta a megfelelő vezetéket az RTC "DS" csapjából az Arduino D2 -hez.

Szoftver változások

Ezután hozzáadtam és módosítottam a szoftvert. A fő változások a következők:

Az LCD kijelző két hőmérsékletet mutat: "Be" és "Kimenő".

Az SD -kártyára rögzített naplófájlok két hőmérsékletmezővel rendelkeznek: "hőmérséklet be" és "hőmérséklet ki".

Az SD -kártyán lévő hosszabb rögzítés miatt az EEPROM munkapufferei nagyobbak voltak, és emiatt memóriakonfliktusokkal kezdtem küzdeni. Számos változtatást eszközöltem a dinamikus memória használatának csökkentése érdekében, beleértve a karakter tömbök használatát minden karakterlánchoz a String objektum helyett.

A szoftver azon része, amely megkapja a hőmérsékleteket, jelentős módosításokat tartalmaz, amelyek nagy része annak azonosítására szolgál, hogy melyik szonda van "be" és melyik "kint". Ez az azonosítás többnyire automatikus. Ha valamilyen oknál fogva a szondákat megfordítják, akkor ezt úgy lehet kijavítani, hogy kihúzza a "out" szondát, majd ismét csatlakoztatja. Ezt a fordulatot magam sem tapasztaltam. A programozónak vagy a felhasználónak nem kell beírnia az érzékelő címét, a szoftver magától felfedezi a hőmérséklet -érzékelő címét.

Az elvégzett vizsgálatok szerint a hőmérséklet -érzékelők azonosítása, valamint az SD -kártya eltávolítására és cseréjére adott válasz továbbra is zökkenőmentesen működik.

1. lépés: Szoftverfejlesztés

Ez a lépés megadja a teljes szoftvert a befejezett projekthez. Arduino IDE 1.6.12 segítségével állítottam össze. 21 400 bájt programmemóriát (69%) és 1 278 bájt dinamikus memóriát (62%) használ.

Megjegyzéseket fűztem a kódexhez abban a reményben, hogy világossá válik, mi történik.

2. lépés: Két hőmérséklet -érzékelő használata - részletek

Ez a szoftver a "OneWire" könyvtárat használja. Nem használ semmilyen "DallasTemperature" vagy hasonló könyvtárat. Ehelyett a parancsokat és a hőmérséklet -érzékelők adatait a vázlat végzi, és könnyen láthatók és érthetők. Találtam egy hasznos listát a OneWire könyvtárparancsokról a címen

www.pjrc.com/teensy/td_libs_OneWire.html

Ha két (vagy több) hőmérséklet -érzékelő van, szükségessé válik annak azonosítása, hogy melyik melyik.

A két érzékelőmet "be" és "kint" neveztem, ami jellemző a kereskedelmi egységekre, amelyek érzékelője a kijelzőmodulban általában "belül" van, a másik érzékelő pedig egy kábelen, így a másik oldalra is elhelyezhető külső falról, és így "kívül" legyen.

A különböző szondák azonosításának szokásos módja az eszközcímek felfedezése, és azonosító címkével együtt történő elhelyezése a szoftverben. Az összes többi projekt, amelyet láttam, ezt a megközelítést használja, függetlenül attól, hogy használják -e a DallasTemperature könyvtárat vagy sem.

Az volt a szándékom, hogy a szoftver automatikusan azonosítsa az érzékelőket, és helyesen rendelje hozzá őket „be” és „ki” értékekhez. Ez elég egyszerű, ha külön Arduino csapokra helyezi őket. Ebben a projektben az A0 -tól A3 -ig, valamint az A6 -tól és az A7 -től mindannyian nem használtak, így az egyiket ebben az esetben is lehetett volna használni. Azonban sikerült, hogy az automatikus azonosítás ugyanazon a OneWire buszon működjön együtt az érzékelőkkel.

Ez így működik.

A OneWire könyvtár "OneWireObject.search (cím)" parancsot tartalmaz, ahol a "cím" 8 bájtos tömb, a "OneWireObject" pedig a korábban létrehozott OneWire objektum példányának neve. Bármilyen neve lehet. Az enyémet "ds" -nek hívják. Amikor kiadja ezt a "keresés" parancsot, a OneWire könyvtár jelez az egy vezetékes buszon. Ha válaszoló érzékelőt talál, akkor "TRUE" logikai értéket ad vissza, és kitölti a "address" tömböt az érzékelő 8 bájtos egyedi azonosítójával. Ez az azonosító tartalmaz egy családi kódot (az elején) és egy csekkszámot (a végén). Között 6 bájt van, amelyek egyedileg azonosítják az érzékelőt a családjában.

A parancs megadásakor egy eredmény (cím és visszatérési IGAZ) érhető el, és a OneWire buszon lévő összes eszközön végighalad. Miután minden eszköz válaszolt, a következő alkalommal, amikor a "keresés" történik, a visszatérés "HAMIS", ami azt jelzi, hogy a buszon lévő összes eszköz már válaszolt. Ha a "keresést" újra kiadja, az első eszköz újra válaszol - és így tovább a végtelenségig. A készülékek mindig ugyanabban a sorrendben válaszolnak. A válaszok sorrendje a OneWire buszon lévő eszközök azonosítóin alapul. Úgy tűnik, hogy ez egy bináris keresés, amely az eszközazonosítók legkevésbé jelentős bitjeiből indul ki. Az azonosítók megtalálásához használt protokoll meglehetősen bonyolult, és ezt az "Book of iButton Standards" dokumentum 51-54. Oldala írja le, amely egy pdf dokumentum a https://pdfserv.maximintegrated.com/en/an/AN937.pd címen. …

Kipróbáltam ezt a keresési folyamatot 1–11 érzékelővel egyetlen buszon, és azt találtam, hogy egy adott eszközkészlet válaszrendje mindig ugyanaz volt, de amikor új eszközt adtam a busz végéhez, nem volt mód Meg tudtam jósolni, hogy a keresési sorrendben hol fog megjelenni. Például az általam hozzáadott 11. érzékelő az 5. pozícióban jött be; és az első érzékelő, amit a buszra tettem, a keresési sorrendben az utolsó volt.

Ebben a projektben két érzékelővel az egyiket a helyére forrasztják az RTC modulra; a másik csatlakozik a tábla férfi fejléce és a kábel női fejfej segítségével. Könnyen leválasztható.

Amikor a kábel érzékelője (a "ki" érzékelő) leválik, a "search" parancs váltakozó "TRUE" és "FALSE" eredményeket ad.

Ha a kábel érzékelője csatlakoztatva van, a "keresés" parancs háromlépcsős ciklust eredményez, két "IGAZ" és egy "HAMIS" értékkel.

Az én eljárásom az, hogy 1, 2 vagy 3 "keresési" parancsot adjak ki, amíg a HAMIS eredményt vissza nem adják. Ezután kiadok még 2 "keresési" parancsot. Ha a második meghibásodik (azaz HAMIS), tudom, hogy csak egy érzékelő van a buszon, és ez az "in" érzékelő. Az eszköz azonosságát rögzíti és hozzárendeli az "in" érzékelőhöz.

Később, ha az első és a második visszatérés is IGAZ, tudom, hogy két érzékelő van a buszon. Ellenőrzöm, hogy melyikük azonos az "in" érzékelővel, és a másikat kiosztom "out" érzékelőnek.

A másik kisebb pont, hogy az eredmények összegyűjtése a két érzékelőből úgy történik, hogy elküldi a "konverzió indítását" az úgynevezett "skip ROM" parancs segítségével. Lehetőségünk van parancsok küldésére egyetlen eszközre (az egyedi azonosító használatával) vagy a buszon lévő összes eszközre (ugrás a ROM -ra). A kód így néz ki:

ds.reset (); //

// send "skip ROM" parancs (tehát a következő parancs mindkét érzékelőnél működik) ds.write (0xCC); // ROM parancs kihagyása ds.write (0x44, 0); // konverzió indítása mindkét szondában hőmérséklet_állapot = wait_convert; // menjen késleltetett állapotba

Ha a szükséges késleltetési idő letelt, a hőmérsékletet minden érzékelőtől egyenként kapja meg. Itt található a második érzékelő (azaz az OUT érzékelő) kódja.

if (zászló2) {

jelen = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Olvassa el a "out" szondaadatok Scratchpadjét [0] = ds.read (); adatok [1] = ds.read (); hőmérséklet_kimenet = (adatok [1] << 8) + adatok [0]; hőmérséklet -ki = (6 * hőmérséklet -ki) + hőmérséklet -ki / 4; // szorozzuk meg 6,25 -vel} else {// nem zászló2 - azaz a kimenő érzékelő nincs csatlakoztatva hőmérséklet -ki = 30000; // javítás 300,00 C -on, ha a hőmérséklet -érzékelő nem működik} // if vége (zászló2)

A szoftver nagy részét önálló vázlatban dolgoztam ki, amelyben éppen a hőmérséklet-érzékelők voltak, az LCD, RTC és SD kártya támogatás komplikációi nélkül. Ez a fejlesztési vázlat az alábbi fájlban található.

3. lépés: Előzetes eredmények

Ez a diagram az olvasások első két résznapjának kombinációja.