پشته سنسور

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

لایه‌ها و مالکان پشته حسگر اندروید

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

SDK

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

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

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

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

چارچوب

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

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

تأثیر مالتی‌پلکسینگ

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

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

همجوشی حسگر

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

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

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

زیر کاپوت

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

جی ان آی

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

چارچوب بومی

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

IPC بایندر

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

هال

رابط برنامه‌نویسی کاربردی لایه انتزاعی سخت‌افزار حسگرها (HAL) رابطی بین درایورهای سخت‌افزاری و چارچوب اندروید است. این رابط شامل یک رابط HAL به نام sensors.h و یک پیاده‌سازی HAL به نام sensors.cpp است.

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

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

چرخه انتشار

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

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

درایور هسته

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

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

هاب سنسور

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

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

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

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

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

حسگرها

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

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

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