Archive for 2014

We have all used breadboards, or those who plan to jump into the fascinating world of electronics need to know about them. This article focuses on introducing breadboards inside out, to help people use them and prototype their innovations faster. We would walk through Bread board concepts, connecting various chips & devices, efficient prototyping and documenting the designs.

We would like to detail about our tryst in making the DS1307 RTC to work on the Raspberry Pi. This exercise helped us to find out more in details of the I2C peripheral on Raspberry Pi and how we can make use of it. Going along the way we changed the buses and the way we approached our problem but again it was best to share that so that you are benefited and don't land up into the same problem that we faced.
We started with as Raspberry Pi B Model and a Tiny RTC module. This module contained both DS1307 RTC and an I2C EEPROM AT24C32 ( 4096 x 8bits = 32kbits ). Here is a picture of the module:
We know that the Raspberry Pi B model has two I2C peripherals I2C0 and I2C1 the details of this has been quite well documented in the Elinux Page for BCM2835_GPIO.
The I2C1 is available on P1 connector(26pin) and I2C0 is available on P5 connector(8pin).
We generally use the 26pin connector for lots of other purposes involving expansion of the RPi functionality. So we decided that we would use the I2C0 for the RTC interfacing. This was a wrong turn and we learn a lot from it.

Here are the steps that we took to configure the I2C or rather enable I2C functions on the Raspberry Pi:

[1] Update Raspbian on RPi:

We do this all the time before we start. First update the RPi raspbian and the boot loader. Here are the three simple commands.

[2] Load the Utilities needed:

We need to setup some useful packages that would help us to debug and install other programs from our favorite Github. There are basically two things - Packages needed to debug I2C and Packages needed to compile programs downloaded from Github.
sudo apt-get install -y i2c-tools git-core python-smbus \
build-essential gcc

[3] Configuring the I2C on Raspbian:

For this there are several steps that need to be followed =

  • Edit the /etc/modprobe.d/raspi-blacklist.conf file:
    sudo nano /etc/modprobe.d/raspi-blacklist.conf
  • Find the Line containing blacklist i2c-bcm2708 add a '#' in front of this line. to make it:
    #blacklist i2c-bcm2708
    Then press 'Ctrl + x' and then enter 'y'  to save modified the file.
    This helps to enable the I2C peripheral on the Chip.
  • Edit the /etc/modules file:
    sudo nano /etc/modules
  • Add the Line i2c-dev at the end of the file.
    Then press 'Ctrl + x' and then enter 'y'  to save modified the file.
    This helps to load the I2C module kernel driver at boot time.
  • Edit the /boot/cmdline.txt file:
    sudo nano /boot/cmdline.txt
  • At the end of the line add  bcm2708.vc_i2c_override=1 . Make sure that you don't add a new line, it should be added to first line end only with a single space.
    This helps to Enable I2C0 bus with override.
  • Now we need the access permissions for the I2C:
    sudo adduser pi i2c
    This would help to access the i2c bus even in normal user mode.
  • Finally Reboot the RPi 'sudo reboot'

[4]Checking the I2C busses:

We have already installed the 'i2c-tools' package in previous steps, this would help us to detect devices on the I2C bus. First check if you have the I2C buses available after reboot:
ls /dev/i2c*
This should display some thing like:
/dev/i2c-0  /dev/i2c-1
These are the two I2C Buses we would need.
Now to check if there are any devices on the I2C bus we issue the detect command:
i2cdetect -y 0
This displays the status of the I2C Bus 0:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
This means that there are no devices on the I2C bus 0.

We were surprised as we had already connected the I2C0 to the RTC based Elinux Page:
P5 Connector Courtesy:
P5 Header Pinout (seen from the back of the board), top row:
Pin NumberPin Name Rev2Hardware NotesAlt 0 FunctionOther Alternative Functions
P5-015V0Supply through input poly fuse
P5 Header Pinout (seen from the back of the board), bottom row:
Pin NumberPin Name Rev2Hardware NotesAlt 0 FunctionOther Alternative Functions
P5-023.3 V50 mA max (combined with P1)

This was the place we referred.  On careful monitoring using our logic analyzer we saw no waveform on the I2C0 lines from P5. We were surprised.
Then we noticed something important !
I2C 0 works on the P5 only if the ALT0 is enabled on GPIO28 and GPIO29
This was the catch ;-) . We knew about the useful package called WiringPi which gives the capability to configure and access the GPIO via C programs. Lets look at our next steps to installing the WiringPi and then configuring the GPIO.

[5] Installing WiringPi on Raspbian for RPi:

We have already installed the git package so lets start by now checking out the repository and then compiling.
git clone git://
cd wiringPi
git pull origin
The last command ensure that we have the updated version of the package.
Now give the following command to build and install the WiringPi package.
We are done installing the libs for the Wiring Pi. This is an very useful utility supplied with this package called as 'gpio' this helps to easily visualize the GPIO status.
Lets try it out:
gpio readall
We get:
 +-----+-----+---------+------+---+-Model B2-+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5V      |     |     |
 |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 1 |  7 || 8  | 1 | ALT0 | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | ALT0 | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 0 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI |   IN | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 0 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |
 |  28 |  17 | GPIO.17 |   IN | 1 | 51 || 52 | 0 | IN   | GPIO.18 | 18  | 29  |
 |  30 |  19 | GPIO.19 |   IN | 0 | 53 || 54 | 0 | IN   | GPIO.20 | 20  | 31  |
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+-Model B2-+---+------+---------+-----+-----+
This shows that the GPIO28(Wiring Pi 17) and GPIO29(Wiring Pi 18) are Inputs and not the ALT0 function that we needed. Now we need to do a small trial to see if we can get the I2C0 to work.
Enter the following commands:
gpio -g mode 28 alt0
gpio -g mode 29 alt0
gpio readall
We get:
 +-----+-----+---------+------+---+-Model B2-+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 | ALT0 | 1 |  3 || 4  |   |      | 5V      |     |     |
 |   3 |   9 |   SCL.1 | ALT0 | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 1 |  7 || 8  | 1 | ALT0 | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | ALT0 | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 0 | 15 || 16 | 0 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI |   IN | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO |   IN | 0 | 21 || 22 | 0 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |   IN | 0 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |
 |  28 |  17 | GPIO.17 | ALT0 | 1 | 51 || 52 | 0 | ALT0 | GPIO.18 | 18  | 29  |
 |  30 |  19 | GPIO.19 |   IN | 0 | 53 || 54 | 0 | IN   | GPIO.20 | 20  | 31  |
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+-Model B2-+---+------+---------+-----+-----+
That's it we have both the GPIO pins now in the ALT0 function mode.
Now lets try our I2C detect command on the I2C 0 bus.
i2cdetect -y 0
We got:
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
We have detected two devices now !

For AT24C32 the 7-bit I2C address 0b1010(A2)(A1)(A0) - In current board A2, A1, A0 = GND so it would become 0b01010000 = 0x50
 For DS1307 the 7-bit I2C address 0b1101000 = 0x68
Hence we have the setup ready.

However we found a note in the following forum thread:
This came out when we were searching for the I2C0 bus problem.
I2C0 is used by Videocore and by default is enabled on GPIO28/29. It will be the VC bootloader that temporarily swaps the alt settings around and probes the GPIO0/GPIO1 I2C0 bus for the EEPROM prior to booting the ARM. There should be no need to probe the EEPROM from Linux in a fully functioning system, but for development or test purposes the hack in the linked thread can let you talk to the EEPROM in Linux.
This means that we can't use the I2C0 at boot time and hence RTC functionality would not be suited on this.
Hence we need to move back to the I2C1 which is available on P1. Lets now look at the final modifications to connect the RTC module to the Raspberry Pi.

[6] Connecting RTC to Raspberry Pi:

We actually soldered connections such that RTC module acts like an extension for the I2C for future.
Power Connections for RTC
I2C Connections at bottom
This way we can add additional modules on the P1 connector top and still have the RTC functionality.
Here is the complete setup:
Raspberry Pi B connected to Tiny RTC module
This completes our hardware setup. Next comes the software part to be configured so that we can have the RTC working.

[7] Configuring the RTC DS1307 on Raspberry Pi in Raspbian:

For this we heavily depend on Adafrut Raspberry Pi RTC Tutorial, we are just quoting the same for your convenience.
We need to type in the following commands:
sudo modprobe rtc-ds1307
sudo -i
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
sudo hwclock -w
Lets describe whats going on here.
The first command loads the rtc kernel driver for DS1307. The second command enters into a root shell where we need to enter the third command. The third command connects the RTC to the System I2C 1 Bus.
The fourth command exits the root shell we entered in the second commands. The last command sets the DS1307 internal time. It is important to note that one must boot the Raspberry Pi connected to the internet to get the correct system time before you set the DS1307 internal time.
In order to verify that the time in the RTC DS1307 set properly give the following command:
sudo hwclock -r
This command directly reads the RTC internal time. If everything goes well then this should show the same date and time as that of the 'date' command.

Now we need to modify some files to make this change permanent. Means that we wish to use the RTC time always. Here are the steps to do that:

  • Edit the file /etc/modules to enable the DS1307 driver to load at boot time like we did for the I2C:
    sudo nano /etc/modules
  • Add the following line at the end of this file:
    Then press 'Ctrl + x' and then enter 'y'  to save modified the file.
  • Edit the file /etc/rc.local to enable the attachment of the RTC to I2C and to set the system time with the RTC time. This ensure that even when the Internet is not connected the RTC time is set as the default system time.
    sudo nano /etc/rc.local
  • Add the following lines before the 'exit 0' at the end of this file:
    echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
    sudo hwclock -s
  • Next Reboot the Raspberry Pi using 'sudo reboot'
Now the Raspberry Pi would always show correct time no matter if its online or not.

Thats all, hope that you like this post. Let us know your feedback and suggestion to help improve this post.

We have already received some of the parts. Actually all the parts in my additional part list but not the Raspberry Pi B+ and the TBS1202B-EDU Oscilloscope.

Here are a couple of pictures of the boxes and modules:
EnOcean Pi Receiver Module
EnOcean Pi Module assembled on an Raspberry Pi
Next the Sensor Kit:

TCM 320C TRX Module to act as Actuator Receiver :
Connected using a 2mm Pitch connector on the board.

Raspberry Pi Camera and Web Server Raspberry Pi: This would be hanged on the wall of the drawing room.

Some more pictures of the working assembly for testing as of now:

Hope to post more pictures of the implementation as we go forward.
As part of our blogging for the Forget Me Not challenge we would first like to detail the idea that we wish to implmented.

SCHO – Safe Connected Home

An IoT based automation and energy efficient monitoring

This project is designed to provided connected control of house and security monitoring. Utilizing the energy efficient wireless network of sensors, switches and actuator outputs by EnOcean this project intends to provide a connected framework which can be remotely controlled using a mobile phone or using an internet gateway. The following are the objectives of SCHO design:
  • Control of electrical outlets from central server as well as wireless switch panels
  • Sensing of Doors and Windows for open/closed status
  • Sensing of soil moisture in the garden and motor actuation
  • Timed dispensing of water and food for the pet and reporting low stock situations
  • User control using Web API
  • Camera monitoring for image and video recording in case of security breach
  • SMS / Twitter status update and alert sending feature
Here is how it would be designed:
  • EnOceanPi with one Raspberry Pi B+ acts as the Wireless network central server
  • Additional Raspberry Pi helps to host the SMS gateway using 3G modem and the Web-server for Remote monitoring of the system Status
  • Both Raspberry Pi would communicate to internet using the home Wi-Fi network.
  • Front Door would be coupled with a STM320 Magnetic sensor sense its open-close status
  • A kitchen window would be coupled with another STM320 Magnetic sensor to sense its open-close status
  • The presence detection of the user would be ascertained using the MAC ID polling on the users Mobile with Wi-Fi connection via the Web-server Raspberry Pi. This would send an instruction to the EnOcean Raspberry Pi controlling the Wireless node network to turn off the Power outlets connected to the TCM 320 module system.
  • Another function of the Web-server Raspberry Pi B+ would be to use a Camera to monitor the front door for movement when the security system is armed. This would be done by the edge detection algorithm executing in python for each snap shot taken by the Raspberry Pi camera.
  • The power control would use two TCM320 modules in Mode 3 with 4 Relay control outputs. One of such output would be used to control the timed Cat feed actuation. Another output would be used to control the Garden water pump to water the plants in case the soil moisture goes below a threshold. Other outputs would be used to control the power plugs using relays. The complete control system housing the TCM320 and the relays would be powered from an external supply to help run the relays. 
  • The additional sensing function of the Soil Moisture and Load Cell on the Cat Feeder would be done using the STM 310 module. Two Soil moisture sensors would be used and one load cell would be used to achieve this.
  • The sensing actuation would be controlled using OpenHAB running on the Web-server Raspberry Pi to the EnOcean Raspberry Pi.

There are important assumptions made to achieve the functionality in time for the Challenge :
  • Soil humidity sensor would be emulated using a potentiometer
  • All the outputs from the TCM320C modules would be LEDs rather than the actual Relay's
  • The pressure input from the cat feeder would again be emulated using potentiometer.

All the above assumptions would help to complete the proof of concept first to help go the next step of actual field testing the rig.
We are pleased to announce our selection in to the highly anticipated Forget Me Not Challenge by Element 14.
This design challenge is all about solving your daily life worries about you house hold items and consumptions.
Some of the key questions that one asks in busy day to day life:
  • Did I leave the door unlocked?
  • Did I leave the iron on?
  • Did I water the plants?
  • DId I feed the cat?
These are the question that we are trying to provide a solution to help people not to worry any more about the mundane things and focus their attention on better parts needing their attention.

In this challenge the competitors would be provided with the best in class energy harvesting wireless control infrastructure by EnOcean in the form of their latest kit the EnOcean Raspberry Pi & Sensor Kit.
EnOcean Raspberry Pi Module
And you guessed it right we would be using the most popular Linux Board that created a new bread of makers - Raspberry Pi. And Element 14 has been generous enough to provide the latest B+ model for this challenge.
Raspberry Pi B+ Model

Not only Element 14 provides us with these goodies but they also provide us with Tektronix TBS1202B-EDU Oscilloscope and Eagle Cadsoft Pro 7 License.
Tektronix TBS1202B-EDU with 200MHz BW and 2G/s Sample Rate

Cadsoft Eagle Pro V7

Apart from this big lot of cool stuff from Element 14 we also get $500 budget to buy additional stuff from Element 14 to complete our entry.
Of course they are are great distributor of parts as well so off we go, implementing the next innovation worry-free-daily-life.

We wish to extend our thanks to Element 14, Tektronix, Raspberry Pi Foundation and EnOcean for organizing this amazing the challenge.
UPDATE 31st July 2014: There has been an issue our only Windows XP laptop has now crashed! So we have no other choice but have this post re-documented for Linux only.

We came across the LPC800 series of microcontroller from NXP. Actually it was an unused board lying in our closet of dev-boards. This is the NGX LPC800 Mini Kit. This board was a limited edition low cost kit part of the marketing campaign of LPC800 microcontrollers. Although there are much better boards to work with LPC800 we chose what we already had to try out this tiny ARM Cortex M0+ chip.
Image Courtesy
This is a nice tiny board with basic features to get started on LPC800. One thing that attracts us is the small PDIP package of the LPC810 microcontorller, more technically called as LPC810M021FN8. That's the exact part name of this chip if you would ever like to sample some from NXP.
On this board we have two buttons - one for Reset and another for ISP entery. Even though this board can be loaded with the LPC-Link or LPC-Link2 etc debuggers we prefer to use the cheaper route using a friendly USB-2-Serial adapters that we buy off ebay and Flash Magic tool. Although this would be a windows centric tutorial we would also provide a Linux alternative for this later, since that's our base system. For us we have been using windows under Virtual Box for some of the windows centric tools. The main problem with this board is that the LED that the board has is connected to the SWDIO pin which is used for debugging. This was the point we decided to do away with the debugger. Another important thing to note is that this board does not have a crystal on-board so the on-chip crystal oscillator needs to be used, this has implication in code we would discuss later. Lets have a quick look whats inside LPC800:
Image Courtesy
Well lets get started in our usual step by step way of running our first code on this microcontroller.

[1] Getting the Setup on Windows

First we would need to following to be downloaded:
Looks to be a long list of things, well this is much simpler than reading the complete datasheet and co-relating the User manual.

[2] Setting up the Environment

We would keep adding more as we go ...
This is an update for Building Android Kitkat from source on Ubuntu 13.10 for the latest version of the Android which android-4.4.2_r2 (Build: KVT49L) on the new 14.04 LTS version of Ubuntu.
We would be targeting this tutorial for the Nexus 5 device codenamed 'hammerhead', however similar procedure can be followed for Nexus 7C 2013('deb') or Nexus 7 ('Grouper').

