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

Rasmus Christian Larsen, Energy Micro

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

יישומים חדשים דורשים חיי שירות ארוכים
התקדמות המעבדים המשובצים הזולים, והחסכוניים באנרגיה וטכנולוגיות אובייקט חכם (Smart Object) הזינו את הצמיחה של רשתות מבוזרות חכמות עבור יישומים כגון בניינים חכמים\בתים חכמים, רשתות חשמל חכמות, ביטחון, ניטור סביבתי, ומערכות ניהול אנרגיה. אותן טכנולוגיות גם משמשות להוספת בינה למוצרים קיימים כגון מודדים חכמים לתפוצת אנרגיה, גז ומים כמו גם בריאות, כושר, וציוד רפואי נייד. בעוד שהדרישות התפעוליות והעיצוביות הן רבות ומגוונות, כל היישומים האלו חייבים לפעול בצורה מהימנה במשך שנים תוך שימוש במקורות אנרגיה מוגבלים הזמינים מסוללות או מערכות איסוף אנרגיה.
לתאי האלקליין AA המשמשים לרוב בהפעלת רכיבים רבים במערכות מבוזרות יש הספק תחילי של 100-2500mAh אך, כאשר לוקחים בחשבון את שיעור הפריקה-עצמית שלהם, המעצב צריך להסתמך על קרוב ל-1000mAh זמינים לשימוש למשך 5-7 שנות חיי שירות של הסוללה (ציור 1). יישומים מסוימים, (כגון מודדי מים וגז חכמים אלחוטיים) הקבורים או קשים לגישה באופן כזה או אחר, ניצבים בפני אתגרים גדולים יותר. על מנת להשיג חיי שירות של 10-20 שנים, משתמשים בסוללות עם כימיית דליפה-נמוכה מיוחדות היכולות לעלות $0.750/4Wh או יותר. על כן, יש לחתוך באופן משמעותי את תקציבי האנרגיה של המודד על מנת לשמות על תמחיר שהוא תחרותי בשוק הגלובלי.
עבור יישומים אלו, אין זה נדיר למצוא תקציבי אנרגיה של 5-20µA (ממוצע\מצב קבוע). עיצוב טיפוסי יכול לכלול תקציב אנרגיה המקצה 20% מההספק הזמין להעברת פעילויות, 30% לקבלת פקודות, ו-20% לאיסוף נתונים ותחזוקת מערכת. מה שמותיר רק 30% מהספק הסוללה לתמיכה במצב השינה\סרק של המערכת בהם היא תבלה יותר מ-99% מחייה. בדומה, הצמתים האלחוטיים ברשתות חישה מבוזרות המסתמכים על מערכות איסוף אנרגיה תרמיות או פוטו-וולטאיות חייבים להתקיים על תקציבי אנרגיה של 1-2mAh ליום.

ניהול זמן השכמה של מיקרו-בקר הוא קריטי
אם יישום מוגבל-אנרגיה מיושם כראוי, ומאחר ורוב תת-המערכות בעלות צריכת אנרגיה גבוהה (RF ומקלטי-משדרי שכבת-PHY, צגים, וכו’) כבר מתוכננות לצרוך בהתאם לזמן הנדרש במצב הפעיל שלהן, אזי המיקרו-בקר מהווה אחת מההזדמנויות הטובות ביותר למטב את תקציב האנרגיה הכולל של המערכת. את רוב חסכונות האנרגיה הנוספים ניתן להשיג על ידי מיטוב השימוש במצבי השינה והמתנה של המיקרו-בקר.
לרוב במיקרו-בקרים החדשים יש יותר ממצב אנרגיה-נמוכה אחד (בדרך ככל, “שינה\המתנה”, “שינה-עמוקה”, ו-“כבוי”), עם רמות שונות של תפקודי יע”מ, זיכרון, ו-I/O. התפקוד המסוים של מצבי “שינה\המתנה” ו-“שינה-עמוקה” יכול להשתנות ממעבד למעבד אך העקרונות הכלליים אינם משתנים ביסודם.
באופן כללי, ככל שהשינה עמוקה יותר, כך המיקרו-בקר צורך פחות כוח. אך חסכונות האנרגיה באים עם מחיר, מאחר והשכמה משינה עמוקה יותר אורכת יותר זמן. הגורמים המשפיעים על זמן ההשכמה כוללים:
חשל (Hysteresis) והשהיות התקדמות בתוך מעגלי ההשכמה
הפעלה וייצוב ניהול אנרגיה של ליבת המיקרו-בקר
הפעלה-מחדש וייצוב מעגל שעון היע”מ
שחזור אוגרי (registers) המעבד ותצורות פנימיות אחרות
זיכרון שחזור מערכת
מחזורי יע”מ הנדרשים על ידי הפסיקה (interrupt) שהניעה את ההפעלה-מחדש

