2 Sensörlü DIY Günlük Termometresi: 3 Adım (Resimlerle)

2024 Yazar: John Day | [email protected]. Son düzenleme: 2024-01-30 13:18

Bu proje, bir önceki projem olan "DIY Logging Thermometer"ın geliştirilmiş halidir. Sıcaklık ölçümlerini bir mikro SD karta kaydeder.

Donanım değişiklikleri

Bu cihaz için baskılı devre kartında provizyon bulunan gerçek zamanlı saat modülüne bir DS18B20 sıcaklık sensörü ekledim; ve RTC'nin "DS" pininden Arduino'nun D2'sine uygun kabloyu ekledi.

Yazılım değişiklikleri

Sonra yazılımı ekledim ve değiştirdim. Ana değişiklikler şunlardır:

LCD ekran "In" ve "Out" olmak üzere iki sıcaklık gösterir.

SD karta kaydedilen günlük dosyaları, "sıcaklık Girişi" ve "Sıcaklık Çıkışı" olmak üzere iki sıcaklık alanına sahiptir.

SD kartta daha uzun kayıt olduğu için EEPROM için çalışma arabellekleri daha büyüktü ve bunun sonucunda hafıza çakışması sorunları yaşamaya başladım. String nesnesi yerine tüm dizeler için karakter dizileri kullanmak da dahil olmak üzere, dinamik bellek kullanımını azaltmaya yönelik bir dizi değişiklik yaptım.

Yazılımın sıcaklıkları alan kısmı, çoğu hangi probun "içeride" ve hangisinin "dışarıda" olduğunu belirlemekle ilgili olan büyük değişikliklere sahiptir. Bu tanımlama çoğunlukla otomatiktir. Herhangi bir nedenle sondalar değiştirilirse, "çıkış" sondasının fişini çekip tekrar takarak düzeltilebilir. Bu geri dönüşü kendim yaşamadım. Programcı veya kullanıcının sensör adreslerini girmesine gerek yoktur, yazılım sıcaklık sensörü adreslerini kendisi keşfeder.

Yaptığım testlere göre, sıcaklık problarının tanımlanması ve SD kartın çıkarılması ve değiştirilmesine verilen yanıt hala sorunsuz çalışıyor.

Adım 1: Yazılım Geliştirme

Bu adım size tamamlanmış proje için tam yazılımı verir. Arduino IDE 1.6.12 kullanarak derledim. 21.400 bayt program belleği (%69) ve 1.278 bayt dinamik bellek (%62) kullanır.

Neler olup bittiğini netleştireceğini umarak koda yorumlar koydum.

Adım 2: İki Sıcaklık Sensörüyle Çalışma - Ayrıntılar

Bu yazılım "OneWire" kitaplığını kullanır. Herhangi bir "DallasTemperature" veya benzeri kitaplıklar kullanmaz. Bunun yerine sıcaklık sensörlerine gelen komutlar ve veriler taslak tarafından yapılır ve oldukça kolay bir şekilde görülebilir ve anlaşılabilir. OneWire kitaplığı komutlarının yararlı bir listesini şu adreste buldum:

www.pjrc.com/teensy/td_libs_OneWire.html

İki (veya daha fazla) sıcaklık sensörü olduğunda hangisinin hangisi olduğunu belirlemek gerekir.

Ekran modülünde normalde "içeride" olan bir sensöre ve diğer tarafa takılabilmesi için bir kablo üzerindeki diğer sensöre sahip ticari ünitelerin tipik özelliği olan iki sensörümü "içeri" ve "dışarı" olarak adlandırdım. bir dış duvarın ve dolayısıyla "dışarıda" olun.

Farklı probları tanımlamaya yönelik genel yaklaşım, cihaz adreslerini keşfetmek ve bunları bir tanımlayıcı etiketle birlikte yazılıma koymaktır. Gördüğüm diğer tüm projeler, DallasTemperature kitaplığını kullansalar da kullanmasalar da bu yaklaşımı kullanıyor.

Niyetim, yazılımın sensörleri otomatik olarak tanımlaması ve bunları "giriş" ve "çıkış" olarak doğru bir şekilde tahsis etmesiydi. Bunları ayrı Arduino pinlerine koyarak bunu yapmak yeterince kolaydır. Bu projede A0'dan A3'e ve A6 ve A7'nin tümü kullanılmamıştır, dolayısıyla bu durumda bunlardan biri kullanılmış olabilir. Ancak, aynı OneWire veri yolundaki sensörlerle otomatik tanımlama çalışmasını sağlamayı başardım.

Bu şekilde çalışır.

OneWire kitaplığında "OneWireObject.search(address)" komutu vardır; burada "adres" 8 baytlık bir dizidir ve "OneWireObject", OneWire nesnesinin önceden oluşturulmuş bir örneğinin adıdır. İstediğiniz herhangi bir isim olabilir. Benimki "ds" olarak adlandırılıyor. Bu "arama" komutunu verdiğinizde, OneWire kitaplığı tek kablolu veri yolunda bazı sinyaller yapar. Yanıt veren bir sensör bulursa, "DOĞRU" bir boole değeri döndürür ve "adres" dizisini sensörün 8 bayt benzersiz tanımlayıcısıyla doldurur. Bu tanımlayıcı, bir aile kodu (başlangıçta) ve bir kontrol toplamı (sonda) içerir. Arada, sensörü ailesi içinde benzersiz şekilde tanımlayan 6 bayt bulunur.

