წვრილმანი თერმომეტრი 2 სენსორით: 3 ნაბიჯი (სურათებით)

2024 ავტორი: John Day | [email protected]. ბოლოს შეცვლილი: 2024-01-30 10:17

ეს პროექტი არის ჩემი წინა პროექტის "წვრილმანი შესვლის თერმომეტრის" გაძლიერება. ის აკავშირებს ტემპერატურის გაზომვებს მიკრო SD ბარათზე.

აპარატურის ცვლილებები

მე დავამატე DS18B20 ტემპერატურის სენსორი რეალურ დროში საათის მოდულში, სადაც ამ მოწყობილობის დაბეჭდილი მიკროსქემის დაფაზე არის მითითება; და დაამატა შესაბამისი მავთული RTC "DS" პინიდან არდუინოს D2- ში.

პროგრამული ცვლილებები

შემდეგ დავამატე და შევცვალე პროგრამული უზრუნველყოფა. ძირითადი ცვლილებებია:

LCD ეკრანი აჩვენებს ორ ტემპერატურას "In" და "Out".

SD ბარათზე ჩაწერილი ჟურნალის ფაილებს აქვთ ორი ტემპერატურის ველი, "ტემპერატურა შიგნით" და "ტემპერატურა გარეთ".

SD ბარათზე უფრო გრძელი ჩანაწერის გამო, EEPROM– ის სამუშაო ბუფერები უფრო დიდი იყო და ამის შედეგად დავიწყე მეხსიერების კონფლიქტის პრობლემები. მე შევიტანე მთელი რიგი ცვლილებები, რომლებიც მიზნად ისახავდა დინამიური მეხსიერების გამოყენების შემცირებას, მათ შორის სიმბოლოთა მასივების გამოყენებას ყველა სტრიქონისთვის სიმებიანი ობიექტის ნაცვლად.

პროგრამული უზრუნველყოფის იმ ნაწილს, რომელიც ტემპერატურას იძენს, აქვს ძირითადი ცვლილებები, რომელთა უმეტესობა დაკავშირებულია იდენტიფიკაციასთან, რომელი ზონდი არის „შიგნით“და რომელი „გარეთ“. ეს იდენტიფიკაცია ძირითადად ავტომატურია. თუ რაიმე მიზეზით გამოძიება გადართულია, ის შეიძლება გამოსწორდეს "out" ზონდის გამორთვით და შემდეგ ისევ ჩართვით. მე თვითონ არ განმიცდია ეს შემობრუნება. პროგრამისტს ან მომხმარებელს არ სჭირდება სენსორის მისამართების ჩაწერა, პროგრამული უზრუნველყოფა თავისთავად აღმოაჩენს ტემპერატურის სენსორის მისამართებს.

ჩემ მიერ ჩატარებული ტესტირების თანახმად, ტემპერატურის ზონდების იდენტიფიცირება და 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 ობიექტის მაგალითის სახელი, რომელიც ადრე შეიქმნა. მას შეიძლება ჰქონდეს ნებისმიერი სახელი, რომელიც მოგწონთ. ჩემსას ჰქვია "დს". როდესაც თქვენ გასცემთ ამ "ძებნის" ბრძანებას, OneWire ბიბლიოთეკა ახდენს სიგნალიზაციას ერთი მავთულის ავტობუსზე. თუ ის აღმოაჩენს საპასუხო სენსორს, ის აბრუნებს "TRUE" ლოგიკურ მნიშვნელობას და ავსებს "მისამართის" მასივს სენსორის 8 ბაიტიანი უნიკალური იდენტიფიკატორით. ეს იდენტიფიკატორი მოიცავს ოჯახის კოდს (დასაწყისში) და გამშვებ თანხას (დასასრულს). მათ შორის არის 6 ბაიტი, რომელიც ცალსახად განსაზღვრავს სენსორს მის ოჯახში.

ერთი შედეგი (მისამართი და დაბრუნება TRUE) მიიღება ყოველ ჯერზე, როდესაც ეს ბრძანება მოცემულია, ველოსიპედით ყველა მოწყობილობაზე OneWire ავტობუსში. მას შემდეგ, რაც ყველა მოწყობილობა გამოეხმაურა, შემდეგ ჯერზე "ძებნა" გაიცემა, დაბრუნება არის "FALSE", რაც მიუთითებს ავტობუსში მყოფი ყველა მოწყობილობის რეაგირებაზე. თუ "ძებნა" კვლავ გაიცემა, პირველი მოწყობილობა კვლავ პასუხობს - და ასე უსასრულოდ. მოწყობილობები ყოველთვის ერთნაირი თანმიმდევრობით რეაგირებენ. პასუხების თანმიმდევრობა ემყარება მოწყობილობების იდენტიფიკატორებს OneWire ავტობუსში. როგორც ჩანს, ეს არის ორობითი ძებნა, რომელიც იწყება მოწყობილობის იდენტიფიკატორების უმნიშვნელო ბიტიდან. პროტოკოლი, რომელიც გამოიყენება ამ იდენტიფიკატორების მოსაძებნად, საკმაოდ რთულია და აღწერილია დოკუმენტის 51-54 გვერდებზე "Book of iButton Standards", რომელიც არის pdf დოკუმენტი https://pdfserv.maximintegrated.com/en/an/AN937.pd …