תגובתיות זמן-אמת לעומת חסכונות באנרגיה
השגת פעולה באנרגיה נמוכה קלה יחסית אם כל האירועים שהמעבד-מארח חייב להתמודד עימם צפויים. אם חסכונות האנרגיה היו העניין היחידי, המערכת תבחר במצב “כבוי\כיבוי” שלה. במקרה זה, המעבד יכול להיכנס למצב כיבוי אחרי תכנות שעון הזמן-אמת שלו (או כל לוגיקת תזמון אחרת) על מנת להניע את תהליך ההשכמה מספיק מוקדם ולהבטיח את מוכנותו לאירוע הבא. דוגמאות לאירועים צפויים יותר המחייבים מעבד להיכנס למצב פעיל כוללות:
יישומים רבים המשתמשים ב-ZigBee/802.15, Wi-Fi, וטכנולוגיות אלחוטיות אחרות צריכים פרוטוקולים קבועי-זמן הדורשים מהמעבד-מארח לבדוק באופן תקופתי הודעות מצמתי מערכת אחרים
פסיקות שעון זמן-אמת עבור משימות הקשורות למערכת, הגעה קבועה-בלוח זמנים של נתונים שנאספו, ושאר אירועי חוץ צפויים.
למרבה הצער, רוב היישומים שתוארו בחלק הקודם גם דורשים שהמיקרו-בקר יגיב לאירועים לא-מתוכננים בזמן-אמת או לפחות זמן-חצי-אמת. דוגמאות לאירועים כאלו כוללות:
תנועה\האמת נתונים, תנאי סף\אזעקה, פסיקות כוח, ואירועים חשובים אחרים, לא מתוכננים שיכולים לדרוש מהמעבד-מארח להגיב בתוך מילי-שניות או מיקרו-שניות ספורות כדי למנוע נזק למערכת או אובדן קריטי של נתונים.
פרוטוקולים קוויים ואלחוטיים מסוימים משדרים במרווחים אקראיים, הדורשים מהמעבד, או מבקר רדיו ייעודי, להיות מוכנים להגיב לחבילה נכנסת בכל זמן.
מדוגמאות אלו, קל לראות, במידה ומצב השינה שבחרתם אינו עמוק מדי, כי חזרת המיקרו-בקר לפעולה רגילה יכולה להימשך זמן רב מדי מכדי להגיב בזמן למה שהניע את מצב ההשכמה. פספוס התראה\אזעקה משמעו איבוד נתונים קריטיים, זמן תגובה איטי לא מקובל לפקודת משתמש, או פגיעה בזמן התגובה של המערכת כולה.

RTOS עם צריכת כוח נמוכה – חידוש או סתירה?
מערכות הפעלה זמן-אמת (RTOS), הנעשות מקובלות יותר ויותר ביישומים משובצים מסוימים, מסבכות את העניינים עוד יותר משום ההתנהגות הדטרמיניסטית והתכנות המפושט שהן מביאות לעיצוב. יחד עם יתרונותיה, RTOS מציגה רמה נוספת של אתגרים טכניים. מעצבים הרוצים ליישם RTOS חייבים לטפל בכל הנושאים שנדונו עד כה, אך גם חייבים לזכור כי:
RTOS רבות דורשות שהמיקרו-בקר יהיה במצב פעיל (או לפחות בהמתנה) ורק מעטות (כגון AVIX ו-FreeRTOS) מצוידות לתמיכה במצבי השינה-עמוקה\כבוי.
RTOS בדרך כלל נושאות תקורה נוספת, גם במונחים של גודל קוד, וחשוב יותר, גם במספר ההוראות הדרושות לחזור ממצב שינה או ביצוע משימות אחרות בהן כל מיקרו-שנייה חשובה.
למרבה המזל, תכנון חומרה טוב ושיטות עבודה חכמות בכתיבת קוד מאפשרים ליהנות מהיתרונות של RTOS ביישומים מוגבלי-אנרגיה רבים. לקראת סוף המאמר נדון בכמה מהנושאים הבסיסיים המעורבים בפיתוח מערכות מונעות-RTOS עם צריכת אנרגיה נמוכה.

