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

מה התפספס?

התכנון המקורי ניסה למצוא איזון בין הדרישות של מספר מודולים פנימיים של המיקרו-בקר: ה-DAC, ה-UART, ה-AC, ה-ADC, רפרנס המתח הפנימי ומיפוי הפינים. בכל התסריטים שהגעתי אליהם, הרעיון היה שהלד של חיישן הקירבה יהיה בשליטה כפולה (לא בו-זמנית): של ה-DAC עם רפרנס 2.5V לשימוש שוטף, ושל ה-UART TX לשידור נתונים במקרה הצורך.

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

כיווני פתרון

דרך אחת לצאת מהבוץ היא באמצעות רכיבים נוספים במעגל, שיקחו על עצמם חלק מהתפקידים שהמיקרו-בקר לא יכול לנהל בעצמו. מייצב מתח ל-3V, נניח, בשביל להאחיד את כל אופני הפלט על פני כל מתחי המערכת, ומגבר שרת להשוואת מתחים כדי שקליטת שידורים לא תהיה תלויה ב-AC הפנימי ובמגבלות הפינים שהוא מציב. זה כנראה יעבוד, אבל המשמעות היא לוח מורכב, יקר וצפוף הרבה יותר.

אופציה שנייה היא "לחתוך" את ה-TX שהוא המקור לכל הצרות, ובמקום להסתמך על UART החומרה, לייצר לבד שידור בתוכנה, באמצעות שינוי פלט ה-DAC! כך אפשר לוותר על הרכיבים החיצוניים, להשיג אחידות במתחים בלי לוותר על הרפרנס, וגם לשלוט בלד דרך פין יחיד במקום שניים. מהניסויים המקדימים כבר ידעתי שקצב השידור הרלוונטי הוא 2400 באוד לכל היותר, וה-DAC יכול בהחלט לעמוד בזה. ניסוי קטן עם טיימר פנימי הראה שהמיקרו-בקר יכול להפיק בקלות פלט "דיגיטלי" 0/2.5V נקי, עם זמני עלייה וירידה של מיליוניות שנייה בודדות, באמצעות ה-DAC, בקצב שמתאים לשידור UART איטי. אם כן, אפשר להמשיך לכתוב את הקוד שמשדר "חבילות" בייטים שלמות ב-UART התוכנה הזה, ואז לצרף את שאר חלקי הפאזל.

פרוטוקול

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

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

באופן כללי, אפשר ליצור פרוטוקול שמתייחס לכל פרמטר בנפרד (למשל, לשלוח פקודת "שנה ערך" + אינדקס הפרמטר + הערך הרצוי), או פרוטוקול שמשדר/קולט את כולם ביחד ("שנה ערכים" + ערך פרמטר 1 + ערך פרמטר 2 + …) הסוג ראשון מתאים למצבים בהם יש הרבה פרמטרים ושכל אחד מהם עשוי להשתנות בלי תלות באחרים, או כשצפויים עדכוני תוכנה שישנו את סוגי הפרמטרים עצמם בעתיד, או כשתקשורת היא "יקרה" (למשל צורכת הרבה זרם במערכת מופעלת בסוללה). במקרה הספציפי שלי מתקיים רק תנאי אחד מבין השלושה, אז אני נוטה לפרוטוקול "הכול בבת אחת".

מה עכשיו?

אחרי שבדיקות על המטריצה הוכיחו את ההיתכנות העקרונית של הרעיון שלי, תכננתי ושלחתי לייצור לוחות PCB כדי להכין מודולים פונקציונליים לשימוש, או לפחות לבדיקה מעמיקה, בשטח. ה-PCB תוכנן לפי מידות ו-pinout של מודולי חיישנים אחרים שקיימים בשוק, כדי שהמודול שלי יוכל להחליף אותם בקלות – או להיפך, כדי שאם תתגלה בעיה במודולים שלי, אפשר יהיה להחליף אותם במודולים הקנויים והיקרים-יותר.

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