Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Android HW-SW devt with virtual prototype (Part 3)

Posted: 26 Dec 2012     Print Version  Bookmark and Share

Keywords:hardware abstraction layer  sensors  debug  API 

Android provides a hardware abstraction layer (HAL) that facilitates communication between Android application framework and the hardware specific device drivers. This well-defined layer eliminates the need to modify the complex application framework when Android is being ported to a new device - ideally only the HAL needs to be updated in order to support the new hardware.

The HAL provides services to the upper layer, the Android application framework. At the same time it uses functions provided by the lower layer Linux device drivers. The HAL defines the API for almost all prominent device functions such as the camera, WiFi, radio, sensors etc. In our case study, we will take a look at the sensor HAL.

A HAL implementation looks similar to a Linux device driver. A defined structure specifies the type of HAL, version ID, and a title string as well as a pointer to the HAL specific access methods. An important method polls new sensor data and is triggered by the Android application framework when an application needs sensor data. In our case, this method needs read access to the pseudo file system provided by the sensor driver. The driver will trigger the sensor control sub-system and deliver the data back to the HAL so it can be used by the Android application.

The HAL module is compiled into a shared object that is dynamically loaded at runtime when needed. Unfortunately, this complicates debugging. The function addresses needed to set breakpoints are not known before the shared object is loaded. By using a VP we have a way to easily address this problem using the runtime scripting capability. The script needed to automatically load the symbol file and relocate it to the correct address will do the following:

 • Trigger a scripted callback procedure when the Android dynamic linker has finished loading a shared object, using a breakpoint/callback mechanism in the VP
 • Use the callback to determine the address and object file name using the register and virtual memory query functions provided by the VP scripting framework
 • Load the respective symbol file from the host and suspend the simulation so that the user can intercept further embedded software execution by setting a breakpoint in the shared object
 • The VDK comes with whole set of such convenient functions. The Android sensor HAL shared object now can be easily debugged. Android provides some test applications for the HAL and we are going to launch the sensor test using via "/system/bin/test-nusensors". Thus we can conduct side-by-side debugging of the user space HAL as well as the kernel sensor driver in the stop mode as shown in figure 1.
Jointly debugging user and kernel space is typically a big hassle. As soon as the kernel is suspended, the user space can no longer be debugged due to the fact that user space debugging is typically conducted in run-mode. Here, a debug server application is running on the target OS. If the OS is suspended through debugging the kernel, then the debug server application also is halted and cannot supply the debugger with information. As a consequence, the debugger hangs or exits with a connection time-out. On the other hand, if you do run-mode debugging, the only change you have make is to debug the driver via tracing or the "printk" debug messages. In the case of the VP, the debug server is part of the VP debug infrastructure. The debug server has access to the kernel as well as the user space and can therefore allow side-by-side debugging of the Android HAL and the kernel drivers.�It is even possible to also debug the sensor firmware and underlying hardware.

Coupling accelerometer with the real world
When using the VP for higher level software development or end-to-end testing, it is important that we supply real world data to the sensor. While it is easy to poke single data values into the sensor sub-system using the VP scripting infrastructure, it is not easy to create data streams that reflect a real scenario such as shaking the device, or moving the device from the table to the ear of the user. However, applications do require such data as they are highly context sensitive. For example, a core function of an application or library could be to detect that a phone is picked up in order to automatically answer the call. Therefore, the algorithm may need to analyse data from the accelerometer sensor, orientation sensor, etc.

Figure 1: Code-bugging Android HAL and Linux sensor driver.

Here, a VP can be extended with Virtual IO capabilities as shown in figure 1. In this case, the data is gathered from a generic real physical device and forwarded to the VP through dedicated APIs for communication with external applications.�In this case, we are using a Nintendo WiiMote controller in order to supply data to the sensor sub-system.

Figure 2: WiiMote Axis.


1 • 2 Next Page Last Page



Comment on "Android HW-SW devt with virtual prot..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top