پشته سنسور

شکل زیر مجموعه سنسور اندروید را نشان می دهد. هر جزء فقط با اجزای مستقیماً بالا و پایین خود ارتباط برقرار می کند، اگرچه برخی از سنسورها می توانند هاب سنسور را در صورت وجود دور بزنند. کنترل از برنامه ها به سمت سنسورها جریان می یابد و داده ها از سنسورها به سمت برنامه ها جریان می یابد.

شکل 1. لایه های پشته سنسور اندروید و صاحبان مربوطه آنها

SDK

برنامه‌ها از طریق Sensors SDK (کیت توسعه نرم‌افزار) API به حسگرها دسترسی دارند. SDK دارای عملکردهایی برای فهرست کردن حسگرهای موجود و ثبت نام در یک حسگر است.

هنگام ثبت نام در یک حسگر، برنامه فرکانس نمونه برداری ترجیحی و الزامات تأخیر آن را مشخص می کند.

• به عنوان مثال، یک برنامه ممکن است در شتاب‌سنج پیش‌فرض ثبت شود، رویدادها را در 100 هرتز درخواست کند، و اجازه دهد رویدادها با تأخیر 1 ثانیه گزارش شوند.
• برنامه رویدادها را از شتاب سنج با نرخ حداقل 100 هرتز و احتمالاً تا 1 ثانیه با تأخیر دریافت می کند.

برای اطلاعات بیشتر در مورد SDK به مستندات توسعه دهنده مراجعه کنید.

چارچوب

این فریم ورک مسئول پیوند دادن چندین برنامه به HAL است. خود HAL تک مشتری است. بدون این که این چندگانه سازی در سطح چارچوب اتفاق بیفتد، تنها یک اپلیکیشن می تواند در هر زمان معین به هر حسگر دسترسی داشته باشد.

• هنگامی که اولین برنامه در یک سنسور ثبت می شود، فریم ورک درخواستی را به HAL ارسال می کند تا حسگر را فعال کند.
• هنگامی که برنامه های اضافی در همان سنسور ثبت می شوند، چارچوب الزامات هر برنامه را در نظر می گیرد و پارامترهای درخواستی به روز شده را به HAL ارسال می کند.
  • فرکانس نمونه‌برداری حداکثر فرکانس‌های نمونه‌گیری درخواستی خواهد بود، به این معنی که برخی از برنامه‌ها رویدادها را با فرکانس بالاتر از فرکانس درخواستی دریافت خواهند کرد.
  • حداکثر تأخیر گزارش حداقل موارد درخواستی خواهد بود. اگر یک برنامه یک سنسور با حداکثر تأخیر گزارش 0 درخواست کند، همه برنامه‌ها رویدادها را از این حسگر در حالت پیوسته دریافت خواهند کرد، حتی اگر برخی سنسور را با حداکثر تأخیر گزارش غیر صفر درخواست کنند. برای جزئیات بیشتر به Batching مراجعه کنید.
• هنگامی که آخرین برنامه ثبت شده در یک سنسور از آن خارج می شود، فریمورک ها درخواستی را به HAL ارسال می کنند تا حسگر را غیرفعال کند تا انرژی بی مورد مصرف نشود.

تاثیر مالتی پلکس شدن

این نیاز به یک لایه مالتی پلکس در چارچوب، برخی از تصمیمات طراحی را توضیح می دهد.

• هنگامی که یک برنامه کاربردی یک فرکانس نمونه برداری خاص را درخواست می کند، هیچ تضمینی وجود ندارد که رویدادها با سرعت بیشتری به دست نیایند. اگر برنامه دیگری همان سنسور را با سرعت بیشتری درخواست کند، اولین برنامه نیز آنها را با نرخ سریع دریافت خواهد کرد.
• همان فقدان ضمانت در مورد حداکثر تأخیر گزارش درخواستی اعمال می‌شود: برنامه‌ها ممکن است رویدادهایی را با تأخیر بسیار کمتر از درخواست خود دریافت کنند.
• علاوه بر فرکانس نمونه برداری و حداکثر تأخیر گزارش، برنامه ها نمی توانند پارامترهای حسگر را پیکربندی کنند.
  • به عنوان مثال، یک حسگر فیزیکی را تصور کنید که می‌تواند هم در حالت «دقت بالا» و هم در حالت «توان کم» کار کند.
  • فقط یکی از این دو حالت را می توان در دستگاه اندرویدی استفاده کرد، زیرا در غیر این صورت، یک برنامه می تواند حالت دقت بالا و دیگری حالت کم مصرف را درخواست کند. هیچ راهی برای فریمورک وجود نخواهد داشت که هر دو برنامه را برآورده کند. چارچوب باید همیشه بتواند همه مشتریان خود را راضی کند، بنابراین این یک گزینه نیست.
