The Code Artist

[patch] [resend] Preparing a modified patch

2012-02-11T17:14:00.000+05:30

In case of any collaborated project (eg. linux-kernel), often after submitting a patch for review, we often receive several comments and need to make appropriate changes and generate a new "version2" of the patch containing the changes. If we are using Git for revision control, then the entire process becomes a snap.

How to prepare a modified patch for resend in 5 easy steps:

STEP1.


git rebase -i <commit-id-just-before-our-changes>

STEP2.
As discussed in the review, make the new changes to the source-files.

STEP3.


git add <modified-filenames>

STEP4.


git commit --amend

(shows editor with original commit-msg)
Edit the commit-msg (or leave as-is) and quit.
New commit is generated in the place of old commit.

STEP5.


git format-patch HEAD~1

DONE!! New patch version2 is ready for review now. :-)

If we do a diff between the PREV and NEW patch, we can see :

+ Changes made after review.

+ Time-Stamp change.

+ Hash change.

Android Sensors and Location based services

2012-01-14T20:10:00.000+05:30

Here is the talk i presented about Sensors and location based services on Android at B.A.(U).G / BLR-DROID. Felt awesome talking to people, answering Qs about nGPS.

Download Sensors and location based services on Android

Booting Android completely over ethernet

2011-12-28T19:44:00.005+05:30

When developing embedded-systems, initial development stages often involve huge number of "Modify-Build-Flash-Test" cycles. Test-Driven-Development methodology further promotes this style of development. This leads to a break in the "flow" at the Flash stage. Flashing the device with a newly built set of binaries interrupts the otherwise smooth "Modify-Build-Test" flow. Also errors tend to creep-in in the form of an older binary being copied/flashed, often causing confusion during debugging and endless grief to the developer.

A simple way to avoid this is to have the binaries on the host-machine (a PC) and boot the embedded device directly using those binaries. In case of Android embedded system development, these binaries are the Linux-Kernel and the Android filesystem image.

Pre-requisites:

The embedded device

A linux PC

Ethernet connectivity between the two

NOTE: Below listed parts 1, 2 & 3 involve setting-up the "host" Linux PC. Part 4 describes configuring the device to boot directly using the binaries present on the "host". It is assumed that a functional bootloader (u-boot) is present on the device (internal-flash/mmc-card) and that ethernet-support(either direct or over usb) is enabled.

Part1: Linux kernel over tftp

1. Install tftpd and related packages

host-PC$ sudo apt-get install xinetd tftpd tftp

2. Create /etc/xinetd.d/tftp

host-PC$ cat <<EOF | sudo tee /etc/xinetd.d/tftp
service tftp
{
    protocol        = udp
    port            = 69
    socket_type     = dgram
    wait            = yes
    user            = nobody
    server          = /usr/sbin/in.tftpd
    server_args     = /srv/tftp
    disable         = no
}
EOF

3. Make tftp-server directory

host-PC$ mkdir <tftp-server-path> 



host-PC$ chmod -R 777 <tftp-server-path> 



host-PC$ chown -R nobody <tftp-server-path>

4. Start tftpd through xinetd

host-PC$ sudo /etc/init.d/xinetd restart
This concludes the tftp part of the setup process on the host.

Part2: Android fs over NFS

1. Install nfs packages

host-PC$ sudo apt-get install nfs-kernel-server nfs-common

2. Add this line to /etc/exports

<rootfs-path> *(rw,sync,no_subtree_check,no_root_squash)

3. Restart service

host-PC$ sudo service nfs-kernel-server restart

4. Update exports for the NFS server

host-PC$ exportfs -a

5. Check NFS server

host-PC$ showmount -e

If everything went right, the <rootfs-path> will be listed in the output of showmount.

Part3: Where to put the files

1. Linux Kernel uImage

On the "host" PC,
Copy the Linux-Kernel uImage into <tftp-server-path>

2. Android rootfs

On the "host" PC,
Copy the contents of the Android rootfs into <rootfs-path>

Part4: Configuring the bootloader

1. Update bootargs

Connect the embedded device to the host-PC over ethernet (either directly or via a switch/router) and power it on. As shown below, configure the bootloader to pick-up the kernel from the host-PC over tftp and to mount the filesystem from the host-PC over NFS. As both support configuring a static-ip for the embedded-device or obtaining one dynamically using dhcp, 4 combinations are possible (2 shown below).

nfs(static-ip) and tftp(dhcp)

U-Boot# setenv bootargs 'console=ttyO0,115200n8 androidboot.console=ttyO0 mem=256M root=/dev/nfs ip=<client-device-ip> nfsroot=<nfs-server-ip>:<rootfs-path> rootdelay=2' 



U-Boot# setenv serverip 'host-pc-ip'



 U-Boot# bootm <Load address>

nfs(dhcp) and tftp(static-ip)

U-Boot# setenv bootargs 'console=ttyO0,115200n8 androidboot.console=ttyO0 mem=256M root=/dev/nfs ip=dhcp nfsroot=<nfs-server-ip>:<rootfs-path> rootdelay=2'



U-Boot# setenv serverip 'host-pc-ip'



U-Boot# setenv ipaddr 'client-device-ip'



U-Boot# tftp 



U-Boot# bootm <Load address>

2. Boot ;-)

Linux-Kernel loaded over tftp

Filesystem mounted over NFS

Why __read_mostly does NOT work as it should

2011-12-01T08:32:00.000+05:30

( OR Why linux does NOT implement __read_mostly for ARM )

In modern SMP(multicore) systems, any processor can write to a memory location. The other processors have to update their caches immediately. For that reason, SMP systems implement the concept of "cacheline bouncing" to move "ownership" of cached-data between cores. This is effective but expensive.

Individual cores have private L1 caches which are extremely faster than the L2 and L3 caches which are shared between multiple cores. Typically, when a memory location is going to be ONLY read repeatedly, but never written to (for example a variable tagged with the const modifier), each core on the SMP system can safely store its own copy of that variable in its private(non-shared) cache. As the variable is NEVER written, the cache-entry never gets invalidated or "dirty". Hence the cores never need to get into "cache line bouncing" for that variable.

Take the case of the x86 architecture,

An Intel core i5 die showing the various caches present

[NON-SMP] Intel Pentium 4 processor has to communicate between threads over the front-side bus, thus requiring at least a 400-500 cycle delay.
[SMP] Intel Core processor family allowed for communication over a shared L2 cache with a delay of only 20 cycles between pairs of cores and the front-side bus between multiple pairs on a quad-core design.
[SMP] The use of a shared L3 cache in the Intel Core i7 processor means that going across a bus to synchronize with another core is NEVER required unless a multiple-socket system is being used.

The copies of "read-only" locations usually end-up being cached in the private caches of the individual cores, which are several orders of magnitude faster than the shared L3 cache.

How __read_mostly is supposed to work:

When a variable is tagged with the __read_mostly annotation, it is a signal to the compiler that accesses to the variable will be mostly reads and rarely(but NOT never) a write.

All variables tagged __read_mostly are grouped together into a single section in the final executable. This is to improve performance by allowing the system to optimise access time to those variables in SMP systems by allowing each core to maintain its own copy of them variable in it local cache. Once in a while when the variable does get written to, "cacheline bouncing" takes place. But this is acceptable as the the time spent by the cores constantly synchronising using locks and using the slower shared-cache would be far more than the time it takes for the multiple cores to operate on own copies in their independent caches.

What actually happens:
The problem with the above approach is that once all the __read_mostly variables are grouped into one section, the remaining "non-read-mostly" variables end-up together too. This increases the chances that two frequently used locations (in the "non-read-mostly" region) will end-up competing for the same position in the cache. Thus frequent accesses will cause excessive cache thrashing thereby degrading the overall system performance.

This situation is slightly alleviated by the fact that modern cpu caches are mostly 8way or 16way set-associative. In a 16way associative cache, each location has a choice of 16 different cache-slots. This means that two very frequently accessed memory-locations, though closely located in memory, can still end-up in 2 different slots in the cache, thereby preventing cache-thrashing (which would have occurred had both continued competing for the same cache-slot). In other words a minimum of 17 elements frequently accessed and closely located in memory are required for 2 of them to begin competing for a common cache-slot.

While this is true in the case of INTEL and its x86 architecture, ARM still sticks to 4way & 2way set-associative caches even in its latest CortexA9 & A15 offerings; which means that just 3 or 5 closely located, frequently accessed elements can result in cache-thrashing on an ARM system. This is probably why __read_mostly is NOT implemented for the ARM architecture in the linux-kernel:

kernel/arch/x86/include/asm/cache.h contains


#define __read_mostly __attribute__((__section__(".data..read_mostly")))

kernel/arch/arm/include/asm/cache.h: does NOT, thereby defaulting to the empty definition in
kernel/include/linux/cache.h


#ifndef __read_mostly
#define __read_mostly
#endif

With the number of cores increasing rapidly and the on-die cache size growing slowly, one must always aim to:

Minimise access to the last level of shared cache to improve performance on multicore systems.
Increase associativity of private caches (of individual cores) to eliminate cache-slot contention and reduce cache-thrashing.

nGPS : Location fix without GPS

2011-11-28T14:46:00.001+05:30

NOTE: Skip this post if you do NOT live on planet earth.

This is one of the ideas that i hit upon when preparing for a talk Sensors on Android @DroidCon2011. It is an unusual application of the on-board sensors present most Android devices. Due to lack of time i was unable to present it in much detail during my talk. So here goes...

nGPS (NO GPS) is a way of obtaining a location fix without using any GPS, AGPS, Wi-Fi Positioning and cell-site triangulation technologies.

Why would anyone want to use nGPS

- Pure GPS based systems take upto 10mins for 1st fix.

- AGPS, Wi-Fi positioning require an active data-connection.

- Cell-site triangulation requires network coverage.

So without any of these technologies at our disposal, how do we obtain a "location-fix" i.e. a latitude-longitude pair representing our current position. The answer lies in the magnetic-field sensor.

The Earth's magnetic field, as measured by a magnetic sensor on the Earth's surface, is combination of of several magnetic fields generated by various sources. These fields interact with each other and the net resultant what the magnetic sensor measures.

World Magnetic Model (WMM)

Major contributors to a magnetic-field:

+ Conducting, fluid outer core.
+ Earth's crust and upper mantle.
+ Electrical currents in the atmosphere.

+ Local magnetic interference.

By filtering the local magnetic interference due to other electronic/electrical devices, we have a unique magnetic-field signature present at each place on earth. The WMM aims to provide an accurate estimate of this field. A device (having a magnetic sensor) can measure the components of this field. Then comparing it with the WMM values of the earth's field, one can identify the latitude/longitude of the present location.

Android contains built-in support for the WMM using the GeomagneticField class. The GeomagneticField class utilises the WMM internally to provide an estimated magnetic field at any given point on Earth at a given time. The important thing to note is that this class accepts the location (alongwith altitude and time) and provides the expected magnetic-field at that position (at that particular altitude and instant of time).

To determine the location using the GeomagneticField class, requires some reverse-lookup trickery on our part. More on it in another post.

UPDATE : A recent talk on Sensors and Location based services on Android at blr-droid meetp#12 featuring nGPS among other things.

Tonight's the night : ICS

2011-11-22T14:22:00.001+05:30

Two weeks after ICS was released, finally synced-up the entire source. 6GB.
Gave a repo sync and woke-up and it was done! Sweet na?...

A good thing with ICS is that pandaboard is supported as-is.
This means that i can...

$ source build/envsetup.sh
$ lunch full_panda-eng
$ make -j4

...and i'm done! :-)

And so i have. Estimating 4hrs for a build on my "old" pc.
Tonight's the night... ;-)

Sensors on Android @ DroidCon2011

2011-11-18T22:33:00.001+05:30

Here is the talk i presented @ DroidCon2011

Download Sensors on Android @ DroidCon2011

Gathered lots of inspiration talking (and listening) to several bright minds @DroidCon2011. Will be posting a "few" of them here. So subscribe to TheCodeArtist or take a quick peek here.

Chocosticks

2011-11-06T17:23:00.001+05:30

