Nhiệt kế ghi nhật ký tự làm với 2 cảm biến: 3 bước (có hình ảnh)

2024 Tác giả: John Day | [email protected]. Sửa đổi lần cuối: 2024-01-30 13:32

Dự án này là sự cải tiến của dự án trước đây của tôi "Nhiệt kế ghi nhật ký tự làm". Nó ghi các phép đo nhiệt độ vào thẻ micro SD.

Thay đổi phần cứng

Tôi đã thêm cảm biến nhiệt độ DS18B20 vào mô-đun đồng hồ thời gian thực, nơi có cung cấp trên bảng mạch in cho thiết bị này; và thêm dây thích hợp từ chân "DS" của RTC đến D2 của Arduino.

Thay đổi phần mềm

Sau đó, tôi thêm và sửa đổi phần mềm. Những thay đổi chính là:

Màn hình LCD hiển thị hai nhiệt độ "In" và "Out".

Các tệp nhật ký được ghi trên thẻ SD có hai trường nhiệt độ, "nhiệt độ vào" và "nhiệt độ ra".

Do bản ghi dài hơn trên thẻ SD, bộ đệm hoạt động cho EEPROM lớn hơn và do đó tôi bắt đầu gặp vấn đề xung đột bộ nhớ. Tôi đã thực hiện một số thay đổi nhằm giảm việc sử dụng bộ nhớ động, bao gồm sử dụng mảng ký tự cho tất cả các chuỗi thay vì đối tượng Chuỗi.

Phần của phần mềm lấy nhiệt độ có những sửa đổi lớn, phần lớn liên quan đến việc xác định đầu dò nào "vào" và đầu dò nào "ra". Việc nhận dạng này chủ yếu là tự động. Nếu vì lý do nào đó mà các đầu dò bị đảo lộn, có thể khắc phục bằng cách rút đầu dò "ra" và sau đó cắm lại. Bản thân tôi chưa trải qua sự đảo ngược này. Người lập trình hoặc người dùng không cần phải nhập địa chỉ cảm biến, phần mềm sẽ tự phát hiện ra địa chỉ cảm biến nhiệt độ.

Theo thử nghiệm mà tôi đã thực hiện, việc xác định các đầu dò nhiệt độ và phản ứng khi tháo và thay thế thẻ SD, vẫn hoạt động trơn tru.

Bước 1: Phát triển phần mềm

Bước này cung cấp cho bạn phần mềm đầy đủ cho dự án đã hoàn thành. Tôi đã biên dịch nó bằng Arduino IDE 1.6.12. Nó sử dụng 21, 400 byte bộ nhớ chương trình (69%) và 1, 278 byte bộ nhớ động (62%).

Tôi đã đưa các nhận xét vào mã với hy vọng sẽ làm rõ điều gì đang xảy ra.

Bước 2: Làm việc với hai cảm biến nhiệt độ - Chi tiết

Phần mềm này sử dụng thư viện "OneWire". Nó không sử dụng bất kỳ thư viện "DallasTempether" hoặc các thư viện tương tự. Thay vào đó, các lệnh và dữ liệu từ các cảm biến nhiệt độ được thực hiện bằng bản phác thảo và có thể được nhìn thấy và hiểu khá dễ dàng. Tôi đã tìm thấy một danh sách hữu ích về các lệnh thư viện OneWire tại

www.pjrc.com/teensy/td_libs_OneWire.html

Khi có hai (hoặc nhiều) cảm biến nhiệt độ, cần phải xác định cái nào là cái nào.

Tôi đã gọi hai cảm biến của mình là "vào" và "ra", đây là đặc điểm điển hình của các thiết bị thương mại có một cảm biến trong mô-đun màn hình thường là "bên trong" và cảm biến còn lại trên cáp để nó có thể được đặt ở phía bên kia của một bức tường bên ngoài và do đó là "bên ngoài".

Cách tiếp cận thông thường để xác định các đầu dò khác nhau là khám phá địa chỉ thiết bị và đưa chúng vào phần mềm cùng với nhãn nhận dạng. Tất cả các dự án khác mà tôi đã thấy đều sử dụng cách tiếp cận này, cho dù chúng có sử dụng thư viện DallasTempether hay không.

Ý định của tôi là phần mềm sẽ tự động xác định các cảm biến và phân bổ chính xác chúng cho "vào" và "ra". Điều này đủ dễ dàng để thực hiện bằng cách đặt chúng trên các chân Arduino riêng biệt. Trong dự án này, A0 đến A3 và A6 và A7 đều không được sử dụng, vì vậy một trong số này có thể đã được sử dụng trong trường hợp này. Tuy nhiên, tôi đã thành công trong việc nhận dạng tự động hoạt động với các cảm biến trên cùng một bus OneWire.

Nó hoạt động như thế này.

Thư viện OneWire có lệnh "OneWireObject.search (address)" trong đó "địa chỉ" là một mảng 8 byte và "OneWireObject" là tên của một phiên bản của đối tượng OneWire đã được tạo trước đó. Nó có thể có bất kỳ tên nào bạn thích. Của tôi được gọi là "ds". Khi bạn đưa ra lệnh "tìm kiếm" này, thư viện OneWire thực hiện một số tín hiệu trên bus một dây. Nếu nó tìm thấy một cảm biến phản hồi, nó sẽ trả về một giá trị boolean "TRUE" và điền vào mảng "địa chỉ" với số nhận dạng duy nhất 8 byte của cảm biến. Định danh này bao gồm mã gia đình (ở đầu) và tổng séc (ở cuối). Ở giữa là 6 byte xác định duy nhất cảm biến trong họ của nó.

