สแต็กเซ็นเซอร์

รูปภาพด้านล่างแสดงถึงสแต็กเซ็นเซอร์ของ Android คอมโพเนนต์แต่ละรายการ จะสื่อสารกับคอมโพเนนต์ที่อยู่เหนือและใต้คอมโพเนนต์นั้นโดยตรงเท่านั้น แม้ว่าเซ็นเซอร์บางตัว จะข้ามฮับเซ็นเซอร์ได้เมื่อมีฮับเซ็นเซอร์ การควบคุมจะไหลจาก แอปพลิเคชันลงไปยังเซ็นเซอร์ และข้อมูลจะไหลจากเซ็นเซอร์ขึ้นไปยัง แอปพลิเคชัน

เลเยอร์และเจ้าของสแต็กเซ็นเซอร์ Android

รูปที่ 1 เลเยอร์ของสแต็กเซ็นเซอร์ของ Android และเจ้าของเลเยอร์นั้นๆ

SDK

แอปพลิเคชันจะเข้าถึงเซ็นเซอร์ผ่าน API ของ Sensors SDK (Software Development Kit) SDK มีฟังก์ชันสำหรับแสดงรายการเซ็นเซอร์ที่พร้อมใช้งานและลงทะเบียนกับa เซ็นเซอร์

เมื่อลงทะเบียนกับเซ็นเซอร์ แอปพลิเคชันจะระบุความถี่ในการสุ่มตัวอย่างที่ต้องการ และข้อกำหนดด้านเวลาในการตอบสนอง

  • ตัวอย่างเช่น แอปพลิเคชันอาจลงทะเบียนกับตัวตรวจวัดความเร่งเริ่มต้น โดยขอเหตุการณ์ที่ 100Hz และอนุญาตให้รายงานเหตุการณ์โดยมีเวลาในการตอบสนอง 1 วินาที
  • แอปพลิเคชันจะได้รับเหตุการณ์จากตัวตรวจวัดความเร่งในอัตราอย่าง น้อย 100Hz และอาจล่าช้าได้สูงสุด 1 วินาที

ดูข้อมูลเพิ่มเติมเกี่ยวกับ SDK ได้ที่เอกสารประกอบสำหรับนักพัฒนาแอป

Framework

เฟรมเวิร์กมีหน้าที่ลิงก์แอปพลิเคชันหลายรายการกับ HAL HAL เองเป็นแบบไคลเอ็นต์เดียว หากไม่มีการมัลติเพล็กซ์ที่ระดับเฟรมเวิร์ก จะมีเพียงแอปพลิเคชันเดียวเท่านั้นที่เข้าถึงเซ็นเซอร์แต่ละตัวได้ในเวลาใดก็ตาม

ผลกระทบของการมัลติเพล็กซ์

ความจำเป็นในการมีเลเยอร์มัลติเพล็กซ์ในเฟรมเวิร์กอธิบายถึงการตัดสินใจออกแบบบางอย่าง

  • เมื่อแอปพลิเคชันขอความถี่ในการสุ่มตัวอย่างที่เฉพาะเจาะจง จะไม่มี การรับประกันว่าเหตุการณ์จะไม่มาถึงในอัตราที่เร็วกว่า หากแอปพลิเคชันอื่น ขอเซ็นเซอร์เดียวกันในอัตราที่เร็วกว่า แอปพลิเคชันแรกก็จะได้รับเหตุการณ์ในอัตราที่เร็วเช่นกัน
  • การรับประกันที่ขาดหายไปแบบเดียวกันนี้ใช้กับเวลาในการตอบสนองสูงสุดในการรายงานที่ขอด้วย: แอปพลิเคชันอาจได้รับเหตุการณ์โดยมีเวลาในการตอบสนองน้อยกว่าที่ขอมาก
  • นอกเหนือจากความถี่ในการสุ่มตัวอย่างและเวลาในการตอบสนองสูงสุดในการรายงานแล้ว แอปพลิเคชันยังกำหนดค่าพารามิเตอร์ของเซ็นเซอร์ไม่ได้ด้วย
    • ตัวอย่างเช่น ลองนึกภาพเซ็นเซอร์จริงที่ทำงานได้ทั้งในโหมด "ความแม่นยำสูง " และ "ประหยัดพลังงาน"
    • อุปกรณ์ Android จะใช้ได้เพียงโหมดใดโหมดหนึ่งเท่านั้น เนื่องจาก หากใช้ทั้ง 2 โหมด แอปพลิเคชันหนึ่งอาจขอโหมดความแม่นยำสูง และอีกแอปพลิเคชันหนึ่งอาจขอโหมดใช้พลังงานต่ำ ซึ่งเฟรมเวิร์กจะไม่มีวิธีตอบสนองความต้องการของทั้ง 2 แอปพลิเคชัน เฟรมเวิร์กต้องตอบสนองความต้องการของไคลเอ็นต์ทั้งหมดได้เสมอ ดังนั้นจึงไม่สามารถใช้ทั้ง 2 โหมดได้
  • ไม่มีกลไกในการส่งข้อมูลจากแอปพลิเคชันลงไปยังเซ็นเซอร์หรือ ไดรเวอร์ของเซ็นเซอร์ ซึ่งจะช่วยให้แอปพลิเคชันหนึ่งไม่สามารถแก้ไขลักษณะการทำงานของ เซ็นเซอร์จนทำให้แอปพลิเคชันอื่นๆ ทำงานผิดพลาด

