Направи си сам термометър за регистриране с 2 сензора: 3 стъпки (със снимки)

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:51

Този проект е подобрение на моя предишен проект "Термометър за регистриране" направи си сам ". Той регистрира измерванията на температурата на микро SD карта.

Хардуерни промени

Добавих температурен сензор DS18B20 към модула за часовник в реално време, където на печатната платка е предвидено това устройство; и добави съответния проводник от "DS" щифта на RTC към D2 на Arduino.

Промени в софтуера

След това добавих и модифицирах софтуера. Основните промени са:

LCD дисплеят показва две температури "In" и "Out".

Регистрационните файлове, записани на SD картата, имат две температурни полета, "temperature In" и "temperature Out".

Поради по -дългия запис на SD картата, работните буфери за EEPROM бяха по -големи и в резултат на това започнах да имам проблеми с конфликта на паметта. Направих редица промени, насочени към намаляване на използването на динамична памет, включително използване на символни масиви за всички низове вместо String обект.

Частта от софтуера, която получава температурите, има големи модификации, голяма част от които са свързани с идентифицирането коя сонда е "в" и коя е "навън". Тази идентификация е предимно автоматична. Ако по някаква причина сондите се превключат, това може да бъде коригирано, като изключите „изходната“сонда и след това я включите отново. Аз самият не съм преживявал този обрат. Програмистът или потребителят не трябва да въвеждат адресите на сензора, софтуерът сам открива адресите на сензора за температура.

Според тестовете, които направих, идентифицирането на температурните сонди и отговорът при премахване и подмяна на SD картата все още работят безпроблемно.

Стъпка 1: Разработка на софтуер

Тази стъпка ви дава пълния софтуер за завършения проект. Съставих го с помощта на Arduino IDE 1.6.12. Той използва 21, 400 байта програмна памет (69%) и 1,278 байта динамична памет (62%).

Поставих коментари в кода с надеждата да стане ясно какво се случва.

Стъпка 2: Работа с два температурни сензора - подробности

Този софтуер използва библиотеката "OneWire". Той не използва никакви "DallasTemperature" или подобни библиотеки. Вместо това командите и данните от температурните сензори се изпълняват от скицата и могат да се видят и разберат доста лесно. Намерих полезен списък с командите на библиотеката на OneWire на адрес

www.pjrc.com/teensy/td_libs_OneWire.html

Когато има два (или повече) температурни сензора, става необходимо да се определи кой е кой.

Извиках двата си сензора „входящ“и „външен“, което е типично за търговските единици, които имат сензор в модула на дисплея, който обикновено е „вътре“, а другия сензор на кабел, така че да може да бъде поставен от другата страна на външна стена и по този начин да бъде „отвън“.

Обичайният подход за идентифициране на различните сонди е да се открият адресите на устройството и да се поставят в софтуера заедно с идентификационен етикет. Всички други проекти, които съм виждал, използват този подход, независимо дали използват библиотеката DallasTemperature или не.

Намерението ми беше софтуерът да идентифицира автоматично сензорите и правилно да ги разпредели за „вход“и „изход“. Това е достатъчно лесно да се направи, като се поставят на отделни щифтове на Arduino. В този проект A0 до A3 и A6 и A7 са неизползвани, така че един от тях може да се използва в този случай. Успях обаче автоматичната идентификация да работи със сензорите и на една и съща шина на OneWire.

Работи по този начин.

Библиотеката на OneWire има команда „OneWireObject.search (адрес)“, където „адрес“е масив от 8 байта, а „OneWireObject“е името на екземпляр на обект OneWire, който е създаден преди това. Може да има всяко име, което харесвате. Моят се нарича "ds". Когато подадете тази команда "търсене", библиотеката на OneWire прави известна сигнализация по едножичната шина. Ако намери реагиращ сензор, той връща булева стойност "TRUE" и попълва масива "address" с 8 -байтовия уникален идентификатор на сензора. Този идентификатор включва семеен код (в началото) и чекова сума (в края). Между тях са 6 байта, които уникално идентифицират сензора в неговото семейство.

