Please Wait . . .

We all want to have add-on displays for status outputs on PC. Yes that's the small display on your PC tower displaying how Awesome is the hardware inside is doing. Well we need one for our python scripts running in background on a Raspberry Pi. We had some spare ST7565 driver based LCDs but could not find any generic utility to connect these. So we wrote one ourselves.

These LCDs use SPI communication to configure the driver. Both data and commands are multiplexed using the A0 pin of the LCD.

We found that there are two variants of the LCD:
1. Adafruit Graphics LCD based on ST7565:
This one had the issue of stange frame locations. These needed some mangling to get it right. Also there was additional column than the mentioned 128x64 resolution of the display. We managed to get this working and added a specific compatibility to our driver. You can buy one of these from Adafruit at http://www.adafruit.com/products/250 and this page contains all the datasheet. However we took the liberty of adding the datasheet to our github repository.

2. Ebay clones Graphics LCDs with ST7565: http://goo.gl/wvmmsl These are the clone of the original Adafruit display but do not have mangling in terms of the pages or the columns. However they have an additional problem, they do not have a roll over function so that when you keep writing data to the LCD row it rolls over to the next. They did not have this function available, so we did an adaptation for that too to help us get the driver running. These are slightly cheaper than the Adafruit ones.

Now for the Raspberry Pi interfacing part we had two choices for the driver:
1. Wiring Pi: This was good but a bit slow for SPI.
2. Pigpio: This was similar but fared better having 20Mhz SPI speed.

We tried out multiple ways of having a Python module do the interfacing work but it was terribly slow in communicating with the LCD. Finally we though of going the C way with Pigpio. And this turned out to be the best choice.

We wanted to have a simple command line interface to work with the LCD. As simple as the 'echo' command in Linux. We needed capability to be able to write, position the cursor and clear the display to begin with.

We created the LCD program a command line tool to communicate with the LCD.
The python scripts can now direct their output to this LCD via commands even though they run in background.

First step was to connect the LCD to the Raspberry Pi, we used a RPi-B+ model as shown in the picture. Here is the pin configuration of J1:

We use the SPI0 bus of the Raspberry Pi to connect the LCD, of course there is MISO as the LCD is only one way traffic. Also we need 2 GPIOs to control the A0 and nRST pins. The nCS chipselect pin used one of the SPI chip select available on the Raspberry Pi (CS0N pin).

Next, since we use the Pigpio program we had to download and install this program.
Here are the instructions:
wget abyz.co.uk/rpi/pigpio/pigpio.zip
unzip pigpio.zip
cd PIGPIO
make
make install

For the benefit of the users we have created a scrip called 'pigpio.sh' in the github repository to help install this driver.

Finally one needs to download the Repository from Github to build this program. Here are the commands:
git clone https://github.com/boseji/Rpi-ST7565-SPI-LCD.git
make
This would download and build the code into an executable called 'lcd'

Now for the commands to access the LCD. All commands need root user access we are accessing the hardware. Hence 'sudo' is added to most of the commands. Listed below are the important commands:

sudo ./lcd init - Used to initialize the LCD

sudo ./lcd c - Used to clear the LCD screen

sudo ./lcd w "String" - Used to write the string to the LCD at the current location

sudo ./lcd g {COLUMN} {ROW} - This is used to position the current cursor at a give location of the LCD screen

All tinkers and hacker like Arduino, we too like it. However some project demand drivers to be developed in the Atmel Studio 6.x for the need of performance and custom IP needs. We have been handling several projects like that for our partners. However whenever production programming comes in question we always tend to use Linux machines. This time around we needed to use a Windows machine instead. We were troubled by the non-availability of avrdude like programming front-end and USB driver issues for programmers. We found one solution by using Atmel's programming back-end. Still every production PC needs to run the full blown version of Atmel Studio 6.x which in itself is a big software. We made it to work but were not satisfied. We liked our good old trusted avrdude from our WinAVR days. So we kept scraping the forums and interacted with our fellow tinkers. Our efforts were paid in full. That's why we would like to share this lesson we learned with you so that if you ever encounter this problem this might be your solution.

In this tutorial we would be using the standard production capable programmer 'AVRISP mkII'. Of course the same goes for its clones and all other programmers supported by Avrdue. The main problem being support of USB AVR programmers for Avrdude on Windows.

AVRISP mkII programmer

