Termòmetre de registre de bricolatge amb 2 sensors: 3 passos (amb imatges)

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:12

Aquest projecte és una millora del meu projecte anterior "Termòmetre de registre de bricolatge". Registra les mesures de temperatura a una targeta micro SD.

Canvis de maquinari

He afegit un sensor de temperatura DS18B20 al mòdul de rellotge en temps real, on hi ha disposició a la placa de circuit imprès per a aquest dispositiu; i va afegir el cable apropiat del pin "DS" de RTC a D2 de l'Arduino.

Canvis de programari

Després vaig afegir i modificar el programari. Els principals canvis són:

La pantalla LCD mostra dues temperatures "In" i "Out".

Els fitxers de registre enregistrats a la targeta SD tenen dos camps de temperatura, "temperatura d'entrada" i "temperatura de sortida".

A causa del registre més llarg a la targeta SD, els buffers de treball per a l'EEPROM eren més grans i com a resultat d'això vaig començar a tenir problemes de conflicte de memòria. Vaig fer diversos canvis destinats a reduir l'ús de la memòria dinàmica, inclòs l'ús de matrius de caràcters per a totes les cadenes en lloc de l'objecte Cadena.

La part del programari que obté les temperatures té modificacions importants, bona part de les quals té a veure amb identificar quina sonda està "in" i quina "out". Aquesta identificació és majoritàriament automàtica. Si per algun motiu es canvien les sondes, es pot corregir desconnectant la sonda "out" i tornant a connectar-la. No he experimentat jo aquesta inversió. El programador o l'usuari no necessita escriure les adreces del sensor, el programari descobreix les adreces del sensor de temperatura per si sol.

Segons les proves que he fet, la identificació de les sondes de temperatura i la resposta a l’eliminació i la substitució de la targeta SD encara funcionen perfectament.

Pas 1: desenvolupament de programari

Aquest pas us proporciona el programari complet per al projecte completat. El vaig compilar amb Arduino IDE 1.6.12. Utilitza 21, 400 bytes de memòria del programa (69%) i 1, 278 bytes de memòria dinàmica (62%).

He posat comentaris al codi amb l'esperança de deixar clar què passa.

Pas 2: Treballar amb dos sensors de temperatura: detalls

Aquest programari utilitza la biblioteca "OneWire". No utilitza cap "DallasTemperature" ni biblioteques similars. En lloc d'això, les ordres i les dades dels sensors de temperatura es fan mitjançant l'esbós i es poden veure i entendre amb força facilitat. He trobat una llista útil de les ordres de la biblioteca OneWire a

www.pjrc.com/teensy/td_libs_OneWire.html

Quan hi ha dos (o més) sensors de temperatura, es fa necessari identificar quin és quin.

He anomenat els meus dos sensors "in" i "out", que és típic de les unitats comercials que tenen un sensor al mòdul de visualització que normalment està "dins" i l'altre sensor d'un cable perquè es pugui posar a l'altre costat d'una paret externa i, per tant, estar "fora".

L’enfocament habitual per identificar les diferents sondes és descobrir les adreces del dispositiu i posar-les al programari juntament amb una etiqueta identificativa. Tots els altres projectes que he vist utilitzen aquest enfocament, tant si fan servir la biblioteca DallasTemperature com si no.

La meva intenció era que el programari identifiqués automàticament els sensors i els assignés correctament a "entrar" i "sortir". Això és prou fàcil de fer col·locant-los en pins Arduino separats. En aquest projecte, A0 a A3 i A6 i A7 estan inutilitzats, de manera que un d’aquests podria haver estat utilitzat en aquest cas. Tot i això, he aconseguit que la identificació automàtica funcionés amb els sensors al mateix bus OneWire.

Funciona així.

La biblioteca OneWire té una ordre "OneWireObject.search (adreça)" on "address" és una matriu de 8 bytes i "OneWireObject" és el nom d'una instància de l'objecte OneWire que s'ha creat prèviament. Pot tenir qualsevol nom que vulgueu. El meu es diu "ds". Quan emeteu aquesta ordre "cerca", la biblioteca OneWire realitza algunes senyalitzacions al bus d'un cable. Si troba un sensor que respon, retorna un valor booleà "TRUE" i emplena la matriu "address" amb l'identificador únic de 8 bytes del sensor. Aquest identificador inclou un codi familiar (al principi) i una suma de xec (al final). Entremig hi ha 6 bytes que identifiquen de forma única el sensor de la seva família.

