Ab Februar 2025 Pflicht (EU AI Act): Anbieter und Betreiber von KI-Systemen müssen KI-Kompetenz nachweisen.
Alle Informatonen 
Porting an Android Embedded Setup
Apps

Android Sensor Integration Part 3: HAL

Lesezeit
4 ​​min

Notice:
This post is older than 5 years – the content might be outdated.

In the previous parts of this series we had a look at how a kernel driver works. This time we continue to better documented areas. While Google gave the design of the kernel module into the hands of the hardware manufacturers they define a clear interface for the Hardware Abstraction Layer (HAL). This is well documented with explanations of the most important functions, so in this article I will only delve into the lesser known parts.

Implementing a new Sensor Class

For HAL, the implementation is straight forward. Google provides an interface that needs to be implemented to access the existing infrastructure for sensors, called the SensorBase class. To use the interface, we need to write an abstract proximity sensor class that inherits from this base class. It supports all official sensor types Google defines; The proximity sensor class then manages the access to our kernel driver.

The first interesting part in this class is the constructor. On instance creation, the constructor of the base class is called. To do so we give the SensorBase class „SRF02 input event module“ as a second argument. This is the name we chose for our input events. SensorBase calls a private function which is looking for an entry in /dev/input that matches the given name and if it exists it returns a file descriptor. And just like that we have the first part of the connection to our kernel module.

We just set a few private variables such as mPendingEvent. That’s a structure of the type sensors_event_t for storing the various sensor data.

Turning on the hardware

Let’s continue to the last function called by the constructor. Basically  enable() works the same way we enabled our sensor in the last part of this series: Writing 1 or 0 to the sysfs file activates the implemented methods. The character array “sysfs“ contains the path to this file in the sysfs. We open this file and write the command to it as a string.

Catching the events

Let’s look at the most interesting part in this class: reading out the events generated in the kernel. To do so we use a class InputEventCircularReader. In the constructor we created an instance of this class called mInputReader. From this class we call the function fill() with the file descriptor we got for our entry in /dev/input. As long as input events are generated, we can fetch them with mInputReader.readEvent(&event). Now the events get evaluated by their types: EV_ABS stands for absolute values. If we get such an event it should have the event code ABS_DISTANCE that describes distances between the sensor and an interaction surface. In this case, the event should be one of those we generated in the kernel. The reading event contains the value of the last ranging, so in mPendingEvent we set the structure to store sensor data, some information about our sensor and the distance mentioned above. Event of the type EV_SYN are markers to separate events. With  mInputReader.next(); we continue to the next event.

Stay tuned

Almost there! In the final part we will learn how to connect our sensor to the Android Sensor Framework. Until then head over to our website to learn more about embedded development and the IoT.

The Whole Story

5 Kommentare

Hat dir der Beitrag gefallen?

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert