ערימת חיישנים

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

שכבות ובעלים של ערימת חיישני אנדרואיד

איור 1. שכבות של ערימת חיישני אנדרואיד והבעלים שלהן

SDK

יישומים ניגשים לחיישנים דרך ה-API של Sensors SDK (ערכת פיתוח תוכנה) . ה-SDK מכיל פונקציות לרשימת חיישנים זמינים ולרישום לחיישן.

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

  • לדוגמה, אפליקציה עשויה להירשם למד התאוצה המוגדרת כברירת מחדל, לבקש אירועים ב-100Hz ולאפשר דיווח על אירועים בהשהייה של שנייה אחת.
  • האפליקציה תקבל אירועים ממד התאוצה בקצב של 100Hz לפחות, ואולי בעיכוב של עד שנייה אחת.

עיין בתיעוד המפתחים למידע נוסף על ה-SDK.

מִסגֶרֶת

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

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

ההשפעה של ריבוי

הצורך הזה בשכבת ריבוי במסגרת מסביר כמה החלטות עיצוביות.

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

היתוך חיישן

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

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

יישום ברירת המחדל של היתוך חיישנים אינו מתוחזק ועלול לגרום למכשירים המסתמכים עליו להיכשל ב-CTS.

מתחת למכסת המנוע

סעיף זה מסופק כמידע רקע לאלו ששומרים על קוד המסגרת של Android Open Source Project (AOSP). זה לא רלוונטי ליצרני חומרה.

JNI

המסגרת משתמשת בממשק מקורי של Java (JNI) המשויך ל- android.hardware וממוקם בספריית frameworks/base/core/jni/ . קוד זה קורא לקוד המקורי ברמה נמוכה יותר כדי לקבל גישה לחומרת החיישן.

מסגרת מקומית

המסגרת המקורית מוגדרת ב- frameworks/native/ ומספקת מקבילה מקורית לחבילת android.hardware . המסגרת המקורית קוראת ל-Binder IPC proxy כדי לקבל גישה לשירותים ספציפיים לחיישנים.

קלסר IPC

פרוקסי Binder IPC מקלים על תקשורת על פני גבולות תהליך.

HAL

ה-API של Sensors Hardware Abstraction Layer (HAL) הוא הממשק בין מנהלי ההתקן של החומרה למסגרת האנדרואיד. הוא מורכב ממשק HAL sensors.h ויישום HAL אחד שאנו מתייחסים אליו כ-sensors.cpp.

הממשק מוגדר על ידי תורמים של אנדרואיד ו-AOSP, והיישום מסופק על ידי יצרן המכשיר.

ממשק ה-HAL של החיישן ממוקם ב- hardware/libhardware/include/hardware . ראה sensors.h לפרטים נוספים.

מחזור שחרור

יישום HAL מציין איזו גרסה של ממשק HAL הוא מיישם על ידי הגדרת your_poll_device.common.version . גרסאות ממשק HAL הקיימות מוגדרות ב-sensors.h, והפונקציונליות קשורה לגרסאות אלו.

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

נהג ליבה

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

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

רכזת חיישן

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

הערה: כדי לפתח תכונות חדשות של ContextHub המשתמשות בחיישנים או נוריות LED חדשות, אתה יכול גם להשתמש ב- Neonkey SensorHub המחובר ללוח פיתוח Hikey או Hikey960.

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

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

אפשרות אחת שנראה שיש לה השפעה משמעותית על פשטות היישום היא קיום שני קווי פסיקה העוברים מרכזת החיישנים ל-SoC: האחד עבור פסיקות התעוררות (לחיישני התעוררות), והשני עבור פסיקות לא התעוררות. (לחיישנים שאינם מתעוררים).

חיישנים

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

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

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