As discussed in the previous post the procedure remains nearly the same. There are minor changes that would help to make this updated build work. But First:
DISCLAIMER: If you proceed on the steps provided it will surely cause damage to your Nexus 5 device and the Author of this article will not be held responsible for any losses or damages of any type caused by following the steps below.

Now for the steps.

[0] PC and Other Requirements:

The basic system requirement are same as stated in the earlier post.

# PC configuration to have a decent build performance:
  • Processor: Quad Core 2.6GHz Intel Core i5 and above
  • RAM: 4GB DDR3 1066MHz and above
  • HDD Space: 120GB Free (build tools + Android source + build cache)
  • Internet Connection: 2mbps and above
# Nexus 5 with PC Cable

[1] Prepare Ubuntu 14.04 for building Android

The update package requirements from Ubuntu have changed so the particular step would need some correction to help install the required packages needed to build the Android Kitkat.

[1._ ] Most of the commands need to run in a terminal window so we need to open it before starting any of the below steps. The easy way on Ubuntu is to press the keyboard combination Ctrl + Alt + 't' else one can also go to the app launcher icon and type "terminal"

[1.a] Correcting and Installing Java

First thing that we need to perform is removing the Icedtea Java or OpenJDK
sudo apt-get purge openjdk-\* icedtea-\* icedtea6-\*

This time the problem is that we can not use the offical Java update from Oracle.
Instead we need to use the Last java version available in the JDK1.6 SE pacakge.
To do so one needs to signup at Oracle Java website:
After sign-up and login into the Oracle website use the JDK1.6SE u46 version link to get to the download area.
Now one needs to select the correct package:
Finally after downloading these files one needs to extract them and add to the path here are the commands:
chmod +x jdk-6u45-linux-x64.bin
echo "export PATH=$PATH :"`pwd`" >> $HOME/.bashrc
This would help to place the directory to path. Next there would be restart needed for the Terminal to enable the new path to take effect.
Note: If you have multiple Java installation then better ignore the last line and add it as per your requirement. We use both Java7 SE for application development and Java6 for Android. Hence we modify the path when needed.

[1.b] Installing the package dependencies into Ubuntu

This is a long an time taking process, where nearly 1050MByte+ data is downloaded. So be careful if you have limited bandwidth connection like ours. This might take up a lot of your Internet connection bandwidth.
sudo apt-get install git-core gnupg flex bison \
gperf build-essential zip curl \
zlib1g-dev zlib1g-dev:i386 libc6-dev \
lib32ncurses5-dev lib32ncurses5 \
lib32bz2-1.0 x11proto-core-dev \
libx11-dev:i386 libreadline6-dev:i386 \
lib32z1-dev libgl1-mesa-glx:i386 \
libgl1-mesa-dev g++-multilib mingw32 \
tofrodos python-markdown libxml2-utils \
xsltproc readline-common \
libreadline6-dev libreadline6 \
lib32readline-gplv2-dev libncurses5-dev \
lib32readline5 lib32readline6 \
libreadline-dev libreadline6-dev:i386 \
libreadline6:i386 bzip2 libbz2-dev \
libbz2-1.0 vim libghc-bzlib-dev \
lib32bz2-dev libsdl1.2-dev libesd0-dev \
squashfs-tools pngcrush schedtool \
libwxgtk2.8-dev python

This would update the base packages needed to compile the Android source.

This would take some time to get the complete download done and then the dependency fixes need to be applied:
sudo apt-get install -f
After this we need to do the following linking:
sudo ln -s /usr/lib/i386-linux-gnu/mesa/ \

This completes the installation of dependencies and necessary packages to begin our build

[2] Downloading the Google Repository tool - repo

In order to obtain the Android source code from Google there is a special tool called "repo". This tool enables us to download all the component repositories sources that come together to make Android OS source for a specific version.

First lets create a local directory which would hold our executable code:
mkdir ~/bin
Now let us download the repo tool into this directory and apply the executable permission:
curl >\
~/bin/repo && chmod a+x ~/bin/repo

Finally adding this to the path to help us get the tool working
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc && \
source ~/.bashrc

We are now ready to obtain the source code from Google for Android OS