• هیچ مکانیزمی برای ارسال داده ها از برنامه ها به حسگرها یا درایورهای آنها وجود ندارد. این تضمین می‌کند که یک برنامه نمی‌تواند رفتار سنسورها را تغییر دهد و سایر برنامه‌ها را از بین ببرد.

همجوشی سنسور

فریم ورک اندروید یک پیاده سازی پیش فرض برای برخی از حسگرهای ترکیبی ارائه می دهد. هنگامی که یک ژیروسکوپ ، یک شتاب سنج و یک مغناطیس سنج روی یک دستگاه وجود دارد، اما هیچ سنسور بردار چرخشی ، گرانش و شتاب خطی وجود ندارد، چارچوب آن حسگرها را پیاده‌سازی می‌کند تا برنامه‌ها همچنان بتوانند از آنها استفاده کنند.

پیاده‌سازی پیش‌فرض به تمام داده‌هایی که سایر پیاده‌سازی‌ها به آن دسترسی دارند دسترسی ندارد و باید روی SoC اجرا شود، بنابراین به اندازه سایر پیاده‌سازی‌ها دقیق و کارآمد نیست. تا آنجا که ممکن است، سازندگان دستگاه باید حسگرهای ذوب شده خود را تعریف کنند (بردار چرخش، گرانش و شتاب خطی، و همچنین سنسورهای ترکیبی جدیدتر مانند بردار چرخش بازی ) به جای اتکا به این پیاده سازی پیش فرض. سازندگان دستگاه همچنین می توانند از فروشندگان تراشه حسگر درخواست کنند تا یک پیاده سازی را به آنها ارائه دهند.

اجرای پیش‌فرض فیوژن سنسور حفظ نمی‌شود و ممکن است باعث شود دستگاه‌های متکی به آن CTS را از کار بیاندازند.

در زیر کاپوت

این بخش به عنوان اطلاعات پس زمینه برای کسانی که کد چارچوب پروژه منبع باز Android (AOSP) را حفظ می کنند ارائه شده است. برای سازندگان سخت افزار مناسب نیست.

JNI

این فریم ورک از یک رابط بومی جاوا (JNI) مرتبط با android.hardware استفاده می‌کند و در فهرست frameworks/base/core/jni/ قرار دارد. این کد کد بومی سطح پایین را برای دسترسی به سخت افزار حسگر فراخوانی می کند.

چارچوب بومی

فریم ورک بومی در frameworks/native/ تعریف شده است و معادل بومی بسته android.hardware ارائه می کند. چارچوب بومی، پروکسی‌های Binder IPC را برای دسترسی به خدمات خاص حسگر فراخوانی می‌کند.

بایندر IPC

پروکسی‌های Binder IPC ارتباط را بر روی مرزهای فرآیند تسهیل می‌کنند.

HAL

Sensors Hardware Abstraction Layer (HAL) API رابط بین درایورهای سخت افزار و چارچوب اندروید است. این شامل یک رابط HAL sensors.h و یک اجرای HAL است که ما به آن sensors.cpp می گوییم.

رابط توسط مشارکت کنندگان Android و AOSP تعریف شده است و پیاده سازی توسط سازنده دستگاه ارائه شده است.

رابط HAL حسگر در hardware/libhardware/include/hardware قرار دارد. برای جزئیات بیشتر به sensors.h مراجعه کنید.

چرخه انتشار

پیاده سازی HAL با تنظیم your_poll_device.common.version مشخص می کند که چه نسخه ای از رابط HAL را پیاده سازی می کند. نسخه‌های رابط HAL موجود در sensors.h تعریف شده‌اند و عملکرد به آن نسخه‌ها گره خورده است.

