מד חום עצים DIY עם 2 חיישנים: 3 שלבים (עם תמונות)

2024 מְחַבֵּר: John Day | [email protected]. שונה לאחרונה: 2024-01-30 09:13

פרויקט זה הוא שיפור של הפרויקט הקודם שלי "מדחום עצים עצים". הוא רושם את מדידות הטמפרטורה לכרטיס מיקרו SD.

שינויים בחומרה

הוספתי חיישן טמפרטורה DS18B20 למודול השעון בזמן אמת, שבו ישנה הורדה על הלוח המודפס למכשיר זה; והוסיף את החוט המתאים מהפין "DS" של RTC ל- D2 של הארדואינו.

שינויי תוכנה

לאחר מכן הוספתי ושיניתי את התוכנה. השינויים העיקריים הם:

צג ה- LCD מציג שתי טמפרטורות "In" ו- "Out".

לקבצי היומן שנרשמו בכרטיס ה- SD יש שני שדות טמפרטורה, "טמפרטורה פנימה" ו"טמפרטורת החוצה ".

בגלל הרישום הארוך יותר בכרטיס ה- SD, מאגרי העבודה של ה- EEPROM היו גדולים יותר וכתוצאה מכך התחילו לי בעיות עימות בזיכרון. ביצעתי מספר שינויים שמטרתם להפחית את השימוש בזיכרון דינאמי, כולל שימוש במערכי תווים עבור כל המחרוזות במקום באובייקט מחרוזת.

בחלק התוכנה שמקבלת את הטמפרטורות יש שינויים משמעותיים, שחלק גדול מהם קשור לזהות איזו בדיקה "נכנסת" ואיזה "בחוץ". זיהוי זה הוא לרוב אוטומטי. אם מסיבה כלשהי הופכים את הגשושיות, ניתן לתקן זאת על ידי ניתוק הבורד החוצה ולאחר מכן חיבור חזרה. לא חוויתי את ההיפוך הזה בעצמי. המתכנת או המשתמש אינם צריכים להקליד את כתובות החיישן, התוכנה מגלה את כתובות חיישן הטמפרטורה מעצמה.

על פי הבדיקות שעשיתי, זיהוי בדיקות הטמפרטורה והתגובה להסרה והחלפה של כרטיס ה- 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

כאשר ישנם שני חיישני טמפרטורה (או יותר), יש צורך לזהות איזה מהם הוא.

קראתי לשני החיישנים שלי "in" ו- "out", האופייניים ליחידות מסחריות שיש בהן חיישן במודול התצוגה שהוא בדרך כלל "בפנים", ולחיישן השני בכבל כך שניתן לשים אותו בצד השני של קיר חיצוני וכך להיות "בחוץ".

הגישה הרגילה לזיהוי הגששים השונים היא גילוי כתובות המכשיר והכנסתן לתוכנה יחד עם תווית זיהוי. כל הפרויקטים האחרים שראיתי משתמשים בגישה זו, בין אם הם משתמשים בספריית DallasTemperature ובין אם לאו.

הכוונה שלי הייתה שהתוכנה תזהה אוטומטית את החיישנים ותקצה אותם נכון ל"כניסה "ו"חוצה". זה קל מספיק על ידי הנחתם על סיכות ארדואינו נפרדות. בפרויקט זה, A0 עד A3 ו- A6 ו- A7 כולם אינם בשימוש, כך שאפשר היה להשתמש באחד מהם במקרה זה. עם זאת הצלחתי שהזיהוי האוטומטי יעבוד עם החיישנים שניהם על אותו אוטובוס OneWire.

זה עובד ככה.

לספריית OneWire יש פקודה "OneWireObject.search (address)" כאשר "כתובת" היא מערך של 8 בתים ו- "OneWireObject" הוא שמו של מופע של אובייקט OneWire שנוצר בעבר. יכול להיות לזה כל שם שאתה אוהב. שלי נקרא "ds". כאשר אתה מוציא פקודת "חיפוש" זו, ספריית OneWire מבצעת איתות מסוים באוטובוס החוט האחד. אם הוא מוצא חיישן מגיב, הוא מחזיר ערך בוליאני "TRUE" וממלא את מערך "הכתובת" במזהה הייחודי של החיישן של 8 בתים. מזהה זה כולל קוד משפחה (בהתחלה) וסכום צ'ק (בסוף). בין לבין נמצאים 6 בתים המזהים באופן ייחודי את החיישן בתוך משפחתו.