We have taken this example since we could not get the clones or the other programmers to work using the Atmel Studio back-end. So we had not choice but to use the original 'AVRISP mkII'.
But later in Part2 we would explain how to get Avrdude working. After that we were able to use Olimex ISP and USBtiny also on Windows PC as production programmers.

PART1 - AVR Studio Programming

This is mostly a standard programming interface API from Atmel. This programming method can be good for using multiple AVRISP mkII progammers to program several chips using a single PC. However in most cases we end up with one programmer with one board per setup.

[1] Download & Install
In order to use the AVR Studio back-end one first needs to install the Avr Studio itself. We have used AVR Studio v6.2 with Service Pack (1).
Its a big download and a long install.
Also as a caution in case of Windows 8 and beyond the driver install protection feature needs to be disabled. This can be found in another tutorial http://goo.gl/cj4V1J

[2] Running the AVR Studio Back end

First thing that's needed is to add the AVR Studio Back end to the System Path.

The AVR Studio back end is located at
'C:\Program Files (x86)\Atmel\Atmel Studio 6.2\atbackend'
in case of 64bit architectures.

In case of 32bit architectures AVR Studio is Located at
'C:\Program Files\Atmel\Atmel Studio 6.2\atbackend'

The program used is 'atprogram.exe' which renders the programming API.

Lets look at various commands to check and program the microcontroller. In this case we would use a Arduino UNO with ATmega328p connected to the PC via USB and AVRISP mkII connected to the ISP connector of the board.

c. Program Fuse:
'atprogram -t avrispmk2 -s 000200208327 -i isp -d atmega328p write -fs -v --values FFDEFD'
Here one needs to be careful in the order of the Fuse. [Extended][High][Low].
Its substituted at the end of the command as HEX values.
Here:

'-fs' indicates we have fuse write operation.

'-v' for verification after write.

'--values' gives the 16-bit fuse to be programmed

d. Program Flash:
'atprogram -t avrispmk2 -s 000200208327 -i isp -d atmega328p program -fl --verify -c --format hex -f program.hex'
This runs with the Program command. Different type of file formats are supported while programming as well as options to perform mass erase.

Here:

'-fl' specifies that the Flash needs to be programmed

'--verify' specifies that after the Flash has been programmed it needs to be verified.

'-c' specified before flashing a MASS ERASE operation needs to be performed before programming Flash.

'--format' specifies the format of the input program file - it can be 'bin', 'hex' or if not specified 'elf'

'-f' provides the file name of the program that needs to be Flashed into the chip

These command help to perform the normal programming operations. The Serial number helps to send commands to multiple interfaces for programming in a concurrent manner.

PART2 - Avrdude Based Programming

We would recommend this for any one trying to implement a multi platform production setup where the programmer used are not necessarily the AVRISP mkII. The best part is it does not damage or alter the existing Atmel Studio driver compatibility on Windows.[1]In order to begin with this we have packaged AVRdude for windows with the required driver DLLs and converted into portable setup.

Download the required files as per the machine architecture type - 32bit or 64bit.
We have tested this working on a Windows 7 x64 installation.

[2] Next step is to install the required Driver.
Once the archive mentioned above is extracted we would have a avrdude directory containing the driver directory.
In our case we had the 'driver-amd64' directory since we had x64 bit system.

a. Run the File 'install-filter-win.exe'
b. It would ask for 'User Access Control' Allow it by pressing 'Yes'
c. Select 'Install a device filter' and press 'Next'
d. Next it sows a list of devices

Select the 'AVRISP mkII' since we are using that. Possibly the same can be done for any other programmer connected with USB.
e. Click on 'Install' after selection of the correct Hardware ID.
f. If the driver installation was successful it would show a confirmation screen.
g. Once done with driver instillation the program would again prompt you to select another Hardware ID. If not needed press 'Cancel' to Exit the installer.

[3] Test it out
Now we get to check if every thing went fine or not. For this experiment again we would use a Arduino board connected to the PC via USB and the AVRISP mkII connected to the ISP connector on it.

a. Open a command prompt from Start Menu by typing 'cmd'
b. Go to the 'avrdude' directory where it was extracted.
d. Give the following command to check the presence of the MCU in this case ATmega328pavrdude -c avrispmkii -P usb -p m328p
Should show the following output:
That's all ! now you have a working setup of Avrdude.

This works for all types of programmers that would need USB drivers in Windows.
Further it allows you to use the Eclipse environment to develop the AVR code using the AVRgcc windows package.

However it still did not work on our Windows 7 x64 installation. We searched further to find one more solution. Since the machine / architecture we were using is x64 there is a chance that it might require some more workaround. Thanks to our favorite http://stackoverflow.com/ we were saved.
Solution is here : http://stackoverflow.com/a/4579917
The above link mentions about a different key location in the Windows registry that helps to fix the install signature of Python.

In order to execute this fix one would need prior installation of PyWin32. We are using build 219 for this on a Windows 7 x64 installation. And the Python Executable should be kept in System Path.
Now we have prepared an update for the script published at effbot.org:

To run this script one needs to run this in Administrator Prompt. In case the Registry keys already exists then this program would ignore the installation.

We were investigating frameworks that can help us create stand alone apps using Python back end. Our exploration led us to some unique solutions, that might as well be helpful for people looking to create small apps out of python. What's best that they work even if python is not installed in the target.

We have seen how the Arduino packages the Java interpreter and VM into its UI. We did not want to make the same thing using python. As python programmers have already built us frameworks that can help stand-alone deployment.

We started with two themes - Command line apps and Windowed Apps.
For the command line app the user interface is the command line itself. Possibly the app would need parameters apart from that most of the interaction is prompt driven. This was one of the category of apps that we already had.
Another category was the TCL/TK based apps that have a basic gui designed. This was another category of apps that we wanted to make standalone.
Apparently in Linux the things are a bit easier as you can make the file executable directly but such is not the case in windows.

We have designed 2 examples to help understand the various packages that can help us with this.

Enter Command SET PATH=C:\Python27;C:\Python27\Scripts;%PATH% to
make sure that the Scripts directory is in PATH environment variable
This ensures that the Path is configured properly and have access to python package manager.

Now for pip installations use the following Commands:pip install cx_freeze PyInstaller virtualenvpip install wget - In case one needs a download managerpip install --upgrade cx_freeze PyInstaller virtualenv - For upgradation

We had already prepared python based execution programs tagged as run-*.

Now each package needs specific command to run.

cx-Freeze Procedure

This package system automatically assembles the Distribution package such that all the
dependencies are take care off. The space taken by this package is the least.
And it generate directly only one directory in the fastest process.
The command used is:python c:\Python27\Scripts\cxfreeze program.py -O -c --target-dir dist-cx
In order to make this process faster we have a python file run-cxFreeze.py.
The command would create the dist-cx directory where the program executable would be created.

PyInstaller Procedure

This package system builds the Dependencies and then build the Distribution with python + support packages.
One of the best advantage is that cross dependencies are handled very well.
The command used is:pyinstaller program.py
We have a runner program in python run-pyinstaller.py.
There are also .spec file that would be generated on the basis of default configuration.
Further advanced options can be configured by writing the .spec file with custom options.
Here is the Documentation Link: http://pythonhosted.org/PyInstaller/

Py2exe Procedure

This package is the oldest of the implemntations. It works by building and then preparing the distribution.
In order to make this package work we would need a specific setup.py as the py2exe needes the Python distribution engine to run.
Example setup.py:

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.

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.

[3] Configuring the I2C on Raspbian:

Find the Line containing blacklist i2c-bcm2708 add a '#' in front of this line. to make it:#blacklist i2c-bcm2708Then 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 i2cThis 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:

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://git.drogon.net/wiringPi
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.

./build

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:

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:

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.

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:

rtc-ds1307

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.

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.

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.

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.

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.

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:

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.

[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 OpenJDKsudo 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: https://login.oracle.com/mysso/signon.jspAfter 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:

For 64-bit Ubuntu Systems (we have the 64-bit version so we use this file):

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
./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.

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/libGL.so.1 \
/usr/lib/i386-linux-gnu/libGL.so
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 http://commondatastorage.googleapis.com/git-repo-downloads/repo >\
~/bin/repo && chmod a+x ~/bin/repo

Finally adding this to the path to help us get the tool workingecho '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: KVT49LRepository Tag: android-4.4.2_r2
To start the download we need to first create a folder eg. android-4.4.2_r2mkdir android-4.4.2_r2cd android-4.4.2_r2

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 https://android.googlesource.com/platform/manifest -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 :
https://developers.google.com/android/nexus/drivers

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.

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.