მე შევამოწმე ეს ძებნის პროცესი 1 -დან 11 სენსორამდე ერთ ავტობუსზე და აღმოვაჩინე, რომ მოწყობილობების მოცემული ნაკრების საპასუხო ბრძანება ყოველთვის ერთნაირი იყო, მაგრამ როდესაც ავტობუსის ბოლოს დავამატე ახალი მოწყობილობა, გზა არ იყო მე შემიძლია ვიწინასწარმეტყველო, თუ სად გამოჩნდება საძიებო სისტემაში. მაგალითად, მე -11 სენსორი, რომელიც მე დავამატე, მოვიდა No5 პოზიციაზე; პირველი სენსორი, რომელიც ავტობუსში ჩავდე, ბოლო იყო ძებნის წესრიგში.

ამ პროექტში ორი სენსორით, ერთი მათგანი გამყარებულია ადგილზე RTC მოდულზე; მეორე არის ჩართული გამოყენებით მამრობითი header დაფაზე და ქალი header კაბელზე. მისი ადვილად მოშორება შესაძლებელია.

როდესაც სენსორი კაბელზე ("გარეთ" სენსორი) იშლება, "ძებნის" ბრძანება იძლევა ალტერნატიულ "TRUE" და "FALSE" ბრუნებს.

როდესაც საკაბელო სენსორი მიმაგრებულია, "ძებნის" ბრძანება აწარმოებს 3 საფეხურიან ციკლს, ორი "TRUE" და ერთი "FALSE" ბრუნდება.

ჩემი პროცედურაა 1, 2 ან 3 "ძებნის" ბრძანების გაცემა, სანამ FALSE შედეგი არ დაბრუნდება. შემდეგ მე ვაძლევ კიდევ 2 "ძებნის" ბრძანებას. თუ მეორე ვერ მოხერხდა (ანუ FALSE) მე ვიცი რომ ავტობუსში არის მხოლოდ ერთი სენსორი და ის არის "in" სენსორი. მოწყობილობის იდენტურობა ჩაწერილია და გამოყოფილია "in" სენსორზე.

მოგვიანებით, თუ ორივე პირველი და მეორე დაბრუნება არის ჭეშმარიტი, მე ვიცი, რომ ავტობუსში არის ორი სენსორი. მე ვამოწმებ, რომელი მათგანს აქვს „in“სენსორის ტოლი იდენტურობა და მეორეს გამოვყოფ, როგორც „out“სენსორს.

მეორე უმნიშვნელო პუნქტი არის ის, რომ ორი სენსორის შედეგების შეგროვება ხდება "კონვერტაციის დაწყების" გაგზავნით, რასაც ეწოდება "გამოტოვეთ ROM" ბრძანება. ჩვენ გვაქვს შესაძლებლობა გაგზავნოთ ბრძანებები ერთ მოწყობილობაზე (მისი უნიკალური იდენტიფიკატორის გამოყენებით) ან ავტობუსის ყველა მოწყობილობაზე (გამოტოვეთ ROM). კოდი ასე გამოიყურება:

ds.reset (); //

// გაგზავნეთ "გამოტოვეთ ROM" ბრძანება (ასე რომ, შემდეგი ბრძანება მუშაობს ორივე სენსორში) ds.write (0xCC); // გამოტოვეთ ROM ბრძანება ds.write (0x44, 0); // კონვერტაციის დაწყება ორივე ზონდის ტემპერატურის_სახელმწიფოში = ლოდინის_კონვერტირება; // გადადით მდგომარეობის გადადებაზე

როდესაც საჭირო შეფერხების დრო გავიდა, ტემპერატურა მიიღება თითოეული სენსორისგან ინდივიდუალურად. აქ არის კოდი მეორე სენსორისთვის (ანუ OUT სენსორი).

თუ (დროშა 2) {

აწმყო = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // "out" ზონდის მონაცემების Scratchpad- ის წაკითხვა [0] = ds.read (); მონაცემები [1] = ds.read (); ტემპერატურა_ გარეთ = (მონაცემი [1] << 8) + მონაცემი [0]; ტემპერატურის_გარე = (6 * ტემპერატურა_გამოშვება) + ტემპერატურა_გარე / 4; // გავამრავლოთ 6.25} სხვაზე {// არა flag2 - ანუ გამომავალი სენსორი არ არის დაკავშირებული temperature_out = 30000; // დაფიქსირება 300.00 C ტემპერატურაზე, თუ ტემპერატურის სენსორი არ მუშაობს} // if- ის დასასრული (flag2)

მე შევიმუშავე პროგრამული უზრუნველყოფის უმეტესი ნაწილი დამოუკიდებელ ესკიზში, რომელშიც მხოლოდ ტემპერატურის სენსორები იყო, LCD, RTC და SD ბარათების მხარდაჭერის გართულებების გარეშე. განვითარების ესკიზი მოცემულია ქვემოთ მოცემულ ფაილში.

ნაბიჯი 3: წინასწარი შედეგები

ეს სქემა არის წაკითხვის პირველი ორი ნაწილის დღის კომბინაცია.