More info at code.google.com/p/chocosticks

AI : Heuristics

2011-09-30T15:49:00.000+05:30

Programming artificial intelligence into a piece of code is NOT about anticipating every single thing that can possibly happen. A heuristic approach is more practical to implement. Implementing a heuristic model has an added advantage that the system improves every time it is run.

Missed Part1 of this series? AI: Artificial or Actual intelligence

Heuristics (meaning "to find" or "discover") refers to techniques for learning, discovery and problem solving. Heuristic methods are used to speed up the process of finding a satisfactory solution. When an exhaustive search is impractical.

Implementing a heuristic model:

1. Setup a generic system that runs by a "rulebook".

The "rulebook" contains set of very simple rules to start with.

2. Design a "playbook" which is easily extensible.

Use arrays, linked-lists, b-trees, tables, a relational-database,... Anything. Just remember that the "playbook" is going to grow very fast. Eventually it will contain ALL the rules & tactics that exist.

3. Let the system run-wild.

At each turn, the system follows the existing rules in the "rulebook". It picks the best move applicable in the current context from the "playbook" At the end of each run, save the moves & the outcome to the "playbook" for reference in the next runs.

Thus the code "learns" the consequences of each move and gradually evolves (into something better) with each run. Care should be taken to formulate the "rulebook". It must be carefully devised to prevent the AI system from performing any illegal moves.

Additional points of interest:

Pruning : Removing obsolete/duplicate entries from the rulebook.
- Reduces the "rulebook" size. Leads to faster decision making.
Character traits : Aggressive, defensive, favorite moves etc.
- Useful in games. To provide multiple opponents.
Realistic AI : Possible to trick AI into making occasional mistakes.
- Again useful in games. Makes gameplay more realistic & fun.

Simulating keypress events on Android

2011-03-17T20:22:00.025+05:30

Modern day smart-phones have already begun to migrate from the traditional "a-button-for-every-need" approach to the "huge-display-cum-touchscreen" form-factors. Android phones are no exception. But, traditional buttons are still reqd. for a few oft used functions (power,back,home,menu etc.) And smart-phones continue to have them alongwith the primary touch-based-UI.

Android-OS provides a very easy method to simulate key/button press/release events via software. You might ask why do we need a software to generate the events when a hardware button is already present on the device. Here's why:

During development/testing of the button-drivers itself.
To implement automated rigorous tests. ( MonkeyTest? )
To implement/interface additional custom software keyboards.
Just because we can!

The reason why i am doing it today is REASON NUMBER 4.

Now, the basic goal of this exercise is extremely simple:

Q. How to generate a hardware-button-press event
WITHOUT actually pressing any key on the device?

Let us first understand what happens when a hardware button is pressed. Here is what happens when you press a button on an Android device:

The h/w button triggers an interrupt.
The ISR of the corresponding driver gets called (in kernel).
In the ISR, the driver generates an input-event.
Android-framework (in userspace) gets the notification of the event.
Android reads the input-event code & type.
Compares it with the proper "keymap/keylayout" file.
The proper button is identified.

To simulate button presses we enter this procedure at STEP3.

Instead of the regular driver generating the input-event, we generate an input-event ourselves using a pre-built userspace binary. This will then be notified to the Android-framework and the rest continues as above.

So now all depends on the the pre-built userspace binary, which is...
[ drum-roll... ]

...Input. (How convenient!) The syntax of input is as follows:

input keyevent <event_code>

Now, before we try to send any keyevent, we need to find out the event-code that maps to the h/w key we want to simulate. The following table summarizes all the supported keycodes in Android:

Additionally we can look up the keylayout (.kl) file on the device. Personally, I find keylayout a misnomer, as we are not talking about different keyboards here, but different mappings of an input-event-value to its functionality.

Anyways you can always find the file in system/usr/keylayout/xyz.kl

NOTE: For each keyboard device xyz, the android.keylayout.xyz system property must be set. If a keylayout file is not specified, Android will default to /system/usr/keylayout/qwerty.kl

Now to generate a event of a specific keycode, we simply execute this on the terminal/serial console:

input keyevent <keycode>