תוצאה אחת (כתובת והחזרה TRUE) מתקבלת בכל פעם שניתן פקודה זו, תוך רכיבה על כל המכשירים באוטובוס OneWire. לאחר שכל מכשיר הגיב, בפעם הבאה שיוצא "חיפוש", ההחזרה היא "שקר", המציין שכל מכשיר באוטובוס כבר הגיב. אם "החיפוש" יוצא שוב, המכשיר הראשון מגיב שוב - וכך הלאה ללא הגבלת זמן. המכשירים תמיד מגיבים באותו סדר. סדר התגובות מבוסס על מזהי המכשירים באוטובוס OneWire. נראה כי מדובר בחיפוש בינארי המתחיל מהפיסות הפחות משמעותיות של מזהי המכשיר. הפרוטוקול המשמש לאיתור מזהים אלה הוא מורכב למדי, ומתואר בעמודים 51 - 54 במסמך "ספר תקני iButton" שהוא מסמך pdf בכתובת https://pdfserv.maximintegrated.com/en/an/AN937.pd …

בדקתי את תהליך החיפוש הזה עם 1 עד 11 חיישנים באוטובוס בודד, ומצאתי שסדר התגובה לקבוצת מכשירים נתונה תמיד זהה, אך כשהוספתי מכשיר חדש לקצה האוטובוס, לא הייתה דרך יכולתי לנבא היכן בסדר החיפוש זה יופיע. לדוגמה, החיישן ה -11 שהוספתי נכנס למיקום מס '5; והחיישן הראשון שהנחתי באוטובוס היה תמיד האחרון בסדר החיפוש.

בפרויקט זה עם שני חיישנים, אחד מהם מולחם במקומו במודול ה- RTC; השני מחובר באמצעות כותרת גברית על הלוח וכותרת נקבה בכבל. ניתן לנתק אותו בקלות.

כאשר החיישן בכבל (חיישן "החוצה") מנותק, הפקודה "חיפוש" מייצרת לסירוגין "TRUE" ו- "FALSE".

כאשר החיישן בכבל מחובר, הפקודה "חיפוש" מייצרת מחזור בן 3 שלבים, עם שני החזרות "TRUE" ואחת "FALSE".

הנוהל שלי הוא להוציא 1, 2 או 3 פקודות "חיפוש", עד להחזרת תוצאה FALSE. ואז אני מוציא עוד 2 פקודות "חיפוש". אם השני נכשל (כלומר FALSE) אני יודע שיש רק חיישן אחד באוטובוס ושהוא החיישן "in". זהות המכשיר מוקלטת ומוקצית לחיישן "in".

במועד מאוחר יותר, אם החזרה הראשונה והשנייה הן אמת, אני יודע שיש שני חיישנים באוטובוס. אני בודק למי מהם יש זהות השווה לחיישן "in", ומקצה את השני כחיישן "החוצה".

הנקודה הקטנה הנוספת היא שאיסוף התוצאות משני החיישנים נעשה על ידי שליחת "המרת התחלה" על ידי מה שמכונה פקודה "דילוג ROM". יש לנו אפשרות לשלוח פקודות למכשיר יחיד (באמצעות המזהה הייחודי שלו) או לכל המכשירים באוטובוס (דלג על ROM). הקוד נראה כך:

ds.reset (); //

// שלח פקודה "דלג על ROM" (כך שהפקודה הבאה עובדת בשני החיישנים) ds.write (0xCC); // דלג על פקודת ROM ds.write (0x44, 0); // התחל המרה בשתי הגשושיות temperature_state = wait_convert; // עבור למצב עיכוב

כאשר חלף זמן העיכוב הנדרש, הטמפרטורות מתקבלות מכל חיישן בנפרד. להלן הקוד לחיישן השני (כלומר חיישן OUT).

אם (flag2) {

present = ds.reset (); ds.select (DS18B20_addr_out); ds.write (0xBE); // קרא את לוח הגירוסים של נתוני בדיקה "החוצה" [0] = ds.read (); data [1] = ds.read (); temperature_out = (נתונים [1] << 8) + נתונים [0]; out_ temperature = (6 * temperature_out) + temperature_out / 4; // כפל ב- 6.25} אחר {// לא דגל 2 - כלומר חיישן יציאה לא מחובר temperature_out = 30000; // לתקן ב- 300.00 C אם חיישן הטמפ 'לא עובד} // סוף ה- if (flag2)

את רוב התוכנה הזו עיבדתי בסקיצה עצמאית שהיתה בה רק חיישני הטמפרטורה, ללא סיבוכים של תמיכת כרטיסי LCD, RTC ו- SD. שרטוט פיתוח זה נמצא בקובץ שלהלן.

שלב 3: תוצאות ראשוניות

תרשים זה הוא שילוב של שני הימים הראשונים של הקריאות.