فریم ورک اندروید در حال حاضر از نسخه های 1.0 و 1.3 پشتیبانی می کند، اما به زودی نسخه 1.0 دیگر پشتیبانی نخواهد شد. این مستندات رفتار نسخه 1.3 را توصیف می کند که همه دستگاه ها باید به آن ارتقا دهند. برای جزئیات در مورد نحوه ارتقاء به 1.3، به حذف نسخه HAL مراجعه کنید.

درایور کرنل

درایورهای حسگر با دستگاه های فیزیکی تعامل دارند. در برخی موارد، اجرای HAL و درایورها موجودیت نرم افزاری یکسانی هستند. در موارد دیگر، یکپارچه ساز سخت افزار از سازندگان تراشه حسگر درخواست می کند تا درایورها را ارائه دهند، اما آنها هستند که اجرای HAL را می نویسند.

در همه موارد، اجرای HAL و درایورهای هسته بر عهده سازندگان سخت افزار است و اندروید رویکردهای ترجیحی برای نوشتن آنها ارائه نمی دهد.

هاب سنسور

پشته حسگر یک دستگاه می تواند به صورت اختیاری شامل یک هاب حسگر باشد که برای انجام محاسبات سطح پایین در توان کم در حالی که SoC می تواند در حالت تعلیق باشد مفید است. برای مثال، شمارش گام یا همجوشی حسگر را می توان روی آن تراشه ها انجام داد. همچنین مکان خوبی برای اجرای دسته‌بندی حسگر است، و FIFOهای سخت‌افزاری را برای رویدادهای حسگر اضافه می‌کند. برای اطلاعات بیشتر به Batching مراجعه کنید.

توجه: برای توسعه ویژگی‌های جدید ContextHub که از حسگرها یا LEDهای جدید استفاده می‌کنند، می‌توانید از Neonkey SensorHub متصل به برد توسعه Hikey یا Hikey960 نیز استفاده کنید.

اینکه هاب حسگر چگونه ساخته می شود به معماری بستگی دارد. گاهی اوقات یک تراشه جداگانه است و گاهی اوقات روی همان تراشه SoC قرار می گیرد. ویژگی مهم هاب سنسور این است که باید حافظه کافی برای دسته بندی داشته باشد و انرژی بسیار کمی مصرف کند تا امکان اجرای سنسورهای کم مصرف اندروید را فراهم کند. برخی از هاب‌های حسگر حاوی یک میکروکنترلر برای محاسبات عمومی و شتاب‌دهنده‌های سخت‌افزاری هستند که محاسبات توان بسیار کم را برای سنسورهای کم توان فعال می‌کنند.

نحوه معماری هاب حسگر و نحوه ارتباط آن با حسگرها و SoC (گذرگاه I2C، گذرگاه SPI، ...) توسط اندروید مشخص نشده است، اما باید هدف آن به حداقل رساندن مصرف کلی انرژی باشد.

یکی از گزینه هایی که به نظر می رسد تأثیر قابل توجهی بر سادگی پیاده سازی دارد، داشتن دو خط وقفه است که از هاب حسگر به SoC می رود: یکی برای وقفه های بیدار شدن (برای سنسورهای بیدار شدن) و دیگری برای وقفه های غیر بیدار. (برای سنسورهای غیر بیدار).

حسگرها

اینها تراشه های MEM فیزیکی هستند که اندازه گیری ها را انجام می دهند. در بسیاری از موارد، چندین حسگر فیزیکی روی یک تراشه وجود دارند. به عنوان مثال، برخی از تراشه ها شامل شتاب سنج، ژیروسکوپ و مغناطیس سنج هستند. (این تراشه ها اغلب تراشه های 9 محور نامیده می شوند، زیرا هر سنسور داده ها را در 3 محور ارائه می دهد.)

برخی از این تراشه ها همچنین دارای منطقی برای انجام محاسبات معمولی مانند تشخیص حرکت، تشخیص گام و همجوشی سنسور 9 محور هستند.

اگرچه الزامات و توصیه‌های قدرت و دقت CDD سنسور اندروید را هدف قرار می‌دهد نه حسگرهای فیزیکی، این الزامات بر انتخاب حسگرهای فیزیکی تأثیر می‌گذارد. به عنوان مثال، نیاز به دقت در بردار چرخش بازی، پیامدهایی بر دقت لازم برای ژیروسکوپ فیزیکی دارد. این بر عهده سازنده دستگاه است که الزامات حسگرهای فیزیکی را استخراج کند.