מבט קרוב יותר בשינה
אחת הדרכים העיקריות במיטוב עיצוב משובץ עם צריכת חשמל נמוכה היא למצוא את מצב השינה הנמוך ביותר שעדיין מספק תגובה מספיקה לאירועים בזמן-אמת. לפני שנעבור על הצעדים הנדרשים לזיהוי מצב (י) שינה המתאים ביותר ליישום מסוים, יעזור מאוד ללמוד את צריכת החשמל של המיקרו-בקר, את התפקודיות הזמינה, ומשך הזמן שיידרש לחזור למצב פעיל מכל אחד ממצבי ההמתנה\שינה שלו.
על מנת להמחיש את המאפיינים של כל מצב שינה, אנו נשתמש ב-“EFM32 Gecko” של Micro Energy ממשפחת המיקרו-בקרים 32 – ביט ממוטבי האנרגיה.
למרות שארכיטקטורת ה-Gecko שופרה כדי לתפקד מעבר לדרישות הבסיסיות של כל מצב, לרוב המיקרו-בקרים המשמשים ביישומים מסוג זה יהיו מצבי פעולה ומאפיינים דומים (ציור 2).
הערה: לארכיטקטורות מיקרו-בקרים רבים יש מצב “שינה עמוקה” אחד הכולל את רוב התכונות של מצבי האנרגיה EM2 ו-EM3 של ה-EFM32.
שינה\המתנה (ידוע כ-“EM1” עבור ה-EFM32) – מאפשר חזרה מהירה למצב פעיל (בדרך כלל דרך פסיקה) על חשבון צריכת חשמל קצת גבוהה יותר.
במצב זה:
מתנד שעון התדר גבוה של המיקרו-בקר ממשיך לעבוד אך עץ שעון היע”מ כבוי. מצב זה מאפשר ליע”מ לחזור לבצע הוראות במחזור השעון הבא לאחר התחלת ההשכמה.
עצי שעון התדר גבוה ההיקפיים פעילים, ומאפשרים להתקנים היקפיים במהירות-גבוהה כגון DMA, UART/USART במהירות גבוהה, ADC/DAC, וקידוד\פענוח AES לפעול אוטונומית
מתנד התדר נמוך של 32.768kHz נשאר פועל, ומאפשר להתקנים היקפיים במהירות-נמוכה להישאר פעילים.
מצביע המיקרו-בקר ומצבי תצורת אוגרים נשמרים, ומבטלים את הצורך בשמירה במהלך כיבוי, שחזור או הפעלה. שמירה על תוכן האוגר בדרך כלל חוסכת מאות עד אלפי מחזורי הוראות בכל השכמה.
זיכרון גישה ישירה נותר פעיל וה-DMA יכול לגשת אליו.
צריכת חשמל: EFM32 = נמוך עד כדי 900nA (עם RTC הפועל ממקור שעון מדויק) 1, מקבילה טיפוסית, מיקרו-בקר של 32- ביט = 200μA.
זמן חזרה למצב פעיל: EFM32 = 1 מחזור שעון.
שינה עמוקה – (ידוע כ-“FM2” עבור ה-EFM32) – מותיר את הרכיבים הקריטיים של המיקרו-בקר פעילים תוך כיבוי שעוני מערכת לתדר גבוה ועומסים לא-חיוניים אחרים.
מתנד מיקרו-בקר בתדר גבוה כבוי.
מתנד התדר נמוך של 32.768kHz המשמש לתזמון התקנים היקפיים על השבב נותר פועל, המאפשר בחירת פונקציות בצריכת אנרגיה נמוכה להישאר פעילים. (כולל מנהל התקן ה-LCD ,RTC, קוצב ה-Watch Dog UART בצריכת אנרגיה נמוכה (LEUART), ממשק חישת מגע, ופסי ה-I2C ו-USB).
מעגלי אתחול הפעלה, וזיהוי הפחתת מתח מערכתית (Brown-out) גם נותרים פעילים.
שמירה מלאה של RAM ואוגרי יע”מ מאפשרת למיקרו-בקר לחזור למצב פעיל במהירות ולשוב לתוכנית במהירות.
צריכת חשמל: EFM32 = נמוך עד כדי 900nA (עם RTC הפועל ממקור שעון מדויק)1, מקבילה טיפוסית, מיקרו-בקר של 32-ביט = 10μA עד 50μA.
זמן חזרה למצב פעיל: EFM32 = 2µs, מקבילה טיפוסית, מיקרו-בקר של 32- ביט = 5µs עד 8µs.
עצירה – (ידוע כ-“EM3” עבור ה-EFM32) גרסה עמוקה יותר של מצב שינה עמוקה המאפשר חיסכון נוסף באנרגיה תוך שמירה על פעילות היקפית אוטונומית מוגבלת והשכמה מהירה.
במצב זה:
מתנדי התדר גבוה והתדר נמוך כבויים.
מצביע המיקרו-בקר ומצבי תצורת האוגרים נשמרים.
תוכן מלא של RAM נשמר.
אתחול הפעלה, השכמת אתחול פין EM4 וגלאי הפחתת מתח מערכתית נותרים פעילים.
ניתן להעיר את היע”מ על ידי פסיקה חיצונית אסינכרונית או כמה מקורות פנימיים כולל הקומפרטורים האנלוגיים שלה (ACMP), מונה פולסים (PCNT), וכאשר פונה אליה מאסטר I2C.
ה-EFM32 שומר על זיכרון פנימי מלא במצבי EM2 ו-EM3, בעוד שהזיכרון אובד בחלק מהמיקרו-בקרים המקבילים.
צריכת חשמל: EFM32 = 0.59μA, מקבילה טיפוסית, מיקרו-בקר של 32-ביט = 10μA עד 30μA.
זמן חזרה למצב פעיל: EFM32 = 2µs, מקבילה טיפוסית, מיקרו-בקר של 32- ביט = 5µs עד 8µs.
כבוי – (ידוע כ-EM4 או “מצב כבוי” ב-EFM32) – מצב “כמעט-מוות” זה משמר מינימום התפקודיות המשלימה הנדרשת להנעת השכמה מגירוי חיצוני. חיסכון האנרגיה בא על חשבון זמני השכמה ארוכים יותר.
במצב זה:
כל הפונקציות ושעונים כבויים, למעט מעגל ניטור פסיקה בפין ה-Reset, השכמת פין GPIO, ומונה זמן-אמת.
הפעלה מחדש דורשת אתחול מכשיר או פסיקה והפעלה-מחדש של ליבת מיקרו-בקר ומתנד ה-RC בתדר גבוה שחייב לפעול ולהתייצב לפני שהיע”מ יכולה לבצע את ההוראה הראשונה.
כמו רוב המיקרו-בקרים, האוגרים של ה-EFM32, ותוכן הזיכרון הראשי אובדים וחייבים להיטען. אולם, ה-EFM32 כולל בלוק זיכרון של 512-byte הנשמר אף במצב זה.
כל מידע תצורת מכשיר אובד, למעט הקצאות פין GPIO.
צריכת חשמל, EFM32 = 20 nA (400 nA עם RTC פועל), מקבילה טיפוסית, מיקרו-בקר 32-ביט = 1.5 µA.
זמן החזרה של המעבד ממצב כבוי למצב פעיל: 160 µs עבור EFM32.
מצב סוללת גיבוי – מאפיין ייחודי של Micro Energy. מצב זה מאפשר חלופה אטרקטיבית למצב הכבוי המשמר פונקציות קריטיות נוספות ומאפשר השכמה הרבה יותר מהירה. משמש לרוב רק אם אספקת החשמל הראשית נופלת והמערכת עובדת על מקור חלופי.
במצב זה:
ה-RTC נותר פעיל.
בלוק של 512-byte נבחר של RAM היע”מ נשמר.
המיקרו-בקר צורך רק 400nA – למקרו-בקרEFM32 של Energy Micro במצב זה ייקח כמעט 7 שנים לצרוך בערך 25% מההספק של זוג תאי AA (הופחתו ל-1000mAh כל אחד).
למרות שמשמש בדרך כלל לפעולות גיבוי\החלפת סוללה, EM3A יכול להיות חלופה מצוינת למצב כבוי עבור יישומיים מסוימים.

