אצווה

מה זה אצווה?

אצווה מתייחסת לאגירת אירועי חיישנים ברכזת חיישנים ו/או FIFO של חומרה לפני דיווח על האירועים דרך ה- SENSYS HAL . המיקום שבו מאוגרים אירועי החיישן (רכזת חיישנים ו/או FIFO של חומרה) נקראים "FIFO" בדף זה. כאשר אצווה אירועי חיישן אינה פעילה, אירועי חיישנים מדווחים מיד ל-SENSORS HAL כאשר הם זמינים.

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

אצווה יכולה להתרחש רק כאשר לחיישן יש FIFO חומרה ו/או יכול לחצץ אירועים בתוך רכזת חיישנים. בכל מקרה, החיישן חייב לדווח על המספר המרבי של אירועים שניתן לקבץ בבת אחת דרך SensorInfo.fifoMaxEventCount .

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

אירועי חיישן מצטברים במצבים הבאים:

  • זמן השהיית הדיווח המקסימלי הנוכחי של החיישן גדול מאפס, מה שאומר שניתן לעכב אירועי חיישן עד להשהיית הדיווח המקסימלית לפני הדיווח באמצעות ה-HAL.
  • ה-AP נמצא במצב השהייה והחיישן הוא חיישן שאינו מתעורר. במקרה זה, אירועים לא חייבים להעיר את ה-AP ויש לאחסן אותם עד שה-AP יתעורר.

אם חיישן אינו תומך באצווה וה-AP במצב שינה, רק אירועי חיישן התעוררות מדווחים ל-AP ואסור לדווח ל-AP אירועים שאינם מתעוררים.

פרמטרי אצווה

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

sampling_period_ns

המשמעות של הפרמטר sampling_period_ns תלויה במצב הדיווח של החיישן שצוין:

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

למידע נוסף על ההשפעה של sampling_period_ns במצבים השונים, ראה מצבי דיווח .

עבור חיישנים רציפים ובשינויים:

  • אם sampling_period_ns קטן מ- SensorInfo.minDelay , אז מימוש HAL חייב להצמיד אותו בשקט ל- max(SensorInfo.minDelay, 1ms) . אנדרואיד לא תומכת ביצירת אירועים ביותר מ-1000 הרץ.
  • אם sampling_period_ns גדול מ- SensorInfo.maxDelay , אז מימוש HAL חייב לחתוך אותו בשקט ל- SensorInfo.maxDelay .

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

אם התדירות המבוקשת היא

אז התדירות בפועל חייבת להיות

תדירות מתחת למינימום (<1/maxDelay)

בין 90% ל-110% מתדירות המינימום

בין תדר מינימלי למקסימום

בין 90% ל-220% מהתדירות המבוקשת

מעל התדירות המקסימלית (>1/minDelay)

בין 90% ל-110% מהתדר המקסימלי, ומתחת ל-1100 הרץ

max_report_latency_ns

max_report_latency_ns מגדיר את הזמן המקסימלי בננו-שניות, שבאמצעותו ניתן לעכב אירועים ולשמור אותם ב-FIFO החומרה לפני שהם מדווחים דרך ה-HAL בזמן שה-AP ער.

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

לדוגמה, מד תאוצה המופעל ב-50 הרץ עם max_report_latency_ns=0 יפעיל פסיקות 50 פעמים בשנייה כאשר ה-AP ער.

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

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

מתן אפשרות לאחסון זמני של אירועי חיישן ב-FIFO אינו משנה את התנהגות הגשת האירועים ל-HAL; ניתן לשלב אירועים מחיישנים שונים וכל האירועים מאותו חיישן מסודרים בזמן.

אירועי השכמה ולא השכמה

אירועי חיישנים מחיישני השכמה חייבים להיות מאוחסנים ב-FIFO התעוררות אחד או יותר. עיצוב נפוץ הוא לקיים FIFO השכמה יחיד, גדול ומשותף שבו אירועים מכל חיישני ההתעוררות משתלבים. לחלופין, אתה יכול לקבל FIFO התעוררות אחד לכל חיישן או FIFO ייעודי עבור חיישני התעוררות מסוימים ו-FIFO משותף עבור שאר חיישני ההתעוררות.

באופן דומה, אירועי חיישנים מחיישנים שאינם מתעוררים חייבים להיות מאוחסנים ב-FIFO אחד או יותר שאינו מתעורר.