The value of keycode can be any of the integer values from the above table. In case a serial-console is NOT available on your device, you can always run the command via adb as follows:

adb shell input keyevent <keycode>

That's how a hardware-button-press is simulated in software!!

Quilt : This patch can be reverse applied

2011-03-17T16:30:00.007+05:30

Quilt is a very sweet little tool. Very easy for generating & maintaining a series of patches to your code. Anyone involved in even a moderate bit of quilting will often come across this message especially when trying to apply imported patches.

Patch <patch-name here> can be reverse-applied

What exactly does this message mean?

Quilt is basically trying to tell us that ALL the changes in the patch (we are trying to apply) are already present in our code.The term "reverse-applied" seems to be derived from some other version-control system.

How-To Resolve this error?...

Simply comment the patch file in the series file as follows:



prev patch file

#current patch file    <-- this patch can be reverse-applied.

next patch file1

next patch file2

This effectively means that since all the changes provided by this patch are already present in your existing code, you are ignoring this patch completely and moving on to the next patch in the series.

Read more about quilt here.

UPDATE:
Also one can use the patch -R command to reverse-apply
(i.e. revert) the patch. This is equivalent to removing the changes made by the patch, without altering the series.
(i.e. without quilt in the picture.)

After the patch -R command succeeds, then quilt push should work well and add the changes back and proceed to the next patch-file in the series.

Read more about patch here.

Proximity Sensor on Android Gingerbread

2011-01-12T16:27:00.006+05:30

The proximity sensor is common on most smart-phones, the ones that have a touchscreen. This is because the primary function of a proximity sensor is to disable accidental touch events. The most common scenario being- The ear coming in contact with the screen and generating touch events, while on a call.

To solve the "I didn't take that stupid picture, my ear did" issue, device manufacturers came up with the idea of a placing a proximity sensor close to the speaker, which will then detect any object in the vicinity of the speaker. If any object is present (ex. user's ear), then the touch events can be assumed to be accidental & ignored.

Now there are various technologies for proximity sensing:

Electrical (Inductive, Capacitive)
Optical. (IR, Laser)
Magnetic.
Sonar.

Of all these, the most non-intrusive and low-cost modules are the optical proximity sensors. These can detect bodies in the vicinity of the device upto 5cm. This is perfect for use on smart-phones.

Coming to Sensors on Android-Gingerbread, the proximity sensor is often implemented using a light sensor chip. Common ones are ISL29003/23 & GP2A by Intersil & Sharp respectively. Both these sensor-chips are primarily active light sensors, which provide the ambient light intensity in LUX units.

The distance value is measured in centimeters. Note that some proximity sensors only support a binary "close" or "far" measurement. In this case, the sensor should report its maxRange value in the "far" state and a value less than maxRange in the "near" state.

Let us take an example. Say the device uses a GP2A chip placed close to the speaker facing the user (as shown in the adjoining pic). The normal light response of the GP2A is such that it triggers a proximity-detect interrupt at a distance of approximately 5cms in normal lighting.

This means that when the user receives a call and brings the phone closer to his ear, the ambient-light around the light/proximity-sensor slowly drops down below the threshold & the sensor detects this and switches the state from FAR to NEAR. This event can be detected by any android application which has registered a SensorEventListener.

In most Android phones, the proximity sensor is implemented as a boolean-sensor. Its returns just two values "NEAR" & "FAR". Thresholding is done on the LUX value i.e. the LUX value of the light sensor is compared with a threshold. A LUX-value more than threshold means the proximity sensor returns "FAR". Anything less than the threshold value and the sensor returns "NEAR". The actual value of threshold is custom-defined depending on the sensor-chip in use and its light-response, coupled with the location & orientation of the chip on the smart-phone body.

The proximity sensor is implemented very much like the other sensors except on one critical point -

Proximity sensor is interrupt-based (not Poll-based).

All the other sensors are polled for at regular intervals, selected by the DELAY parameter used while registering a SensorEventListener. Proximity Sensor is interrupt based (NOT polling). This means that we get a proximity event only when the proximity changes (either NEAR to FAR or FAR to NEAR).

__________________________

AI : Artificial or Actual Intelligence

2011-01-03T11:14:00.006+05:30

Here is a question for the programmer in you:

Q. How do you write a program that writes itself ?

NOTE: The following article is NOT about quines.

Now coming back to the question, let us think for a moment. do we really need a program that can write itself. Or to put it more precisely, In what scenario is a self-modifying piece of code better than one which is not?

The first obvious scenario that comes to mind is that : Catching Run-time Errors.
Currently there are two schools of thought on the whole run-time issue scene.

Run-Time errors are critical and must and should be identified & fixed.
There is no such thing as a Run-Time error.
( There are only Exceptions ;) )

