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

הרקע

יש לי מערכת פועלת, שמבצעת לעתים קרובות העברת מידע חד-סטרית של כתובת ושני ביטים כל פעם, דרך מודולי RF Link Kit שנשלטים על ידי צמד הג'וקים 2262/72. הפתרון הזה נבחר כי הוא היה הקל ביותר ליישום, והוא עבד יפה. אך כעת המערכת עוברת מקצה שיפורים בכמה אספקטים, ועלתה השאלה האם כדאי לוותר על הג'וקים המסייעים ולנהל את התקשורת ישירות במיקרו-בקר הראשי.

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

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

המצב הקיים

צריכת החשמל של הג'וק המשדר (2262) נמוכה מאד: בזמן מנוחה, לפי המפרט, הוא מגיע עד מיקרואמפר בודד – ומכיוון שפין הפלט שלו לא צריך להניע שום עומס, סביר להניח שהמספרים לא יהיו משמעותיים גם בזמן שידור. אז לא נכלול אותו בחישוב.

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

כפי שפירטתי בעבר, כל שידור של הג'וק 2262 מורכב מארבע חזרות על "Frame", וכל "Frame" כזה מורכב משנים עשר פסודו-ביטים של כתובת/נתונים, ומפסודו-ביט אחד לסינכרון. פסודו-ביט של כתובת/נתונים יכול לקבל כל אחד משלושה ערכים שונים, שמיוצגים על ידי סדרות קצרות של HIGH ו-LOW. זמן ה-HIGH הכולל של ערך "0" הוא 8 מחזורי שעון, של ערך "1" הוא 24, ושל ערך "F" הזמן הוא 16 מחזורי שעון. שמונת הפסודו-ביטים הראשונים, שמהווים במערכת שלי את הכתובת, יכולים לקבל בתיאוריה כל ערך, כך שבממוצע יש לנו זמן HIGH של 16×8 מחזורי שעון. מתוך ארבעה פסודו-ביטים של נתונים, שניים (אלה שאני משתמש בהם בפועל) יכולים להיות רק "0" או "1" – עם זמן ממוצע של 16, כלומר מוסיפים 16×2 מחזורי שעון – ושני הנותרים יהיו תמיד 0, וזה מוסיף לנו 8×2 מחזורים. פסודו-ביט הסינכרון מתחיל באות HIGH של ארבעה מחזורי שעון בלבד. אם כן, הסכום לכל "Frame" הוא 180 מחזורי שעון.

השידור המלא מורכב כאמור מארבעה כאלה, כלומר 720 מחזורים. ומכיוון שבמערכת הקיימת תדר שעון השידור הוא 16.9KHz, אנחנו מדברים על זמן HIGH כולל של 42.6 אלפיות השניה לשידור. איך ועד כמה אפשר לרדת מהמספר הזה?

למתוח את הגבולות

הכיוון הראשון ששווה לבדוק, לפני שנוטשים את ה-2262, הוא תדר השעון שלו. הוא נקבע על ידי נגד חיצוני, שערכו במערכת הקיימת 2MOhm. נגד אחר ייתן תדר אחר, ואם למשל נגדיל את התדר פי שניים, זמן השידור (ולכן זמן ה-HIGH בשידור) יצטמצם פי שניים.

בתדר של 16.9KHz, משך ה-HIGH המינימלי שיוצא מה-2262 הוא כ-237 מיליוניות השניה. בבדיקת יכולות שעשיתי לא מזמן ל-RF Link Kit עלה שהמקלט מסוגל לזהות בקלות אותות שאורכם כ-100 מיליוניות השניה ואפילו פחות. אם נקבע את המספר 100us בתור גבול בטוח, אנחנו יכולים בעצם למצוא נגד שיזרז את השעון פי 2.37 ולרדת לכ-18 אלפיות השניה. לא רע. האם אפשר לרדת עוד יותר?

מפסודו-ביטים לביטים

שמונת הפסודו-ביטים התלת-ערכיים של הכתובת מגדירים מרחב של 6561 כתובות אפשריות. אני מוכן להסתפק ב-4096, שמחייבות 12 ביטים בינאריים. הפסודו-ביטים של הנתונים הם ממילא רק "0" או "1", ואני זקוק לשניים בלבד – סה"כ 14 ביטים לשידור. עם זאת, היתירות בשידור של 2262 נועדה לצמצם את הסיכוי לטעות, וגם זה דבר שצריך לקחת בחשבון – אז נניח שאעזר בשני ביטים נוספים לבקרת שגיאות מינימלית. סה"כ 16 ביטים. האם אוכל לשדר 16 ביטים בזמן HIGH קטן משמעותית מ-18ms לשידור?

המערכת העתידית

נניח, לצורך הדוגמה בלבד, שאני בוחר לייצג ביטים על ידי אורכים משתנים של אותות (אות של 100 מיליוניות השניה ל-"0" ומאתיים ל-"1"), עם רווחים קצרים ביניהם. בממוצע, משך ה-HIGH בשידור של 16 ביטים יהיה 16x150us, כלומר 2.4 אלפיות השניה.

אפשר לעבוד בצורה עוד יותר חכמה, ולהגדיר ביטים לא לפי משך ה-HIGH אלא לפי משכי השקט ביניהם – כך אפשר יהיה לרדת לזמן HIGH של, נניח, 16x100us שזה 1.6 אלפיות השניה. חיסכון של כ-90% בצריכת החשמל לשידור!

לסיכום

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