בכל המקרים, לא ניתן לשלב אירועי חיישן התעוררות ואירועי חיישן ללא התעוררות באותו FIFO. אירועי התעוררות חייבים להיות מאוחסנים ב-FIFO של השכמה, ואירועים שאינם התעוררות חייבים להיות מאוחסנים ב-FIFO שאינו מתעורר.

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

התנהגות מחוץ למצב השעיה

כאשר ה-AP ער (לא במצב השעיה), אירועים מאוחסנים באופן זמני ב-FIFO כל עוד הם לא מתעכבים ביותר מ- max_report_latency .

כל עוד ה-AP לא נכנס למצב השעיה, שום אירוע לא יושמט או יאבד. אם FIFOs פנימיים מתמלאים לפני max_report_latency , אירועים מדווחים באותה נקודה כדי להבטיח ששום אירוע לא יאבד.

אם מספר חיישנים חולקים את אותו FIFO ו- max_report_latency של אחד מהם חולף, כל האירועים מה-FIFO מדווחים, גם אם max_report_latency של שאר החיישנים עדיין לא חלפה. זה מפחית את מספר הפעמים שמדווחות קבוצות של אירועים. כאשר יש לדווח על אירוע אחד, כל האירועים מכל החיישנים מדווחים.

לדוגמה, אם החיישנים הבאים מופעלים:

  • מד תאוצה באצווה עם max_report_latency = 20 שניות
  • גירוסקופ באצווה עם max_report_latency = 5s

קבוצות מד התאוצה מדווחות באותו זמן שבו מדווחות קבוצות הג'ירוסקופ (כל 5 שניות), גם אם מד התאוצה והגירוסקופ אינם חולקים את אותו FIFO.

התנהגות במצב השעיה

אצווה מועיל במיוחד לאיסוף נתוני חיישנים ברקע מבלי לשמור על ה-AP ער. מכיוון שמנהלי ההתקן של החיישנים והטמעת HAL אינם מורשים להחזיק נעילת השכמה*, ה-AP יכול להיכנס למצב השעיה גם בזמן איסוף נתוני חיישן.

ההתנהגות של חיישנים בזמן שה-AP מושעה תלויה בשאלה אם החיישן הוא חיישן התעוררות. לפרטים נוספים, ראה חיישני התעוררות .

כאשר FIFO שאינו מתעורר מתמלא, הוא חייב להתעטף ולהתנהג כמו חוצץ מעגלי, המחליף אירועים ישנים יותר כשהאירועים החדשים מחליפים את הישנים. ל- max_report_latency אין השפעה על FIFOs שאינם מתעוררים בזמן השעיה.

כאשר FIFO התעוררות מתמלא, או כאשר max_report_latency של אחד מחיישני ההתעוררות חולפת, החומרה חייבת להעיר את ה-AP ולדווח על הנתונים.

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

*חריג אחד בולט של נהגים שלא מורשים להחזיק נעילת ערות הוא כאשר חיישן התעוררות עם מצב דיווח רציף מופעל עם max_report_latency < שנייה אחת. במקרה זה, הנהג יכול להחזיק נעילת התעוררות מכיוון של-AP אין זמן להיכנס למצב השעיה, מכיוון שהוא יתעורר מאירוע התעוררות לפני שהגיע למצב השעיה.

אמצעי זהירות שיש לנקוט בעת שילוב חיישני התעוררות

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

אמצעי זהירות שיש לנקוט בעת שילוב חיישנים ללא התעוררות בעת שינוי

חיישני On-change יוצרים אירועים רק כאשר הערך שהם מודדים משתנה. אם הערך הנמדד משתנה בזמן שה-AP במצב השהייה, יישומים מצפים לקבל אירוע ברגע שה-AP מתעורר. בשל כך, יש לבצע אצווה של אירועי חיישן ללא התעוררות בעת שינוי בזהירות אם החיישן חולק את ה-FIFO שלו עם חיישנים אחרים. האירוע האחרון שנוצר על ידי כל חיישן ב-change חייב תמיד להישמר מחוץ ל-FIFO המשותף כך שלעולם לא ניתן יהיה לדרוס אותו על ידי אירועים אחרים. כאשר ה-AP מתעורר, לאחר שכל האירועים מה-FIFO דווחו, יש לדווח על אירוע החיישן האחרון בשינוי.