איזה מצב שינה?
מרגע שהובנו זמני ההשכמה ורמות החשמל לכל אחד ממצבי השינה של המיקרו-בקר, קל יחסית למצוא את המצב שמספק מקסימום חיסכון באנרגיה ומבטיח שהעיצוב שלכם יוכל להגיב מספיק מהר לאירועי זמן-אמת. תהליך הבחירה מערב מבט קרוב יותר בהיבטים של יישום היעד, המערכת שלכם, והמיקרו-בקר שמפעיל אותה. כדוגמה, אנו נשתמש במודול מופעל-סוללה המנטר את התנאים שמכולת משלוחים חווה במהלך שינוע (ציור 3):
1) פרטו את כל תנאי ההתראה\אזעקה הנוצרים על ידי היישום וזהו את האחד עם זמן ההמתנה הקצר ביותר. מוניטור מכולה זה מצויד לרוב במקלט GPS, חיישני טמפרטורה, מתגי מגע לזיהוי חבלה, ומדי תאוצה למדידת קפיצות, מכות וזעזועים שמתרחשים לאורך הדרך. הוא גם לעתים מצויד בממשק רדיו אחד או יותר, על פי דרישות היישום.
תחת נסיבות רגילות, המיקרו-בקר יישאר במצב שינה רוב הזמן, ומתעורר לכמה מילי-שניות כל 10 או 15 דקות כדי לתעד תנאי טמפרטורה. פעילות ממתגי זיהוי חבלה אכן דורשת תשומת לב בזמן אמת אך חלון התגובה בזמן המתאים לאותו אירוע נמדד במאות מילי-שניות ואף שניות. המעבד חייב, אולם, להיות מסוגל להתעורר ולהתחיל למדוד רמות זעזוע ורעד תוך מילי-שנייה או פחות מרגע שקלט מד התאוצה חורג רמת סף שתוכנתה-מראש.
2) לכל מצב המתנה, שינה, ושינה עמוקה, הוסיפו את ההשהיות הנכללות בין הזמן בו תנאי ההתראה או אזעקה נוצר, והזמן בו המיקרו-בקר מוכן להתחיל לטפל בו. בהמשך לדוגמה של מוניטור המכולה, אנו יכולים להניח שלחיישן מד התאוצה\מעגל הקומפרטור יש השהיה קטנה או כלל לא אך, תלוי במצב השינה בו הוא נמצא, המיקרו-בקר יחווה השהיות של כמה מיקרו-שניות עד מאות מילי-שניות לפני שיוכל להתחיל לתת תשומת לב לאירוע האזעקה שהעיר אותו.
3) הוסיפו את זמן ביצוע הקוד הדרוש לטיפול בתנאי ההתראה\אזעקה כדי לקבל את סך כל ההשהיה בין אירוע קריטי לזמן בו המיקרו-בקר מגיב. אורך חלק זה בקוד ישתנה בין יישום ליישום. הוא גם תלוי בשאלה האם המיקרו-בקר חייב לעבור דרך שגרת הטיפול בפסיקה (Interrupt Service Routine, ISR) או לקפוץ ישירות לקוד שמטפל באירוע הנוכחי. השוו את מקסימום זמן התגובה של כל מצב שינה וזהו את המצב עם צריכת החשמל הנמוכה ביותר התואם את מקסימום ההשהיה הנסבל של היישום.
4) וודאו שלמצב השינה שבחרתם יש את המשאבים שאתם צריכים. לדוגמה, אם היישום דורש RTC, הוא לא יכול לרדת נמוך יותר ממצב שינה עמוקה.
אם מצב השינה שבחרתם לא מספק את חיי הסוללה הדרושים, ישנן טכניקות אחרות שתוכלו להשתמש בהן כדי לחדד את העיצוב שלכם אשר יידונו בחלק הבא.
אסטרטגיות אחרות לצמצום פעילות יע”מ
חשובים ככל שיהיו, מצבי שינה הם רק משתנה אחד במשוואת ניהול החשמל. וכמו כל משוואה מורכבת, האופן השימוש במצב שינה תלוי במשתנים המלווים שלו. האסטרטגיות המפורטות להלן הן דוגמה לדרך בה השימוש במשתנים אחרים אלו מאפשר לנצל את היתרונות הטובים ביותר במצבי השינה של המיקרו-בקר.
– זהו את שגרת הפונקציות מרמה-נמוכה שהיישום שלכם ידרוש ואתרו ארכיטקטורות מיקרו-בקר שיכולות להתמודד עם שגרות רבות ככל האפשר על ידי שימוש בחומרה על-שבב שאינה דורשת התערבות יע”מ. למעט פונקציות המונה\קוצב\RTC, הקיימות ברוב המיקרו-בקר, ישנן ארכיטקטורות מתקדמות (כולל Energy Micro) המטפלות ב:
המרות A/D ואיסוף נתונים אוטונומי
ניטור סיפי אזעקה (אנלוגיים ודיגיטליים)
קידוד\פענוח על ידי האצת חומרה
ניהול מסך מגע
– אם המיקרו-בקר בו אתם משתמשים יכול לנהל העברות זיכרון וטרנסאקציות אחרות בין התקנים היקפיים פנימיים וחיצוניים באופן אוטונומי, וודאו שאתם מנצלים זאת. לדוגמה, מקלט-משדר פס I2C או UART שיכול לקבל ולשלוח חבילות לזיכרון, מאפשר למיקרו-בקר להישאר במצב שינה עד שההודעות הנכנסות אכן דורשות פעולה. התקנים היקפיים בחלק מהמיקרו-בקרים דורשים חומרה חיצונית או התערבות יע”מ.
– אם המיקרו-בקר שלכם מבוסס על ארכיטקטורת ARM Cortex, אתם יכולים לקצר את זמן תגובת היע”מ על ידי שימוש בתצורה חלופית המאפשרת ליע”מ להתעורר על ידי בקשת פסיקה ולקפוץ ישירות לקוד היישום. ויתור על ה-ISR מוריד 12 מחזורי שעון מזמן התגובה של המיקרו-בקר יחד עם כל תקורת קוד אחרת הקשורה ל-ISR.
בחירת מהירות שעון מעבד המתאימה ליישום שלכם היא כלי נוסף שיכול לשמש בחידוד כמות החשמל בפעולת היישום וזמן מצב השינה שלו. במקרים רבים, מהירות המעבד המתקבלת בשימוש הכולל באנרגיה הנמוך ביותר לא תהיה גם מהירות השעון הנמוכה ביותר.
הרעיון של הפעלת התקן מהר יותר כדי לשמר אנרגיה יכול להיראות מנוגד לשכל הישר, אך צריכת האנרגיה של מוליך-למחצה, שהיא סכום הצריכה הסטטית שלו (המיוצגת בנפרד מתדירות שעון) והצריכה הפעילה שלו הגוברת עם מהירות הפעלה (MIPS/μW), בדרך כלל פוחתת כאשר תדירות השעון עולה. על כן, אם אנו מניחים שהכפלת תדר השעון משמעה קיצוץ הזמן בה היע”מ משלימה מטלה (ציור 4א) בחצי, העלייה בכוח הדינמי מקוזזת על ידי זמן העיבוד המופחת בעוד שצריכת כוח סטטית מתאימה לפרק זמן קצר יותר אשר גם יקוצץ בערך באותו אחוז (ציור 4ב).
חיסכון נוסף בחשמל ניתן להשיג לעתים על ידי הגברת מהירויות השידור של הקישורים החוטיים והאלחוטיים שלכם. זאת משום ש-PHY עבור רבות מהרשתות הקוויות (קווי חשמל, אתרנט, וכד’) והאלחוטיות (Wi-Fi, ZigBee, וכד’) צורך לעתים את אותה כמות או יותר של חשמל כפי שהמיקרו-בקר עצמו. אלא אם ישנם שיקולים אחרים (כגון זמני מו”מ קישור בשיעורי שידור גבוהים יותר), את צריכת החשמל של המקלט-משדר ניתן לצמצם בכך שנבטיח שמהירות שעון המעבד מספיקה כדי לאפשר לו לטפל הנתונים בשיעור זמינות השידור\קליטה המקסימליים של המקלט-משדר.