Một kết quả (địa chỉ và trả về TRUE) nhận được mỗi khi lệnh này được đưa ra, đi vòng qua tất cả các thiết bị trên xe buýt OneWire. Khi mọi thiết bị đã phản hồi, lần tiếp theo "tìm kiếm" được đưa ra, kết quả trả về là "FALSE", cho biết mọi thiết bị trên xe buýt đã phản hồi. Nếu "tìm kiếm" được đưa ra một lần nữa, thiết bị đầu tiên sẽ phản hồi lại - và cứ tiếp tục như vậy vô thời hạn. Các thiết bị luôn đáp ứng theo cùng một thứ tự. Thứ tự phản hồi dựa trên số nhận dạng của các thiết bị trên xe buýt OneWire. Nó dường như là một tìm kiếm nhị phân bắt đầu từ các bit ít quan trọng nhất của số nhận dạng thiết bị. Giao thức được sử dụng để tìm các số nhận dạng này khá phức tạp và được mô tả trong các trang 51 - 54 của tài liệu "Sách về các tiêu chuẩn iButton", là tài liệu pdf tại https://pdfserv.maximintegrated.com/en/an/AN937.pd …

Tôi đã thử nghiệm quy trình tìm kiếm này với từ 1 đến 11 cảm biến trên một xe buýt và nhận thấy thứ tự phản hồi cho một nhóm thiết bị nhất định luôn giống nhau, nhưng khi tôi thêm một thiết bị mới vào cuối xe buýt, không có cách nào Tôi có thể dự đoán vị trí mà nó sẽ xuất hiện trong thứ tự tìm kiếm. Ví dụ, cảm biến thứ 11 mà tôi thêm vào ở vị trí số 5; và cảm biến đầu tiên tôi đặt trên xe buýt luôn là cảm biến cuối cùng trong thứ tự tìm kiếm.

Trong dự án này với hai cảm biến, một trong số chúng được hàn tại chỗ trên mô-đun RTC; cái còn lại được cắm bằng cách sử dụng đầu cắm nam trên bo mạch và đầu cắm nữ trên cáp. Nó có thể dễ dàng được tách ra.

Khi cảm biến trên cáp (cảm biến "ra") được tách ra, lệnh "tìm kiếm" sẽ trả về "TRUE" và "FALSE" luân phiên.

Khi cảm biến trên cáp được gắn vào, lệnh "tìm kiếm" tạo ra chu kỳ 3 giai đoạn, với hai lần trả về "ĐÚNG" và một "SAI".

Quy trình của tôi là đưa ra 1, 2 hoặc 3 lệnh "tìm kiếm", cho đến khi trả về kết quả FALSE. Sau đó, tôi ra thêm 2 lệnh "tìm kiếm". Nếu cái thứ hai không thành công (tức là FALSE), tôi biết chỉ có một cảm biến trên xe buýt và đó là cảm biến "trong". Nhận dạng thiết bị được ghi lại và phân bổ cho cảm biến "trong".

Vào thời điểm sau đó, nếu kết quả đầu tiên và thứ hai đều ĐÚNG, tôi biết có hai cảm biến trên xe buýt. Tôi kiểm tra xem cái nào trong số chúng có nhận dạng bằng cảm biến "vào" và phân bổ cái còn lại là cảm biến "ra".

Điểm nhỏ khác là việc thu thập kết quả từ hai cảm biến được thực hiện bằng cách gửi "bắt đầu chuyển đổi" bằng lệnh "bỏ qua ROM". Chúng tôi có tùy chọn gửi lệnh đến một thiết bị (sử dụng mã định danh duy nhất của nó) hoặc đến tất cả các thiết bị trên bus (bỏ qua ROM). Mã trông như thế này:

ds.reset (); //

// gửi lệnh "bỏ qua ROM" (vì vậy lệnh tiếp theo hoạt động trên cả hai cảm biến) ds.write (0xCC); // Bỏ qua lệnh ROM ds.write (0x44, 0); // bắt đầu chuyển đổi trong cả hai đầu dò nhiệt độ_state = wait_convert; // chuyển đến trạng thái trì hoãn

Khi thời gian trễ cần thiết trôi qua, nhiệt độ sẽ nhận được từ từng cảm biến riêng lẻ. Đây là mã cho cảm biến thứ hai (tức là cảm biến OUT).

if (flag2) {

hiện tại = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // Đọc Scratchpad của dữ liệu thăm dò "ra" [0] = ds.read (); data [1] = ds.read (); nhiệt_độ = (dữ_liệu [1] << 8) + dữ_liệu [0]; nhiệt độ ra = (6 * nhiệt độ ra) + nhiệt độ ra / 4; // nhân với 6.25} else {// không phải flag2 - tức là cảm biến Out không kết nối nhiệt độ_out = 30000; // sửa ở 300.00 C nếu cảm biến tạm thời không hoạt động} // kết thúc if (flag2)

Tôi đã phát triển hầu hết phần mềm này trong một bản phác thảo độc lập chỉ có các cảm biến nhiệt độ trong đó, không có sự hỗ trợ của LCD, RTC và thẻ SD. Bản phác thảo phát triển này nằm trong tệp bên dưới.

Bước 3: Kết quả sơ bộ

Biểu đồ này là sự kết hợp của hai bài đọc trong ngày đầu tiên.