[3] Downloading the Android Sources & Vendor Binaries

For the Nexus 5 Device we have the 'hammerhead' Google code release:
Build: KVT49L
Repository Tag: android-4.4.2_r2

To start the download we need to first create a folder eg. android-4.4.2_r2
mkdir android-4.4.2_r2
cd android-4.4.2_r2

Now lets Initialize the Repository for GIT configuration
git config --global {Your Name}
git config --global {Your@Email}

This would set up your identity that would be part of this source code checkout
Finally we can Initialize the Repository using the following command:
repo init -u -b android-4.4.2_r2
This command will take some time to finish as it creates the basis for the list of location from which the different components are downloaded.

Now we are ready to receive the real code:
repo sync -j4

The Vendor Specific Binaries located at :

For 'hammerhead' and Android Kitkat Release download the binaries at this link:

Go to the android-4.4.2_r2 directory and Download the drivers:
cd android-4.4.2_r2
wget -c
wget -c
wget -c
tar -xvf broadcom-hammerhead-kot49h-a670ed75.tgz
tar -xvf lge-hammerhead-kot49h-e6165a67.tgz
tar -xvf qcom-hammerhead-kot49h-518133bf.tgz
rm *.tgz

Finally extract the Vendor Specific binaries by the following commands:
You need to enter the "I ACCEPT" at the end of license notices to execute the program.

Perform this for all the three files extracted above.

For 'Grouper' Nexus 7 these binaries are available at:

For 'deb' Nexus 7C 2013 these binaries are available at:

Now we are ready for the next big step - Compiling!

[4] Building the Sources

First open another Termial window and go the Android directory:
cd android-4.4.2_r2
. ./build/

Now to select the type of device we give the following command:

This would display a menue:
You're building on Linux

Lunch menu... pick a combo:
     1. aosp_arm-eng
     2. aosp_x86-eng
     3. aosp_mips-eng
     4. vbox_x86-eng
     5. mini_x86-userdebug
     6. mini_armv7a_neon-userdebug
     7. mini_mips-userdebug
     8. aosp_tilapia-userdebug
     9. aosp_flo-userdebug
     10. aosp_deb-userdebug
     11. aosp_grouper-userdebug
     12. aosp_manta-userdebug
     13. aosp_hammerhead-userdebug
     14. aosp_mako-userdebug

Which would you like? [aosp_arm-eng] 13

Select the option '13. aosp_hammerhead-userdebug' choice by entering '13'.
Now we are ready to start the build.
make -j4

Here the "-j4" switch would help to run the build on Quad core.

This process would take some time ranging from 30minutes to 3hours depending of your PC performance and configuration.
After this is done you are ready with your source to flash the image into your device.
DISCLAIMER: If you proceed on the steps provided it will surely cause damage to your Nexus 5 device and the Author of this article will not be held responsible for any losses or damages of any type caused by following the steps below.

[5] Flashing the Device

This would definitely damage your device and load the image of Android OS built in the previous steps. In order to perform this step one needs to unlock the bootloader as explained in the XDA forum post.
Connect your device into the Linux PC. And give the command in the existing terminal prompt from the earlier step.
adb root
adb reboot bootloader
cd out/target/product/grouper

This would help you enter the bootloader mode. And change the directory to the place where the actual build image files are located
Final command that would kill the device and load your compiled image:
fastboot oem unlock && fastboot -w flashall

This would load the complete image into your device and then reboots it.

Now in order to restore the device back to its original os follow the steps outline in another post. Although this is for the Nexus 7 device the similar steps work for Nexus 5 device also.
We were evaluating different IDE's for development with our newly acquired STM32 board that we posted about earlier and a new Stellaris Launchpad . The initial example that we covered was completed in Keil environment. Next we wanted to extend beyond the 32KByte limit imposed by Keil so we need to look for alternatives. Although we were quite happy with coocox IDE, we needed some thing with lot more debugging options. Even though the CCS IDE from TI is good but for older PC's like ours its difficult. This lead us to work with Keil, but under the hood GCC would do the heavy lifting.

We would explain the process of compiling for thee different ARM Cortex-M3 architectures and all that you would need to get started on that.