Bu komut her verildiğinde, OneWire veri yolundaki tüm aygıtlar arasında dolaşarak bir sonuç (adres ve dönüş DOĞRU) elde edilir. Her cihaz yanıt verdiğinde, bir sonraki "arama" yayınlandığında, dönüş "YANLIŞ" olur ve bu, veri yolundaki her cihazın zaten yanıt verdiğini gösterir. "Arama" tekrar yapılırsa, ilk cihaz tekrar yanıt verir - ve bu, süresiz olarak devam eder. Cihazlar her zaman aynı sırayla yanıt verir. Yanıtların sırası, OneWire veri yolundaki cihazların tanımlayıcılarına dayanır. Cihaz tanımlayıcılarının en az anlamlı bitlerinden başlayan ikili bir arama gibi görünüyor. Bu tanımlayıcıları bulmak için kullanılan protokol oldukça karmaşıktır ve https://pdfserv.maximintegrated.com/en/an/AN937.pd adresinde bir pdf belgesi olan "Book of iButton Standards" belgesinin 51 - 54. sayfalarında açıklanmıştır. …

Bu arama işlemini tek bir veriyolu üzerinde 1'den 11'e kadar sensörle test ettim ve belirli bir cihaz grubu için yanıt sırasının her zaman aynı olduğunu buldum, ancak veri yolunun sonuna yeni bir cihaz eklediğimde hiçbir yolu yoktu. Arama sırasında nerede görüneceğini tahmin edebilirim. Örneğin eklediğim 11. sensör 5 No'lu pozisyonda geldi; ve otobüse koyduğum ilk sensör arama sıralamasında sonuncuydu.

İki sensörlü bu projede bunlardan biri RTC modülü üzerinde yerinde lehimlenmiştir; diğeri ise kart üzerinde bir erkek başlık ve kablo üzerinde bir dişi başlık kullanılarak takılır. Kolayca ayrılabilir.

Kablo üzerindeki sensör ("dışarı" sensörü) ayrıldığında, "arama" komutu dönüşümlü "DOĞRU" ve "YANLIŞ" dönüşleri üretir.

Kablo üzerindeki sensör takıldığında, "ara" komutu, iki "DOĞRU" ve bir "YANLIŞ" dönüşlü 3 aşamalı bir döngü üretir.

Benim prosedürüm, bir YANLIŞ sonucu döndürülene kadar 1, 2 veya 3 "arama" komutu vermektir. Sonra 2 tane daha "ara" komutu veririm. İkincisi başarısız olursa (yani YANLIŞ) Bus'ta sadece bir sensör olduğunu ve bunun "iç" sensörü olduğunu biliyorum. Cihaz kimliği kaydedilir ve "in" sensörüne atanır.

Daha sonra, hem birinci hem de ikinci dönüşler DOĞRU ise, otobüste iki sensör olduğunu biliyorum. Hangisinin "in" sensörüne eşit bir kimliğe sahip olduğunu kontrol ediyorum ve diğerini "out" sensörü olarak tahsis ediyorum.

Diğer küçük nokta, iki sensörden gelen sonuçların toplanmasının, "ROM atla" komutu olarak bilinen "dönüştürmeyi başlat" göndererek yapılmasıdır. Komutları tek bir cihaza (benzersiz tanımlayıcısını kullanarak) veya veri yolu üzerindeki tüm cihazlara (ROM atla) gönderme seçeneğine sahibiz. Kod şöyle görünür:

ds.reset(); //

// "ROM atla" komutunu gönder (sonraki komut her iki sensörde de çalışır) ds.write(0xCC); // ROM komutunu atla ds.write(0x44, 0); // her iki probda da dönüştürmeyi başlat sıcaklık_durumu = wait_convert; // gecikme durumuna git

Gerekli gecikme süresi geçtiğinde, sıcaklıklar her sensörden ayrı ayrı alınır. İşte ikinci sensörün kodu (yani ÇIKIŞ sensörü).

if (bayrak2) {

mevcut = ds.reset(); ds.select(DS18B20_addr_out); ds.write(0xBE); // "Çıkış" prob verilerinin Not Defteri'ni oku[0] = ds.read(); veri[1] = ds.read(); sıcaklık_çıkışı = (veri[1] << 8) + veri[0]; sıcaklık_çıkış = (6 * sıcaklık_çıkış) + sıcaklık_çıkış / 4; // 6,25 ile çarpın } else { // flag2 değil - yani Çıkış sensörü bağlı değil sıcaklık_çıkış = 30000; // sıcaklık sensörü çalışmıyorsa 300,00 C'de sabitleyin } // if'nin sonu (flag2)

Bu yazılımın çoğunu, LCD, RTC ve SD kart desteği komplikasyonları olmadan, içinde sıcaklık sensörleri olan bağımsız bir taslakta çalıştım. Bu geliştirme taslağı aşağıdaki dosyadadır.

Adım 3: Ön Sonuçlar

Bu çizelge, okumaların ilk iki yarı gününün bir birleşimidir.