The first school of thought is very harsh on developer. It expects developers to foresee the program's future and code in such a manner so as to be able to handle ANY situation that may arise ( however rarely). This also encourages Test-Driven programming which is sloppy to say the least. With every test-cycle discovering a series of "bugs" (that occur once 1 say 10,000 iterations) & adding a series of "minor" patches or fixes for each. By the time the code is considered "ready", its hardly efficient any more. Often the patches outnumber the original code itself.[1] This goes to show that the "ready" code doesn't do its job efficiently, but also more importantly, no longer does it do what it was originally intended to. You don't take a F1 car and add a tanker-trailer to carry gasoline just in case it runs out. Proper design is a prerequisite and oft ignored phase in most development projects [2].

In the second school of thought, we find die-hard fans and wannabe fan-boys of languages like JAVA that allow a developer to get away with anything and everything, as long as he feels comfortable doing it the way it is done. A guy trained in this school of thought will firmly believe that-

If a tree was going to fall, and you knew it would fall,
then hey! its not a problem anymore. Its expected behavior!

Rather than preventing the tree from falling,
you gently step aside & wait for it to fall...

...and then proceed [3].

try {
    tree = forest.tree;
    if (tree.falling() == 1) {
        throw new TreeFallingException("RUN!");
    }
    console.printLine("All iz well");

} catch (TreeFallingException e) {
    console.printLine("RUN! RUN! RUN!");

} catch (Exception err) {
    console.printLine("No tree, But RUN! " + err.WhyToRun());

} finally {
    console.printLine("THE-END");
}

As we see, neither approach is perfect and both have their disadvantages.

Enter A.I. ...
Imagine a platform where you have infinite memory. Now add infinite processing power to your kitty. With these two in your pocket, you can write a program to do pretty much anything, right? So whats the catch you might ask.
That IS THE catch? Your program has to be able to do EVERYTHING!

More on this in a latter post.

To wrap-up:

Q. How do you write a program that writes itself ?
ANS: Quite simply, You don't! ;-)

Read part2 of this series AI: Heuristics

Footnotes:

[1] Each patch to the applied to the code is the evolving code itself. But developer intervenes individually.

[2] Today's average developer, having been exposed to the horrors of coding a poor design, is in a position to understand the problems of not spending enough time in the design phase. But, Its often the tightly constrained project schedules and the uncertainty associated with new-technologies that mean that there is never enough time dedicated to the design-phase.

[3] Each catch-block added to the code is the evolving code itself. Again here the developer intervenes.

Sensors on Android Gingerbread

2010-12-24T16:00:00.003+05:30

Android 2.3 (codename Gingerbread) was officially released amidst huge hype and fanfare last week and BOY O BOY!! people sure are queuing-up to have a peek. Sensors were the most hyped about sub-system.

Just google-search "Android Gingerbread" & you will see a host of results of this pattern:

The big news in Android 2.3 Gingerbread
Support for new sensors

Android-Fans sure are blogging everywhere about the enhanced support for "NEW" sensors on gingerbread. But having worked on Android sensors since the days of cupcake, I beg to differ...

Gingerbread does NOT support any NEW sensors!

Here is what Android has to say in the official Gingerbread release notes.

Native input and sensor events
Applications that use native code can now receive and process input and sensor events directly in their native code, which dramatically improves efficiency and responsiveness.
Native libraries exposed by the platform let applications handle the same types of input events as those available through the framework. Applications can receive events from all supported sensor types and can enable/disable specific sensors and manage event delivery rate and queueing.