ענייני RTOS
מרבית היישומים שנדונו כאן משתמשים בארכיטקטורה בסגנון “לופ ראשי” עם תת-שגרות זמן-קריטי המונעות על ידי פסיקות הנוצרות על ידי שעון הזמן-אמת או רכיבי I/O היקפיים. חלק מהקוד המשובץ עדיין נכתב ברמת המכלל (assembly) אך מיקרו-בקרים בעלי יותר יכולות, קומפיילרים משופרים, וכלי תוכנה מתקדמים מאפשרים לכתוב יישומים רבים ב-C/C++ או שפות ברמה דומה.
ישנו גם מספר הולך וגדל של עיצובים עם צריכת חשמל נמוכה המשתמשים במערכת הפעלה זמן-אמת (RTOS) כדי לשלוט ביישומים מרדניים על ידי הבטחת תגובה דטרמיניסטית לאירועים מתוזמנים ולאירועים לא-מתוזמנים.
גם C וגם RTOS מציעים יתרונות ליישומים משובצי זמן-אמת כולל פיתוח וקוד מפושטים הנוטים להיות יותר חזקים. מבנה הקוד הסופי גם מאפשר שינויי קוד עתידיים עבור שדרוגים צפויים. לבסוף, השכבות והממשקים המוגדרים-היטב המוצעים על ידי RTOS מאפשרים שימוש בתווכות (middleware) שימושיות כגון מחסניות רשת ומנהלי התקני I/O.
למרות יתרונות אלו, ל-RTOS יש גם בעיות שמנעו מהן להיות בשימוש נרחב יותר בסביבות קלות משקל, ומוגבלות-חשמל המשותפות ליישומים שנדונו כאן. ברור לכל ש-RTOS דורש מיקרו-בקר של 32-ביט שבדרך כלל דורשים תקציב כוח הרבה יותר גדול מאשר המיקרו-בקרים של ה-8 או 16 bit השכיחים ביישומים אלו.
הרצת RTOS גם מעלה את השאלה האם היא דורשת שימוש בבלוקים של חומרה בתוך המיקרו-בקר (כגון קוצבים או שעוני זמן-אמת) שייתכן ואינם זמינים במצבי השינה העמוקה יותר שלו. רוב ה-RTOS מציעות תמיכה מוגבלת או כלל לא במצבי שינה אך ישנו מספר קטן, אך גדל של מוצרים שהם ידידותיים למצב שינה, כולל AVIX-RT ו-FreeRTOS. ל-AVIX יש את אחד מציוני בוחן הביצועים המהירים ביותר בתעשייה, זמן המתנה נמוך, וטביעת רגל זיכרון מאוד קלה. הוא יכול לשמש ברוב המיקרו-בקרים הנבנים סביב מעבד ה- ביט כמו גם כמה מעבדים אחרים, אלא שזה משופר במיוחד כדי להשתמש שימושי מלא במצבי האנרגיה הנמוכה של ה-EFM32.
FreeRTOS זו מערכת הפעלה קוד-פתוח, חוצה-פלטפורמות סטנדרטית עבור מיקרו-בקרים התומכת ב-28 ארכיטקטורות ו-17 שרשרות כלים. היא חופשית להורדה ופריסה, ויכולה לשמש ביישומים מסחריים מבלי לחשוף את קוד המקור הקנייני שלכם. היא גם זמינה כ-OpenRTOS, גרסה מסחרית ברישיון ונתמכת הכוללת USB מלא ברמה מקצועית, מערכת קבצים ורכיבי TCP/IP.
בעוד ששני מוצרי ה-RTOS תומכים בארכיטקטורות מיקרו-בקר רבות, למשפחת EFM32 של Energy Micro.
יש כמה מאפיינים ארכיטקטוניים, המסייעים לשימוש בצורה המיטבית של מצבי צריכת האנרגיה הנמוכה שלה, שבהם נדון בחלק הבא.