การผสานรวมเซ็นเซอร์

เฟรมเวิร์กของ Android มีการใช้งานเริ่มต้นสำหรับเซ็นเซอร์แบบผสมบางตัว เมื่ออุปกรณ์มีไจโรสโคป ตัวตรวจวัดความเร่ง และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก แต่ไม่มีเซ็นเซอร์เวกเตอร์การหมุน เซ็นเซอร์แรงโน้มถ่วง และเซ็นเซอร์การเร่งความเร็วเชิงเส้น เฟรมเวิร์กจะใช้เซ็นเซอร์เหล่านั้นเพื่อให้แอปพลิเคชัน ยังคงใช้เซ็นเซอร์เหล่านั้นได้

การใช้งานเริ่มต้นไม่มีสิทธิ์เข้าถึงข้อมูลทั้งหมดที่การใช้งานอื่นๆ มีสิทธิ์เข้าถึง และต้องทำงานบน SoC จึงไม่แม่นยำและประหยัดพลังงานเท่ากับการใช้งานอื่นๆ ผู้ผลิตอุปกรณ์ควรกำหนดเซ็นเซอร์แบบผสานรวมของตนเอง (เวกเตอร์การหมุน แรงโน้มถ่วง และการเร่งความเร็วเชิงเส้น รวมถึงเซ็นเซอร์แบบผสมใหม่ๆ เช่น เวกเตอร์การหมุนของเกม) ให้มากที่สุดเท่าที่จะทำได้ แทนที่จะอาศัยการใช้งานเริ่มต้นนี้ นอกจากนี้ ผู้ผลิตอุปกรณ์ยังขอให้ผู้จำหน่ายชิปเซ็นเซอร์จัดหาการใช้งานให้ได้ด้วย

เราไม่ได้ดูแลรักษาการใช้งานการผสานรวมเซ็นเซอร์เริ่มต้น และ อาจทำให้อุปกรณ์ที่ใช้การใช้งานนี้ไม่ผ่าน CTS

ขั้นสูง

ส่วนนี้มีไว้เพื่อให้ข้อมูลเบื้องต้นแก่ผู้ที่ดูแลรักษาโค้ดเฟรมเวิร์กของ โครงการโอเพนซอร์ส Android (AOSP) ซึ่งไม่เกี่ยวข้องกับ ผู้ผลิตฮาร์ดแวร์

JNI

เฟรมเวิร์กใช้ Java Native Interface (JNI) ที่เชื่อมโยงกับ android.hardware และอยู่ในไดเรกทอรี frameworks/base/core/jni/ โค้ดนี้จะเรียกโค้ดแบบเนทีฟระดับล่าง เพื่อเข้าถึงฮาร์ดแวร์เซ็นเซอร์

เฟรมเวิร์กเนทีฟ