Gyroscope and other new sensors,
for improved 3D motion processing
Android 2.3 adds API support for several new sensor types, including gyroscope, rotation vector, linear acceleration, gravity, and barometer sensors. Applications can use the new sensors in combination with any other sensors available on the device, to track three-dimensional device motion and orientation change with high precision and accuracy. For example, a game application could use readings from a gyroscope and accelerometer on the device to recognize complex user gestures and motions, such as tilt, spin, thrust, and slice.

That IS quite a mouthful. But stripping-off the marketing-spiel we can say:

Gingerbread provides sensors-support to native C/C++ apps.
Gingerbread provides more accurate and precise sensor-data.
Gingerbread provides APIs to recognise complex user gestures.
Gingerbread supports gyroscope and barometer.

Real Sensors map 1-to-1 to actual Hardware.
Data of Virtual Sensors, on the other hand,
is exported to the apps by performing
calculations on 1(or more) real sensors.

While points [1], [2], [3] do mention tremendous improvements over FroYo, none of them has to do anything with any new sensors. Moving on to [4] we see the first mention of supposedly new sensors. But, here are two things that most people overlook:

- Both Gyroscope and Barometer (i.e. pressure) sensors were already available in previous releases of Android.

- The 4 "NEW" sensors (shown alongside) are just wrapper-APIs around existing hardware. They just provided "easy-to-digest" data.

These newly introduced wrapper-APIs process the raw sensor data into a format ready to use by the Android apps. This proves especially useful to the apps doing advanced 3D math. ( read Games ;) )

Gyroscope sensor was supported in FroYo and so was Barometer. Since it was early days for Android sensors not much attention was paid to them. Maybe even added as an afterthought to the existing array of Accelerometer,Compass,Orientation.

With Android apps ( again read Games ;) ) really pushing them to the limit, the limitations of a "pure" accelerometer device became evident.

Step-In INVENSENSE...

Founded in 2003, InvenSense is based in Sunnyvale, California, Invensense is a market-leader in advanced MEMS gyroscope design. Their latest offering (based on SensorFusion technology) is a MotionProcessing library i.e. MPL on Android Gingerbread.

Apart from the rudimentary API which Android provided, Invensense Motion-Processing Library(MPL) sits alongside the Sensor-HAL and provides a feature-rich API to obtain Gestures, Glyphs & Pedometer data from sensors.

All this data is derieved from a combination of Accelerometer/Gyroscope/Compass hardware modules. The MPL processes the individual data and combines them appropriately to overcome the individual limitations of each sensor & provide an overall better stream of precise & accurate (processed)samples. Also Advanced operation/Pattern-matching & count is done by the MPL and any app can then directly obtain data pertaining to gestures or step-counts(pedometer) etc. using the MPL APIs.

Here is a "short" video by David Sachs(Invensense Tech) which explains the advantages of INVENSENSE MPL extensions on Android...

To conclude, one can say that the Sensor sub-system has undergone a huge overhaul in Gingerbread. And one can only hope that what it delivers is well worth all the hyped-up expectations.

_________________________

Related Posts:

Proximity Sensor on Android

Bachelor of (Reverse) Engineering

2010-09-14T11:47:00.006+05:30

Just a thought - What makes newly graduated engineers (or "freshers" in layman terms) such bad programmers. Why is it that in the IT industry, experience counts more than anything else! Why is it that companies spend so much in training recently graduated engineers "freshers". More simply put,

Q. What is the main difference between a
"brilliant fresher" and an "experienced pro"?

The answer lies in the following fact. Most of what is taught in undergraduate courses (BE/B.Tech) is irrelevant to what one actually ends up doing as a "fresher" programmer. No one in his/her right mind would tell a fresher to design the framework of a new module. Also a programmer never has to write fresh code from scratch. The job at hand is, almost always, to fix bugs in existing code and sometimes to add a few "features" to existing software.
This means the good programmer needs to be:

Good at reading code quickly.
Good at identifying the relevant parts quickly.
Good at understanding code quickly.

It might be surprising to know, but seldom are these emphasized enough. Rarely does any "fresher" ever focus on these aspects. Instead you will always find one totally engrossed in any of the following:

Writing code as efficiently as possible.
Writing it so that it is easier to understand.
Writing it in newer languages.
Writing code using newer IDEs.

Ask any "fresher" whats so special about him and he is sure to reply that he can write better code than his peers. Little does he know that writing code is going to be the least of his worries (for the next few years atleast).

To drive the point home lets look at the following code-snippet:


for(j = 0; j < MAX; j++) {



    //some

    //code

    //here



   //ISSUE #xyzxyz FIX: change order

   i = (j < 2) ? !j : j;



    switch (i) {

        case 0:

        //case 0 code

        break;



        case 1:

        //case 1 code

        break;



        case 2:

        //case 2 code

        break;



        //rest of the code here



   }



}

The above snippet is what one would encounter on an average day. Note the following line:
i = (j < 2) ? !j : j;

Can You figure out what the ISSUE could have been.
And how the one-liner FIX solves it... ;-)

(more on this in later post)

What is NULL?

2010-08-10T18:41:00.020+05:30

W hat is NULL? A friend of mine recently told me how this question had stumped his teacher in college and left her speechless for quite some time. Inspired by that, I posed myself the following question:

Q. In not more than 10 words,
Define NULL in the context of a programming language.

And i came up with the following few answers:

Null is absolutely Nothing. Zilch.
Null is something which is NOT defined.
Null is the return-value of a function which has nothing to return. †
Null is the value of the pointer which points to nothing. ‡
Null is the character at the end of a string.
Null is the character with ASCII-code zero.
Null is a byte with all its bits set to 0.

If you have good observation skills then you will notice that the list starts with a very general definition and then moves on to more specific ones.

In fact, [1] & [2] are so generic that they are applicable even in other fields (ex. Mathematics).

[3], [4], [5] & [6] are NOT definitions in the true sense. Rather they are commonly found implementations (or "Use-Cases") of NULL in programming languages.

Finally [7] gives us a one-line definition of NULL i.e. a byte with all its bits set to 0.

Now with reference to [7] we can see that-

Since ASCII-code zero is a byte with all bits set to 0, [6] is the exact same definition but just in so many other words.
[5] is NOT a definition of NULL. Rather it is a commonly found usage of NULL. One sees NULL terminated strings everywhere. It is so common that even programming-languages that do NOT have any explicit support for NULL, support lpStrZ i.e. null-terminated-strings.
[4] mentions yet another very common usage of NULL. Pointers are usually used to pass references to data between functions. As a special "use-case" whenever the "sender" function encounters a case wherein it has no (valid) data to pass, it assigns the value NULL to the pointer thereby signaling to the "receiver" function that the pointer reference is invalid.
[3] is yet another (not so common) usage of NULL. The following line //end of function return(0); }
found at the end of so many common functions in any given C-code is the line that implements it. By convention, any function that completes execution successfully and has nothing to report (except for the fact that it succeeded) returns a NULL (i.e. zero in this case). In case of errors the functions usually return non-zero values which indicate the kind of error they encounter.

Thus, we can clearly see that there is nothing special about NULL. It is just another name for zero. The name NULL signifies the usage the value zero is put to i.e. to state that it points-to/stands-for/holds nothing.

Further reading:

boredzo.org/pointers
" How a function pointer can even be the return value of a function...
...is really mind-bending, so stretch your brain a bit so as not to risk injury."
c-faq.com/null/index.html
20 Qs. 20 straight answers.
EVERYTHING you ever wondered about NULL pointers.

____________ _ _ ____________

† If your function returns some data in some cases and no data in other cases, then define it as a non-void function and use NULL when you have nothing to return.

‡ Once a block of memory is freed, any pointers pointing to it must be set to NULL to prevent any accidental access.

BONUS: Here is an even more intriguing question that the one i had started with:

Q. What is the data-type of NULL?
Hint: NULL is just yet another value like 13, 3.14 or 'c'.

NULL

2010-08-09T09:52:00.019+05:30

In the beginning when God created the heavens and the earth,
the earth was a formless void...

...Then God said, ‘Let there be light’; and there was light. -Genesis 1:1