При всеки подаване на тази команда се получава един резултат (адрес и връщане TRUE), преминавайки през всички устройства на шината на OneWire. След като всяко устройство е отговорило, при следващото издаване на „търсене“връщането е „FALSE“, което показва, че всяко устройство в шината вече е отговорило. Ако „търсенето“се издаде отново, първото устройство реагира отново - и така безкрайно. Устройствата винаги реагират в същия ред. Редът на отговорите се основава на идентификаторите на устройствата в шината на OneWire. Изглежда, че това е двоично търсене, започващо от най -малко значимите битове от идентификаторите на устройството. Протоколът, използван за намиране на тези идентификатори, е доста сложен и е описан на страници 51 - 54 от документ "Книга на стандартите на iButton", който е pdf документ на адрес https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Тествах този процес на търсене с от 1 до 11 сензора на една шина и установих, че редът на отговор за даден набор от устройства винаги е един и същ, но когато добавих ново устройство в края на шината, нямаше начин Мога да предвидя къде в реда за търсене ще се появи. Например 11 -ият сензор, който добавих, влезе в позиция № 5; и първият сензор, който пуснах в автобуса, беше последният в реда за търсене.

В този проект с два сензора, един от тях е запоен на място върху RTC модула; другият е включен с помощта на мъжка заглавка на дъската и женска на кабела. Може лесно да се отдели.

Когато сензорът на кабела (сензорът "out") се отдели, командата "search" произвежда редуващи се връщания "TRUE" и "FALSE".

Когато сензорът на кабела е свързан, командата "търсене" произвежда тристепенен цикъл, с две "TRUE" и едно "FALSE" връщане.

Моята процедура е да издам 1, 2 или 3 команди за „търсене“, докато не се върне НЕВЯРЕН резултат. След това издавам още 2 команди за „търсене“. Ако вторият се провали (т.е. FALSE) Знам, че има само един сензор в шината и че това е сензорът "in". Идентичността на устройството се записва и разпределя към сензора "in".

По -късно, ако и първото, и второто връщане са ИСТИНСКИ, знам, че има два сензора в шината. Проверявам кой от тях има идентичност, равна на "in" сензора, и разпределям другия като "out" сензор.

Другият незначителен момент е, че събирането на резултатите от двата сензора се извършва чрез изпращане на „стартиране на преобразуването“чрез това, което е известно като „пропуснете ROM“команда. Имаме възможност да изпращаме команди до едно устройство (използвайки неговия уникален идентификатор) или до всички устройства в шината (пропуснете ROM). Кодът изглежда така:

ds.reset (); //

// изпраща команда „skip ROM“(така че следващата команда работи и в двата сензора) ds.write (0xCC); // Пропускане на ROM команда ds.write (0x44, 0); // стартиране на преобразуването в двете сонди temperature_state = wait_convert; // отидете в състояние на забавяне

Когато изтече необходимото време на забавяне, температурите се получават от всеки сензор поотделно. Ето кода за втория сензор (т.е. сензорът OUT).

if (flag2) {

present = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Прочетете Scratchpad на "out" данни от сондата [0] = ds.read (); данни [1] = ds.read (); temperature_out = (данни [1] << 8) + данни [0]; temperature_out = (6 * temperature_out) + temperature_out / 4; // умножаваме по 6.25} иначе {// не флаг2 - т.е. изходният сензор не е свързан temperature_out = 30000; // поправя се при 300.00 C, ако сензорът за температура не работи} // край на if (flag2)

Разработих по-голямата част от този софтуер в самостоятелна скица, в която имаше само температурни сензори, без усложненията от поддръжката на LCD, RTC и SD карти. Тази скица за развитие е във файла по -долу.

Стъпка 3: Предварителни резултати

Тази диаграма е комбинация от първите два непълни дни на четене.