เฟรมเวิร์กเนทีฟกำหนดไว้ใน frameworks/native/ และมีฟังก์ชันเทียบเท่าเนทีฟ กับแพ็กเกจ android.hardware เฟรมเวิร์กเนทีฟจะเรียกพร็อกซี Binder IPC เพื่อเข้าถึง บริการเฉพาะของเซ็นเซอร์

Binder IPC

พร็อกซี Binder IPC ช่วยให้การสื่อสารข้ามขอบเขตของกระบวนการเป็นไปได้ง่ายขึ้น

HAL

API ของ Sensors Hardware Abstraction Layer (HAL) เป็นอินเทอร์เฟซระหว่าง ไดรเวอร์ฮาร์ดแวร์กับเฟรมเวิร์กของ Android ซึ่งประกอบด้วยอินเทอร์เฟซ HAL หนึ่งรายการ (sensors.h) และการใช้งาน HAL หนึ่งรายการที่เราเรียกว่า sensors.cpp

อินเทอร์เฟซกำหนดโดยผู้มีส่วนร่วมของ Android และ AOSP และการ ใช้งานจัดทำโดยผู้ผลิตอุปกรณ์

อินเทอร์เฟซ HAL ของเซ็นเซอร์อยู่ใน hardware/libhardware/include/hardware ดูรายละเอียดเพิ่มเติมได้ที่ sensors.h

ช่วงปล่อยเพลง

การใช้งาน HAL จะระบุเวอร์ชันของอินเทอร์เฟซ HAL ที่ ใช้งานโดยการตั้งค่า your_poll_device.common.version เวอร์ชันอินเทอร์เฟซ HAL ที่มีอยู่กำหนดไว้ใน sensors.h และฟังก์ชันการทำงานจะเชื่อมโยงกับเวอร์ชันเหล่านั้น

ปัจจุบันเฟรมเวิร์กของ Android รองรับเวอร์ชัน 1.0 และ 1.3 แต่จะเลิกให้การรองรับเวอร์ชัน 1.0 ในเร็วๆ นี้ เอกสารนี้อธิบายลักษณะการทำงานของเวอร์ชัน 1.3 ซึ่งอุปกรณ์ทั้งหมดควรอัปเกรดเป็นเวอร์ชันนี้ ดูรายละเอียดเกี่ยวกับวิธีอัปเกรดเป็น เวอร์ชัน 1.3 ได้ที่การเลิกใช้งานเวอร์ชัน HAL

ไดรเวอร์เคอร์เนล

ไดรเวอร์เซ็นเซอร์จะโต้ตอบกับอุปกรณ์จริง ในบางกรณี การใช้งาน HAL และไดรเวอร์เป็นเอนทิตีซอฟต์แวร์เดียวกัน ในกรณีอื่นๆ ผู้ผสานรวมฮาร์ดแวร์จะขอให้ผู้ผลิตชิปเซ็นเซอร์จัดหา ไดรเวอร์ให้ แต่ผู้ผสานรวมฮาร์ดแวร์จะเป็นผู้เขียนการใช้งาน HAL

ไม่ว่ากรณีใดก็ตาม การใช้งาน HAL และไดรเวอร์เคอร์เนลเป็นความรับผิดชอบของผู้ผลิตฮาร์ดแวร์ และ Android ไม่ได้ระบุแนวทางที่แนะนำในการเขียนการใช้งานและไดรเวอร์

ฮับเซ็นเซอร์

สแต็กเซ็นเซอร์ของอุปกรณ์อาจมีฮับเซ็นเซอร์ (ไม่บังคับ) ซึ่งมีประโยชน์ในการ ทำการคำนวณระดับต่ำบางอย่างโดยใช้พลังงานต่ำ ขณะที่ SoC อยู่ใน โหมดพัก ตัวอย่างเช่น การนับก้าวหรือการผสานรวมเซ็นเซอร์สามารถทำได้บน ชิปเหล่านั้น นอกจากนี้ ฮับเซ็นเซอร์ยังเป็นตำแหน่งที่ดีในการใช้การจัดกลุ่มเซ็นเซอร์ โดยการเพิ่ม FIFO ของฮาร์ดแวร์สำหรับเหตุการณ์ของเซ็นเซอร์ ดูข้อมูลเพิ่มเติมได้ที่การจัดกลุ่ม