היתרון של
Energy Micro
את רוב הטכניקות ושיטות התכנון שכיסינו עד כה ניתן ליישם בכל מיקרו-בקר שעוצב לשימוש ביישומים מוגבלי-אנרגיה. בחלק זה, אנו נביט מקרוב בכמה מהמאפיינים המיוחדים בארכיטקטורת EFM32 של Energy Micro ההופכים אותה למיקרו-בקר החסכוני ביותר באנרגיה, הן עבור יישומים מסורתיים ויישומים מבוססי-RTOS משובצים.
כל חברי משפחת ה-EFM32 מצוידים ברכיבים היקפיים אנלוגיים ודיגיטליים משלימים (ציור 5). רוב הרכיבים האלו מכונים התקנים היקפיים אוטונומיים Autonomous Peripherals) APs) שיכולים לפעול ללא התערבות יע”מ ונותרים פעילים במצב שינה אחד או יותר. הדבר מנוגד לרוב המיקרו-בקרים, שמצבי החיסכון באנרגיה שלהם רק תומכים בפונקציות הישארות בחיים מאוד בסיסיות כגון השכמות GPIO ופעולת RTC.
בנוסף למונים\קוצבים, ADC/DACs GPIO ותקשורת טורית הנמצאים ברוב המיקרו-בקרים, ה-AP המשלימים של Energy Micro כוללים:
– מעבד חישה קיבולי – מזהה מגע בלוח נגיעה ומתאם ברשת n-by-n (עד 16 נקודות) ללא יע”מ. נותר פעיל עד למצב האנרגיה EM2.
– מנהל התקן LCD – מפעיל תצוגת LCD נומרי או TFT דרך DMA מזיכרון ללא יע”מ.
– קומפרטורים אנלוגיים – מאפשרים ניטור סף וולטים עבור תנאי התראה\אזעקה ללא התערבות יע”מ.
– UART בצריכת אנרגיה נמוכה (LEUART) עם DMA היכולים להישאר במצב EM2 ולקבל כמות גדולה של נתונים מבלי להעיר את היע”מ.
הפעילויות של רוב פונקציות ההיקפיות, כולל תקשורת טורית, מונים\קוצבים, קומפרטורים אנלוגיים ודיגטליים ו-I/O מרמה גבוהה יותר מתואמות על ידי פס רפלקס בצריכת חשמל נמוכה. אירועים ואותות מהתקן היקפי אחד יכולים לשמש כאותות קלט או מניעים עבור התקנים היקפיים אחרים ומבטיחים ביצוע בתזמון-קריטי ותקורת תוכנה מופחתת.
תכונות מתקדמות אלה מאפשרות למיקרו-בקר ממשפחת EFM32 של Energy Micro לרתום את הכוח החישובי של התקן 32-ביט ליישום עם צריכת אנרגיה טיפוסית (ולעתים אף קטנה יותר) למוצר 16-ביט.
ה-EFM32 גם כולל תכונות המאפשרות ל-RTOS לרוץ באופן יעיל ולנצל היטב את מצבי השינה\שינה עמוקה בחסכוניים באנרגיה. כמה מהתכונות החשובות ביותר כוללות:
– רבים מהשעונים והמונים של ה-EFM32 זמינים במצבי השינה (EM1), שינה עמוקה (EM2), לעצירה (EM3), כולל שעון גיבוי זמן-אמת. ומפחיתים בכך, בצורה משמעותית, את כמות תקורת המעבד שה-RTOS צריך לנצל כדי לשמר את הפניות התזמון שלו.
– שמירה על זיכרון פעיל, מצביעי יע”מ, ואוגרי תצורה במצבי שינה (EM1), שינה עמוקה (EM2) ועצירה (EM3) מפחיתה בצורה משמעותית את תקורת הזמן וקוד הדרושים לחזרת המיקרו-בקר למצב הריצה (EM0) שלו.
– הקוד הקל יותר ומהירות הביצוע המהירה יותר מאפשרים ל-RTOS לפעול באופן שקוף ליישום.
– אפילו עם התקורה הנוספת הבלתי-נמנעת ש-RTOS כופה, ליבת ה-RISC 32-ביט של ה-EFM32 נהנית מתכונות ביצוע מהיר יותר ומצב שינה מוגבר המפחיתות בצורה משמעותית את הזמן בו היא נמצאת במצב פעיל. ביישומים רבים, תכונות אלו מאפשרות ליהנות מתקציב אנרגיה השווה, או קטן יותר מזה של מיקרו-בקר 16-ביט.

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

הערות שוליים
1זרם המתנה של ה-EFM32 במצב שינה עמוקה (EM2) נמדד תחת התנאים הבאים: אספקת חשמל = 3V, טמפרטורת סביבה = 25°C.
זרם פעולה טיפוסי נמדד עבור המיקרו-בקר השלם ומתנדים חיצונים למיניהם, כולל ה-RTC (שפעל במתנד דיוק הפנימי), עם זיהוי הפחתת מתח מערכתית, שמירת RAM מלא ואוגר פעילים. זרם ב-RTC של מצב שינה עמוקה (EM2) נמדד עם ה-RTC שפעל מהמתנד תדר נמוך 32kHz הפנימי.

תגובות סגורות