הנה מצב שכדאי להימנע ממנו:

  1. אפליקציה נרשמת למונה הצעדים ללא התעוררות (בשינוי) ולמד התאוצה ללא התעוררות (רציף), שניהם חולקים את אותו FIFO.
  2. האפליקציה מקבלת אירוע מונה step_count=1000 steps קוד>.
  3. ה-AP הולך להשעיה.
  4. המשתמש צועד 20 צעדים, מה שגורם לאירועי מונה צעדים ומד תאוצה להשתלב, אירוע מונה הצעדים האחרון הוא step_count = 1020 steps .
  5. המשתמש לא זז במשך זמן רב, מה שגורם לאירועי מד התאוצה להמשיך להצטבר ב-FIFO, ולבסוף מדרוס כל אירוע step_count ב-FIFO המשותף.
  6. AP מתעורר וכל האירועים מה-FIFO נשלחים לאפליקציה.
  7. האפליקציה מקבלת רק אירועי מד תאוצה וחושבת שהמשתמש לא הלך.

על ידי שמירת אירוע מונה הצעדים האחרון מחוץ ל-FIFO, ה-HAL יכול לדווח על אירוע זה כאשר ה-AP מתעורר, גם אם כל שאר אירועי מונה הצעדים הוחלפו על ידי אירועי מד התאוצה. בדרך זו, האפליקציה מקבלת step_count = 1020 steps כאשר ה-AP מתעורר.

יישום אצווה

כדי לחסוך בחשמל, יש ליישם אצווה ללא עזרת ה-AP, ויש לאפשר ל-AP להשהות במהלך האצווה.

אם אצווה מתבצעת ברכזת חיישנים, יש למזער את צריכת החשמל של רכזת החיישנים.

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

עדיפות להקצאת FIFO

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

ערך גבוה: הספק נמוך של הולכי רגל

זמן אצווה יעד: 1 עד 10 דקות

חיישנים לאצווה:

  • גלאי צעדי התעוררות
  • וקטור סיבוב משחק התעוררות ב-5 הרץ
  • ברומטר השכמה ב-5 הרץ
  • מגנומטר לא מכויל התעוררות ב-5 הרץ

אצווה של נתונים אלה מאפשרת ביצוע חישוב מוות של הולכי רגל תוך מתן אפשרות ל-AP ללכת להשעות.

ערך גבוה: זיהוי פעילות/ מחוות לסירוגין בעוצמה בינונית

זמן אצווה יעד: 3 שניות

חיישנים לקבוצה: מד תאוצה ללא התעוררות ב-50 הרץ

אצווה של נתונים אלה מאפשרת לזהות מעת לעת פעילויות ומחוות שרירותיות מבלי צורך להשאיר את ה-AP ער בזמן איסוף הנתונים.

ערך בינוני: זיהוי פעילות מתמשכת/ מחוות בעוצמה בינונית

זמן אצווה יעד: 1 עד 3 דקות

חיישנים לקבוצה: מד תאוצה של השכמה ב-50 הרץ

אצווה של נתונים אלה מאפשרת זיהוי רציף של פעילויות ומחוות שרירותיות ללא צורך להשאיר את ה-AP ער בזמן איסוף הנתונים.

ערך בינוני-גבוה: הפחתת עומס פסיקה

זמן אצווה יעד: < שנייה אחת

חיישנים לקבוצה: כל חיישן בתדר גבוה, בדרך כלל לא מתעורר.

אם הג'ירוסקופ מוגדר ל-240 הרץ, אפילו אצווה של 10 אירועי ג'ירו בלבד יכולה להפחית את מספר ההפסקות מ-240 לשנייה ל-24 לשנייה.

ערך בינוני: איסוף נתונים מתמשך בתדר נמוך

זמן אצווה יעד: 1 עד 10 דקות

חיישנים לאצווה:

  • ברומטר השכמה ב-1 הרץ
  • חיישן לחות מתעורר ב-1 הרץ
  • חיישני השכמה אחרים בתדר נמוך בקצבים דומים

מאפשר יצירת אפליקציות ניטור בהספק נמוך.

ערך בינוני-נמוך: איסוף חיישנים מלאים מתמשך

זמן אצווה יעד: 1 עד 10 דקות

חיישנים לקבוצה: כל חיישני ההתעוררות, בתדרים גבוהים

מאפשר איסוף מלא של נתוני חיישנים תוך השארת ה-AP במצב השעיה. שקול רק אם שטח FIFO אינו מהווה בעיה.