UPDATE 19,Apr 2014: There has been some changes to the STM32 Standard Libs location
Recently we discovered the long awaited MSP430GCC which was released in support with RedHat and TI . It was disclosed in the sourceforge MSP430GCC website notice on 26th October, 2012 . Well we were hoping since a long time that this release to be out. It seams that last year in December'2013 the first version was released.
The MSP430GCC is officially supported in the beta version of the CSSv6. This can be installed using the new TI AppCenter feature.
This feature of CCSv6 helps to install the required software features such as GCC and MSP430Ware directly from the CCS IDE. TI has also included support for Energia in this latest beta release. The sketches of Energia can be directly composed in CCS IDE along with the native CCS projects. We have not tested this feature and would be posting more on the review of all the features of the CCSv6.
The only problem we found was that the CCSv6 now requires a online installation which consumes roughly 460MB of internet bandwidth for download not including the MSP430Ware and MSP430GCC. They are downloaded separately after the installation of the CCS itself through the AppCenter.

MSP430GCC can also be individually installed for Windows and Linux , for normal operation using makefiles like the older times. However there is a need to download additional device header files and install them into correct path so that during the make these files get included correctly. However inside the CCS environment this is take care directly. The links for the download location are mentioned below. We would be covering this new MSP430GCC compiler in our next review.

We would like to thank TI and RedHat for bringing the MSP430GCC release.

Here are the relevant links

MSP430GCC Download for Windows and Linux :
Note: Under Linux the installation file downloaded needs to be first made executable using the 'chmod +x' command. And later the installation needs to be run in super user mode using the 'sudo ./' command. Here the FileName would change as per the installation file downloaded.

MSP430GCC Device Specific Header files Download:

CCSv6 Download for Windows and Linux :
We were investigating a way to make some automation for file generation and tried to use python to solve our problems. Doing so we found an interesting way to use python scripts.
Our python scripts were stored in various directories below a root directory.
It looked some thing like this:

Each of the directories contained several scripts that would generate corresponding pages for a website. This would mean that we need to parse the directory tree and then run the Scripts. That was done using the 'walk' function available as part of the 'os' Package. Here is the code for the function:

Another thing that was done in this function was that some time due to inclusion of the sub-modules the '__pycache__' is create or there are '' files for packages that would not be executed.

Next we need the way to run the Python sctipts using the above 'runner' function. For this there are three ways to go about. This completely depends on the way in which the script is called , its dependencies and possible case of individual or ' Runner' execution. We decided to write for all the different ways.

In this snippet depending on the variable 'bDirect' the way of execution is decided.

  • The option 0 calls the module by using the internal interpreter function 'exec' after compiling the script.
    In this case the environment of the Caller eg. the Runner function would be completely inherited.
  • The option 1 executes the script in command line. This is same a going to each of the directories and then executing the files individually. This case no environment can be inherited. Each script is responsible for seting up its required environment for execution.
  • The option 2 executes a specific function called 'run()' defined in each of the script files. In this the script being run inherits only the Path and not any other entity. This call is similar to calling any function in any other module or package. However the user program now has a way to pass parameters to the scripts which may include local / global variables, generators or even functions.
Here is the complete program for this we call it the '' and is placed in the root for the folder:

Still there is one problem that remains , how to detect if the python scripts are being executed from the Runner or are being directly executed. As this would effect the environment initialization. To solve this we created a example script that could be used to test its own environment and be able to set up the environment in case its not being run from the 'Runner' script.

This Example program how to create the scripts in the directories such that they can either run using the Runner or directly. The 'config ' here is a package that contain the configuration data for each of the scripts. So relative paths can be used to correct the errors in case the files are run directly.

Hope that this tip would be helpful, let us know your comments if you like this.

Welcome to Boseji's Blog

Popular Post

Blogger templates


Creation by Electronics Hobbyists from Bharat(India) to encourage & help people. This blog hosts the numerous innovations, discoveries and projects we provide.
Our Research Wing Adhar Labs
Contact Form | Email Address
We Support Open Source Hardware Definition v1.0
Creative Commons License
All works on this blog are licensed under a
Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at and

Permissions beyond the scope of this license may be available at
Thank you for all your support.

© A.D.H.A.R Labs Research 2008-2013 . Powered by Blogger.

Follow by Email


Blog Archive

PCB Unit Converter


- Copyright © Electronics for Bharat -Robotic Notes- Powered by Blogger - Designed by Johanes Djogan -