S’obté un resultat (adreça i retorn TRUE) cada vegada que es dóna aquesta ordre, recorrent tots els dispositius del bus OneWire. Un cop tots els dispositius han respost, la propera vegada que s'emet la "cerca", la devolució és "FALS", indicant que tots els dispositius del bus ja han respost. Si es torna a publicar la "cerca", el primer dispositiu torna a respondre, i així de manera indefinida. Els dispositius responen sempre en el mateix ordre. L'ordre de les respostes es basa en els identificadors dels dispositius del bus OneWire. Sembla ser una cerca binària a partir dels bits menys significatius dels identificadors de dispositiu. El protocol utilitzat per trobar aquests identificadors és força complex i es descriu a les pàgines 51 a 54 del document "Book of iButton Standards", que és un document pdf a https://pdfserv.maximintegrated.com/en/an/AN937.pd …

He provat aquest procés de cerca amb 1 a 11 sensors en un sol bus i he trobat que l’ordre de resposta per a un determinat conjunt de dispositius sempre era el mateix, però quan he afegit un dispositiu nou al final del bus no hi havia manera Podria predir on apareixerà en l'ordre de cerca. Per exemple, l’11è sensor que he afegit va arribar a la posició número 5; i el primer sensor que vaig posar a l'autobús va ser sempre l'últim en l'ordre de cerca.

En aquest projecte amb dos sensors, un d’ells està soldat al mòdul RTC; l'altre està endollat mitjançant una capçalera masculina al tauler i una capçalera femenina al cable. Es pot desprendre fàcilment.

Quan el sensor del cable (el sensor "out") es desconnecta, l'ordre "search" produeix alternatius "TRUE" i "FALSE".

Quan el sensor del cable està connectat, l'ordre "cerca" produeix un cicle de 3 etapes, amb dos "TRUE" i un "FALSE".

El meu procediment consisteix a emetre 1, 2 o 3 ordres de "cerca" fins que es retorni un resultat FALS. Llavors emet dues ordres més de "cerca". Si el segon falla (és a dir, FALS) sé que només hi ha un sensor al bus i que és el sensor "in". La identitat del dispositiu es registra i s'assigna al sensor "in".

Més endavant, si el primer i el segon retorn són TRUE, sé que hi ha dos sensors al bus. Comprovo quin d'ells té una identitat igual al sensor "in" i assigno l'altre com a sensor "out".

L'altre punt menor és que la recopilació dels resultats dels dos sensors es fa enviant la "conversió d'inici" mitjançant el que es coneix com a ordre "saltar ROM". Tenim l’opció d’enviar ordres a un sol dispositiu (mitjançant el seu identificador únic) o a tots els dispositius del bus (saltar ROM). El codi té aquest aspecte:

ds.reset (); //

// enviar l'ordre "ometre ROM" (per tant, l'ordre següent funciona en tots dos sensors) ds.write (0xCC); // Omet la comanda ROM ds.write (0x44, 0); // iniciar la conversió en ambdues sondes state_stat = wait_convert; // anar a retardar l'estat

Quan ha passat el temps de retard requerit, les temperatures es reben de cada sensor individualment. Aquí teniu el codi del segon sensor (és a dir, el sensor OUT).

if (bandera2) {

present = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Llegiu el bloc de notes de dades de sonda "fora" [0] = ds.read (); dades [1] = ds.read (); temperature_out = (dades [1] << 8) + dades [0]; temperature_out = (6 * temperature_out) + temperature_out / 4; // multiplica per 6,25} else {// not flag2 - ie Sensor de sortida no connectat temperature_out = 30000; // fixa a 300,00 C si el sensor de temperatura no funciona} // final de if (flag2)

Vaig treballar la major part d’aquest programari en un esbós autònom que només contenia els sensors de temperatura, sense les complicacions del suport de les targetes LCD, RTC i SD. Aquest esbós de desenvolupament es troba al fitxer següent.

Pas 3: Resultats preliminars

Aquest gràfic és una combinació dels dos primers dies parcials de lectures.