หมายเหตุ: หากต้องการพัฒนาฟีเจอร์ ContextHub ใหม่ที่ ใช้เซ็นเซอร์หรือ LED ใหม่ คุณยังใช้ Neonkey SensorHub ที่เชื่อมต่อกับ บอร์ดพัฒนา Hikey หรือ Hikey960 ได้ด้วย

ลักษณะของฮับเซ็นเซอร์ขึ้นอยู่กับสถาปัตยกรรม บางครั้งฮับเซ็นเซอร์เป็นชิปแยกต่างหาก และบางครั้งก็รวมอยู่ในชิปเดียวกับ SoC ลักษณะสำคัญ ของฮับเซ็นเซอร์คือควรมีหน่วยความจำเพียงพอ สำหรับการจัดกลุ่มและใช้พลังงานน้อยมากเพื่อให้สามารถใช้เซ็นเซอร์ Android ที่ใช้พลังงานต่ำ ได้ ฮับเซ็นเซอร์บางตัวมีไมโครคอนโทรลเลอร์สำหรับการคำนวณทั่วไป และตัวเร่งฮาร์ดแวร์เพื่อให้สามารถคำนวณโดยใช้พลังงานต่ำมากสำหรับ เซ็นเซอร์ที่ใช้พลังงานต่ำ

Android ไม่ได้ระบุสถาปัตยกรรมของฮับเซ็นเซอร์และวิธีที่ฮับเซ็นเซอร์สื่อสารกับเซ็นเซอร์ และ SoC (บัส I2C, บัส SPI, …) แต่ควรมีเป้าหมาย เพื่อลดการใช้พลังงานโดยรวม

ตัวเลือกหนึ่งที่ดูเหมือนจะมีผลอย่างมากต่อความเรียบง่ายในการใช้งาน คือการมีสายสัญญาณอินเทอร์รัปต์ 2 เส้นจากฮับเซ็นเซอร์ไปยัง SoC: โดยเส้นหนึ่งสำหรับอินเทอร์รัปต์การปลุก (สำหรับเซ็นเซอร์การปลุก) และอีกเส้นหนึ่งสำหรับอินเทอร์รัปต์ที่ไม่ใช่การปลุก (สำหรับเซ็นเซอร์ที่ไม่ใช่การปลุก)

เซ็นเซอร์

เซ็นเซอร์คือชิป MEMs จริงที่ทำการวัด ในหลายกรณี จะมีเซ็นเซอร์จริงหลายตัวอยู่ในชิปเดียวกัน ตัวอย่างเช่น ชิปบางตัว มีตัวตรวจวัดความเร่ง ไจโรสโคป และเครื่องวัดค่าความเข้มข้นของสนามแม่เหล็ก (ชิปดังกล่าวมัก เรียกว่าชิป 9 แกน เนื่องจากเซ็นเซอร์แต่ละตัวให้ข้อมูลผ่าน 3 แกน)

ชิปบางตัวยังมีตรรกะบางอย่างเพื่อทำการคำนวณตามปกติ เช่น การตรวจจับการเคลื่อนไหว การตรวจจับก้าว และการผสานรวมเซ็นเซอร์ 9 แกน

แม้ว่าข้อกำหนดและคำแนะนำด้านพลังงานและความแม่นยำของ CDD จะกำหนดเป้าหมายไปที่ เซ็นเซอร์ Android ไม่ใช่เซ็นเซอร์จริง แต่ข้อกำหนดเหล่านั้นก็ส่งผลต่อการ เลือกเซ็นเซอร์จริง ตัวอย่างเช่น ข้อกำหนดด้านความแม่นยำของเวกเตอร์การหมุนของเกม ส่งผลต่อความแม่นยำที่จำเป็นสำหรับไจโรสโคปจริง ผู้ผลิตอุปกรณ์มีหน้าที่กำหนดข้อกำหนดสำหรับ เซ็นเซอร์จริง