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 :
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/1_00_00_00/index_FDS.html
Note: Under Linux the installation file downloaded needs to be first made executable using the 'chmod +x FileName.run' command. And later the installation needs to be run in super user mode using the 'sudo ./FileName.run' command. Here the FileName would change as per the installation file downloaded.

MSP430GCC Device Specific Header files Download:
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/1_00_00_00/exports/GCC_RH_20131206.zip

CCSv6 Download for Windows and Linux :
http://processors.wiki.ti.com/index.php/CCSv6
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 '__init__.py' 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 'main.py' 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.

This is an update from our last post of Building Android from Source for Nexus 7 on Ubuntu 13.04 : Step-by-Step. This time we upgrade our Ubuntu Installation to 13.10 Saucy Salamander along with the update Android Version 4.4 KitKat for the Latest Nexus 5 device code named 'hammerhead'.
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 13.10 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: https://login.oracle.com/mysso/signon.jsp
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
./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/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 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: KRT16M
Repository Tag: android-4.4_r1

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


Now lets Initialize the Repository for GIT configuration
git config --global user.name {Your Name}
git config --global user.email {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 https://android.googlesource.com/platform/manifest -b android-4.4_r1
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

For 'hammerhead' and Android Kitkat Release download the binaries at this link:
https://developers.google.com/android/nexus/drivers#hammerheadkrt16m

Go to the android-4.4_r1 directory and Download the drivers:
cd android-4.4_r1
wget -c https://dl.google.com/dl/android/aosp/broadcom-hammerhead-krt16m-bf9b8548.tgz
wget -c https://dl.google.com/dl/android/aosp/lge-hammerhead-krt16m-0efa9c33.tgz
wget -c https://dl.google.com/dl/android/aosp/qcom-hammerhead-krt16m-53cf1896.tgz
tar -xvf broadcom-hammerhead-krt16m-bf9b8548.tgz
tar -xvf lge-hammerhead-krt16m-0efa9c33.tgz
tar -xvf qcom-hammerhead-krt16m-53cf1896.tgz
rm *.tgz


Finally extract the Vendor Specific binaries by the following commands:
./extract-<filename>.sh
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.
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_r1
. ./build/envsetup.sh


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

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 would like
We have been working on some Java based projects recently. The compile mechanism of Java is a bit different from the way each of the IDEs implement them. We have used Netbeans-IDE and Eclipse. We figured that both have radically different way of implementing the compile time and jar time constrains. However we wanted some thing as simple as "make clean" and "make compile". That's when we came across Ant.

Apache Ant is internal build system used by many of the IDEs, this is the build framework in the world of Java. Kind of like 'make' for Java but apparently bit easier than makefiles. We need a consistent build framework across our Linux, Mac OS and Windows. We made a generic build system and configured in the way to make building Java projects a breeze.

In this article we would be discussing how we went about setting up the all the three system to have a common build framework for our up coming project jNeelSer which would be detailed later.

[1] Obtain Java

The  Ant framework is written in Java and hence to execute the same we would need to have Java compiler and run time available. To do this we simply get the JDK and place it into our path.
One can obtain the Java SE JDK from the Oracle Website. For now one can use the Latest JDK Java SE 7 releases.
A word of caution for the Linux users - if one intend to use the JDK to compile Android and use it for general purpose Java programming then they need to have JDK 6 version separately for Android from the Oracle Java Archive and if JDK 7 is used for development then the Path needs to appended accordingly. We actually do this so we will show how to do this in the next steps.

[2] Obtain Ant

The Ant package is available in binary form at Apache Ant website. Its designed in such a way that one can easily run it in any platform. So to setup extract the Ant package into the desired directory.
We are using Ant 1.9.2. So we have the directory apache-ant-1.9.2/bin and we add this to our Path in all the three platforms. Its easy to understand the Zipped version is for windows and the .tar.gz & .tar.bz2 are for Linux or MacOS.

[3] Ant Environment Script

In order the Ant build system to work one needs to setup the system Environment in the correct way.
Lets try to spend a moment to understand the system variable and what they mean:
  • JAVA_HOME = Location of the Java Installed Directory. Not the 'bin' directory but the root directory of Java installation.
    Eg. JAVA_HOME=C:\jdk1.6.0_45 and not C:\jdk1.6.0_45\bin
  • ANT_HOME = Location of the Ant Installed Directory. Again not the 'bin' but the extracted directory.
    Eg. ANT_HOME=/home/efb/local/apache-ant-1.9.2 and not /home/efb/local/apache-ant-1.9.2/bin
  • PATH = Need to be modified to add the Ant as well as Java ahead of all parsing. We will show this how
 Now lets look at how we can configure these environment variables:
Windows Batch file script (Save this text into a .bat file replacing the 'path' strings):
For Linux / MacOS we can create a small shell script to do this:
However this also means that the file needs to executable, so below is the command:
chmod +x antconf.sh

Next lets progress with writing a simple build script.

[4] Writing the Build Script for Ant

The Ant build framework is written in Java and uses XML based format to write the build scripts. This is a complete paradigm shift from the conventional Makefile business that we have seen countless number of times. Have a look at the basic framework of the build script:

Here the first XML tag defines the usual DTD as per the W3C. This is similar to the one used in any conventional XML data file.
Next the header <Project> gives details about the project that we plan to compile/build. Its important to remember the name specified by the parameter 'name="jNeelSer"' gives the project its true name. The compiled output would use this parameter to name the file build output.
The parameter 'basedir="."' helps to determine the path to the source code base where the build.xml is present.

Forgot to mention that  build.xml is the default name of the build script for Ant.

The 'default="compile"' option helps to determine the default step to be performed when the build is invoked.
Here is the complete source for the jNeelSerial project, we would use this as an example to detail the way of writing the Ant build script.
In the above build script there are many additional tags that help to define more information about the project and help in correct build generation.
  • Fail tag shown in line 26 is used to declare that one can use this build script with 1.8.0 or higher version of Ant build.
  • Property Tag shown in line 34 is used to fine the source and build location directories using the location value. The Property tag can also have other values if needed.
  • Target Tag shown in line 38 is like a configuration which contains a set of actions to be perfomed when the build is invoked. One can also add some description to each of the targets if needed as shown in the Compile configuration. Lets have a detailed look at this:
    • Init configuration: This is the Initial target that helps to create the necessary directories or build related info before hand.
    • Compile configuration: This is used to actually build the classes for the source code with the correct Class path. This build target need to run the Init in case it was not explicitly called.
    • jar configuration: This is used to generate the executable manifest information and create the required JAR file that contains the supporting libraries in one place. jNeelSerial uses the jSSC library stored in the lib directory. Again Jar depends on the Compile configuration as the class files to be packaged need to be available.
    • clean configuration: This is used to clear the build and intermediate directories.
  • mkdir Tag shown in line 42 helps to create directories with reference to build.xml file directory path as the reference.
  • delete Tag shown in line 67 can be used to delete files(use file attribute) or directories (use dir attribute)
  • javac Tag shown in line 48 is the most important tag that actually performs the compilation. The srcdir attribute helps to locate the java source code. The destdir attribute specified the location where the compiled classes should be placed. The includeantruntime attribute helps to run the java compilation under ant system control to help produce useful output of the commands being executed.
    • Classpath Tag in line 49 helps to define and include the necessary classes/packages and their locations. It require the Pathelement Tag to declare the paths. There can be two types - Package/Class locations(Eg. Line 50) or Absolute includes (Eg. Line 51)
  • jar Tag shown in line 58 is used to generate the executable java archive. In this the destfile attribute defines the destination jar file and the basedir attribute specifies the location for the class files complied earlier.
    • Manifest Tag in line 59 is used to define the default executable class which contains the 'main'. This is achived by using the Attribute Tag for 'Main-Class' with the value of the exact class with namespace.
    • zipgroupfileset Tag in line 62 helps to include some additional files if needed into the final jar. In the above example shows how to specify the directory and include files using a wildcard sequence.
This concludes the description of he build script.
Now how to run this thing.

[5] Running the Build

In order to run the build, first we need to use the scripts that we wrote earlier to setup the Ant build environment inside a Terminal window. Then change directory to the desired project directory and run the ant command.
Here is the syntax:
ant [target]
Here the important point is that [target] should be a valid one specified in the build.xml file. And this is run in the directory of the project containing the build.xml file.
In our above example for jNeelSerial there are 3 main targets - compile, jar and clean
In case the file name of the build script is different then use the following syntax:
ant -f [build script.xml] [target]

For example in jNeelSerial the name of the build script is make.xml and hence the command would be:
ant -f make.xml compile

Hope that you like this tutorial, let us know your feedback on this article.
This is in continuation to our earlier article "Building Android from Source for Nexus 7 on Ubuntu 13.04 : Step-by-Step" where we discussed on how to build a complete android distro. This article focuses on restoring the Nexus 7 [2012] Wifi (grouper) device to the official version of android.

This process would completely format the Grouper device and the user would lose all the data.
DISCLAIMER: If you proceed on the steps provided it will surely cause damage to your Nexus 7 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.

[1] Download the official Android Build

First step is to obtain the latest version of the Android OS. In order to do so we would need to visit the Google Factory Images Page At: https://developers.google.com/android/nexus/images
The correct Latest Android OS Image for Grouper is:
Official Name: nakasig
Android Version: 4.3
Build: JWR66V (more details from on Build Code Name page )
Link: http://developers.google.com/android/nexus/images#nakasijwr66v
Download Link: https://dl.google.com/dl/android/aosp/nakasig-jwr66v-factory-aebc7b11.tgz

After this extract this file into a directory just above the 'android-4.3_r1' created earlier.
In order to extract issue the following command in Ubuntu Linux Terminal prompt at the directory where the above downloaded file ".tgz" is located.

tar -xvf nakasig-jwr66v-factory-aebc7b11.tgz

This would create a directory called "nakasi-jwr66v" which would contain the required files to flash the factory Android image.

[2] Setting up and Download

 Now its time that we setup the environment to load the Image. Before we begin the Nexus 7 grouper device needs to be plugged to the Ubuntu machine. And the Android build that we did earlier needs to be present or the Android SDK must be in the path.

We will assume that you have the earlier Android build, else one can skip the steps given below if you have the Android SDK:
cd android-4.3_r1
. ./build/envsetup.sh
lunch 6

cd ..

Now we are ready to move with the installation step:

adb reboot bootloader

This would help to go into the Boot loader mode.
Now we need to go to the directory where the offical android build was extracted. And then run the command to flash the image:

cd nakasi-jwr66v
./flash-all.sh


This would format the complete flash and then load a fresh copy of the Official Android build.
Finally the device would reboot on its own and would ask for the default setup needed to get the device running.

Hope that you liked our articles, let us know your comments and suggestions to improve them.
Next we would be posting on how to develop some basic low level apps in Android.
We have been kept busy with our research work on Android operating system for mobile phones. We thought it would be nice to share a short tutorial to get started on building the Android source from scratch. There were several hurdles to pass before we could really get some thing working. Our target platform was Nexus 7 or what is called as "grouper" in Android terms.

Updated for Nexus 5 Source build on Ubuntu 13.10 >>

Nexus 7 is fairly a cheap device for now, as compared to the other high end phones. For disambiguation we are using a Nexus 7 with 16GB Storage and Only Wi-Fi. Since there are two variants available in the market, this one is called as "grouper".
However off the shelf devices are not the development units so you need to mod it to work as a development device. Here we would like to issue a warning.

DISCLAIMER: If you proceed on the steps provided it will surely cause damage to your Nexus 7 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.

[0] PC and Other Requirements:

# 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 7 with PC Cable
# Lots of patience and 1 day time ;-)

[1] Prepare Ubuntu 13.04 for building Android

In order to prepare the standard Ubuntu operation you can first update the installation to the most recent packages. Next follow the steps to install and configure the build system. Thanks to the Blog: soupdawg.wordpress.com
[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-\*
Next we need to add the official last JDK from Oracle:
sudo add-apt-repository ppa:webupd8team/java
Next perform an update on Apt Sources:
sudo apt-get update
Finally Install the Java6 version of JDK:
sudo apt-get install oracle-java6-installer
Just to make sure that you have the right stuff you run the following command:
java -version
The output would be something like:
java version “1.6.0_39″
Java(TM) SE Runtime Environment (build 1.6.0_39-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode)
So now we are done with Java which is one of the essential components needed by the Android Dalvik compiler

[1.b] Installing the package dependencies into Ubuntu

This is a long an time taking process, where nearly 900MByte+ 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 ia32-libs 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 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 packaes 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 https://dl-ssl.google.com/dl/googlesource/git-repo/repo >\
~/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] Understanding and Downloading the Android Sources

There are multiple sources to obtain the Android OS source code. Here are a few of them:
1. Android Open Source Project - AOSP : This is the Google's official development project for android which would be detailed in this tutorial
2. AOKP from Team KANG : Offshoot with all bells-n-whistles loaded plus additional functionality
3. CyanogenMod : This project provides the complete Bootloader customization with specific Recovery and Andorid OS source integration. Slightly old but widely used to replace the official bootloader and recovery tool.

Digging deeper into the AOSP project we now need to know what are the Android OS distributions and what would be most suited towards our "grouper" device.
http://source.android.com/source/build-numbers.html
For now we would choose:
Build: JWR66V  
Repository Tag: android-4.3_r1
This is compatible to the "grouper" device so its a safe bet, there are others but possibly dont have official support for our target device.

UPDATE[4-Oct-2013] Latest version compatible for "grouper" is:
Build: JWR66Y
Repositrory Tag: android-4.3_r1.1
Please update the below commands and branch names accordingly

UPDATE[10-Nov-2013] Latest version compatible for "grouper" is:
Build: KRT16S
Repository Tag: android-4.4_r1.2
Finally we have Kitkat also for "grouper", thank to the signing campaign.
Update procedure for Kitkat have been published in another post

[3.a] Downloading the Source

To start the download we need to first create a folder eg. android-4.3_r1
mkdir android-4.3_r1
cd android-4.3_r1
Now lets Initialize the Repository for GIT configuration
git config --global user.name {Your Name}
git config --global user.email {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 https://android.googlesource.com/platform/manifest -b android-4.3_r1

The anatomy of this command is:
repo = Command
init = For Initialization
-u https://android.googlesource.com/platform/manifest = Location for all the source
-b android-4.3_r1 = Specific branch of source code that needs to be picked

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 anatomy of the command is:
repo = Command
sync = Download the code
-j4 = Use Quad core processing for downloading the source code

Once this command is completed you have the basic android source code available. Just to be sure that you have not missed any files try to run this command again. In case the download fails due to some reason you can ask for another download to fix any issues.
Once suggestion would be back up this basic source to have a copy that you can use to get back the older stage. Use this command to create the backup: (OPTIONAL)
cd .. && tar -jcvf android-4.3_r1_INIT.tar.bz2 --exclude ".git" \
--exclude ".repo" --exclude ".svn" android-4.3_r1/

[3.b] Getting Vendor Specific Binaries

In order to support the various sub-components in the "grouper" we would need to have the vendor binaries. These help to enable functionality + FW needed for the additional processors in the system.
One can find more info on this from the following link:
https://developers.google.com/android/nexus/drivers

For "grouper" and Android JBMR2 release download the binaries from the below location:
https://developers.google.com/android/nexus/drivers#grouperjwr66v

Download all the driver binaries into the android-4.3_r1 directory:
cd android-4.3_r1
wget -c https://dl.google.com/dl/android/aosp/asus-grouper-jwr66v-15547c77.tgz
wget -c https://dl.google.com/dl/android/aosp/broadcom-grouper-jwr66v-fa38dae8.tgz
wget -c https://dl.google.com/dl/android/aosp/elan-grouper-jwr66v-4235892f.tgz
wget -c https://dl.google.com/dl/android/aosp/invensense-grouper-jwr66v-0da5128c.tgz
wget -c https://dl.google.com/dl/android/aosp/nvidia-grouper-jwr66v-2cbbe013.tgz
wget -c https://dl.google.com/dl/android/aosp/nxp-grouper-jwr66v-202ba26a.tgz
wget -c https://dl.google.com/dl/android/aosp/widevine-grouper-jwr66v-c6bdbc54.tgz
tar -xvf asus-grouper-jwr66v-15547c77.tgz
tar -xvf broadcom-grouper-jwr66v-fa38dae8.tgz
tar -xvf elan-grouper-jwr66v-4235892f.tgz
tar -xvf invensense-grouper-jwr66v-0da5128c.tgz
tar -xvf nvidia-grouper-jwr66v-2cbbe013.tgz
tar -xvf nxp-grouper-jwr66v-202ba26a.tgz
tar -xvf nxp-grouper-jwr66v-202ba26a.tgz
rm *.tgz

Optionally create a backup for these shell scripts extracted:
cd ..
tar -jcvf Nexus7Binaries.tar.bz2 ./android-4.3_r1/*.sh
cd android-4.3_r1

[3.c] Extracting the Vendor Specific Binaries

In order to install the vendor specific binaries one needs to run the .sh files generated by extracting the .tgz files in the earlier step.
The method to run the shell files:
.\extract-<filename>.sh
Once you run them you would get a prompt to read the License agreement, press Enter to start reading and then Space bar to reach the end. Finally you need to type "I ACCEPT" to make the script extract the files. Finally the 'Vendor' directory would be ready after this step
Now we are ready for the next big step - Compiling!

[4] Building the Sources

First thing to do is to setup the Environment:
cd android-4.3_r1
. ./build/envsetup.sh

Anatomy of the command
'. ' = Signifies that we would be implying to execute the command in the current shell context
./build/envsetup.sh = Command to setup the environment variables and commands

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

This would display some selection menu like:

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. aosp_flo-userdebug
     6. full_grouper-userdebug
     7. full_tilapia-userdebug
     8. mini_armv7a_neon-userdebug
     9. mini_mips-userdebug
     10. mini_x86-userdebug
     11. full_mako-userdebug
     12. full_maguro-userdebug
     13. full_manta-userdebug
     14. full_arndale-userdebug
     15. full_toroplus-userdebug
     16. full_toro-userdebug
     17. full_panda-userdebug

Which would you like? [aosp_arm-eng]

For this you need to select the " 6. full_grouper-userdebug" choice by entering '6'
It would display the details of the selected "grouper" hardware.

Next major Step is to initiate big build process. This build process would take approximately 2hours 45minutes to complete on the machine specified above. If one has i7 then they can get even faster builds.
This command is:
make -j4

Here the "-j4" switch would help to run the build on Quad core.
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 7 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 that you have successfully built and flashed the code you might not find it very useful until you add all the bells-n-whistles that a professional rom has. We would try to cover that in our next tutorial. Also next tutorials we have described how to restore the factory image.
Hope that you find this post helpful, let us know your feedback and suggestions.
We would like to outline a list of techniques and commands by which one can easily transfer files securely over the network between PCs connected on the same network. This need came out of our experiments to find the fastest method to transfer files between linux and windows via the Network.
Let us first clearly define some of the terms that would govern this  post:
HostPC - The local PC from which the transfers would be made
RemotetPC
- This is a PC connected on the same network as the HostPC, to which the transfer needs to be made.
RemoteUser - This is the username used to log in into the remote PC

First lets prepare the PCs:

For Windows PC:
    Install the Putty Software from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

For Linux PC:
    Install the SSH server (Comes along with SFTP as well as SCP)
    We are trying it out on Ubuntu 13.04 so the command would be
    sudo apt-get install ssh


File Transfers

Now lets look at cases of the transfer.
There can be two types of transfers:
    1. Single file Transfer
    2. Directory Transfer
We would be looking at commands to do both. This would require the RemotePC  logon information and its IP address to be available.

Important point to note here is due to limitation on Windows side transfers can be only initiated from the Windows machine to a Linux machine. The vise versa is not possible. There are software to circumvent this limitation, however that would be discussed some other time.
Also the file or directroy Path used in the 'psftp', 'pscp', 'scp' and 'sftp' commands is a linux style path.

Here is a list of Use cases in terms of the type of OS on the PCs and transfers:

Between HostPC windows and RemotePC Linux

Using SCP technique (Slow)

From HostPC windows to RemotePC Linux
For Single File Transfer
cd {filepath}
pscp {filename} {RemoteUser}@{RemotePC IP}:{Remote PC path for the HostPC file}

For Directory File Transfer
cd {directorypath}
pscp -r {dirname} {RemoteUser}@{RemotePC IP}:{RemotePC path for HostPC directory}


Using SCP technique (Slow)

From RemotePC Linux to HostPC Windows

For Single File Transfer
cd {HostPC path for RemotePC file}
pscp {RemoteUser}@{RemotePC IP}:{Remote PC  file} .


For Directory File Transfer
cd  {HostPC path for RemotePC directory}
pscp -r {RemoteUser}@{RemotePC IP}:{Remote PC  directory} .



Using SFTP technique(Fast)

From HostPC windows to RemotePC Linux

For Single File Transfer
cd {filepath on HostPC}
psftp {RemoteUser}@{RemotePC IP}

Now in the 'psftp prompt' use the following set of commands:
cd {Path on Remote PC for the HostPC file}
put {file name}

Here {filename} is the HostPC file that needs to be copied

For Directory File Transfer
cd {path of the directory in HostPC}
psftp {RemoteUser}@{RemotePC IP}

Now in the 'psftp prompt' use the following set of commands:
cd {Path on Remote PC for the HostPC directory}
mkdir {dirname}
put -r {dirname}

Here the {dirname} is the directory on the HostPC that needs to be copied

Using SFTP technique(Fast)

From RemotePC Linux to HostPC Windows

For Single File Transfer
cd {HostPC path for RemotePC file}
psftp {RemoteUser}@{RemotePC IP}

Now in the 'psftp prompt' use the following set of commands:
cd {Path to Remote PC file}
get {file name}

Here {filename} is the RemotePC file that needs to be copied

For Directory File Transfer
cd {HostPC path for RemotePC directory}
psftp {RemoteUser}@{RemotePC IP}

Now in the 'psftp prompt' use the following set of commands:
cd {Path to Remote PC directory}
lmkdir {dirname}
get -r {dirname}

Here the {dirname} is the directory on the RemotePC that needs to be copied

Between HostPC Linux and RemotePC Linux

SCP technique (Slow)

From HostPC linux to RemotePC Linux

For Single File Transfer
scp {filename+path} {RemoteUser}@{RemotePC IP}:{Path on Remote PC for the HostPC file}

For Directory File Transfer
scp -r {dirname+path} {RemoteUser}@{RemotePC IP}:{Path on Remote PC for the HostPC directory}

SCP technique (Slow)

From RemotePC Linux to HostPC Linux

For Single File Transfer
scp {RemoteUser}@{RemotePC IP}:{Remote PC  file} {HostPC path for RemotePC file}

For Directory File Transfer
scp -r {RemoteUser}@{RemotePC IP}:{Remote PC  directory} {HostPC path for RemotePC directory}

SFTP technique(Fast)

From HostPC Linux to RemotePC Linux

For Single File Transfer
sftp {RemoteUser}@{RemotePC IP}
Now in the 'sftp prompt' use the following set of commands:
cd {Path on Remote PC for the HostPC file}
put {filepath on HostPC}


For Directory File Transfer
cd {path of the directroy HostPC}
sftp {RemoteUser}@{RemotePC IP}

Now in the 'sftp prompt' use the following set of commands:
cd {Path on Remote PC for the HostPC directory}
mkdir {dirname}
put -r {dirname}

Here the {dirname} is the directory on the HostPC that needs to be copied

SFTP technique(Fast)

From RemotePC Linux to HostPC Linux

For Single File Transfer
sftp {RemoteUser}@{RemotePC IP}
Now in the 'sftp prompt' use the following set of commands:
lcd {HostPC path for RemotePC file}
get {Path to Remote PC file name}


For Directory File Transfer
sftp {RemoteUser}@{RemotePC IP}
Now in the 'sftp prompt' use the following set of commands:
lcd {HostPC path for RemotePC directory}
lmkdir {dirname}
get -r {Path to Remote PC directory}

Here the {dirname} is the directory on the RemotePC that needs to be copied

These techniques are also valid for PC connected over the internet, provided your ISP allow SCP&SFTP and one is aware of the IP address the PC is connected to.

We have been working with the well known Stellaris Launch Pad, now known as the Tiva C Launch Pad. This was a quite transition however we found some subtle differences with the microcontrollers.

Stellaris Launch pad:


  • Used the LM4F120H5QR Microcontroller which is now renamed as TM4C1233H6PM
  • Original name for this Launch Pad: EK-LM4F120XL
  • Still available at TI e-Store link.
  • Important thing to note is the chips in initial version of the Stellaris Launch Pads were Engineering Sample versions so the chip name became LX4F120H5QR - Not very reliable !!
  • TI has released an official migration guide for Stellaris to Tiva C -This guide also contains the part number mapping for the new Tiva C Series
  • Also the support software for the Stellaris ware has been now changed to Tiva Ware - Important changes include the naming convention and C99 standard types

Summary of Links:

Hope that this list would be helpful. Let us know your comments on this.
We had some initial troubles in getting around with the Unity Interface of Ubuntu. One of the common problems was in creating short cuts for the UI.

We got some info from this source in Ubuntu Forum while searching.

Here is the explanation and step-by-step procedure:
1. Open your favorite editor with an "ApplicationName.desktop" file
     We use 'gedit' so we give the command:
gedit ApplicationName.desktop
     The 'ApplicationName' field here needs to be replaced with your desired application's name.

2.  Now write the following into the file:
[Desktop Entry]
Name=ApplicationName
Comment=Comment_To_Be_Displayed_when_Mouse_Hover
Exec=/path/to/executable
TryExec=/path/to/executable
Icon=/path/to/application_icon_file
StartupNotify=false
Terminal=false
Type=Application
Categories=Main_Category_of_Application; Sub_Category_of_Application

Here the following Fields are required:
  • ApplicationName - This is the name that you have earlier given to your desktop icon
  • Comment_To_Be_Displayed_when_Mouse_Hover - This is a comment that would be displayed both on the Ubuntu Unity panel as well as if placed on the Desktop
  • /path/to/executable - This is actual path to the install directory of the application that you wish to create the short cut for
  • /path/to/application_icon_file - This is the application icon file that can be a .ico or a picture file with 48x48 max pixel dimension.
  • Main_Category_of_Application - This is an optional parameter, it can be any of the standard application categories that you find in the Ubuntu Software Center - Accessories, Education, Games, Graphics, Network, Office, Development, System .etc.
  • Sub_Category_of_Application - This is sub category under main category - for more info refer to this page: https://wiki.ubuntu.com/SoftwareCenter#Genre
3. After save this file into the correct directory and close the editor.

4. To install the icon to the Dash-Home of the Ubuntu Unity give the following command in a terminal window:
xdg-desktop-menu install --novendor /path/to/ApplicationName.desktop
Now your icon would be available on the Dash-Home.
Next if you need this to be on the Unity Bar - just run the program and right click to 'Lock to Launcher'.

Hope that this was helpful, let us know your feedback.
It might be surprising but yes we wish to provide a simple guide to perform 8051 development under Linux. For many 8051 might be history but its still relevant for starters.

The amount of study material already available along with a base of example and help available on topics related to this microcontroller architecture makes it a easy choice. Although the same is true for AVR,PIC or the grand ARM, but the simplicity of this controller cant be compared with any one of them. In fact we had this microcontroller is several of our projects and endeavours in the past decade. So we decided to pay our tributes to this grand old microcontroller with the help of this article on how to start and effectively perform development on this controller under linux.

One of our friends recently too up a project of building a CNC router. The idea was to make a Open source router framework that can be used for 3D printer, Cutters, painters etc.
NEMA 17 Bipolar 4-wire Stepper Motor
However he had surplus motors so he wishes to see off the excess motors at reasonable rates. He requested us to put this up so that people can buy these motors, and here we are with the post for the same.

Specifications of this NEMA 17 Bipolar 4wire Stepper motor:
  • Motor Properties:
    • Motor Type: Bipolar Stepper (2 Coils)
    • Step Angle: 1.8 degree
    • Step Accuracy: 5%
    • Holding Torque: 4.0 Kg cm @ 1.7A
    • Rated Torque: 3.4 Kg cm @ 1 A
  • Electrical Characteristics:
    • Motor Coils: 2 Coils
    • Rated Current: 1.7A
    • Recommended Voltage: 12V (Full Stepping), 9V (Micro-stepping)
    • Coil Resistance: 2 Ohm
  • Physical Properties:
    • Mounting Plate: NEMA 17
    • Motor Length: 40mm
    • Shaft Length: 24mm
    • Shaft Diameter: 5mm
Mechanical Dimensions
Coils and Colors
You can contact him through this form and he would be happy to help you out with any details you may need.
We have been searching for a consistent source to obtain a stable releases of AVR tools on Linux. Here is what we came across recently.

This is Atmel's Official link supporting the Linux Tool chain for  AVR-8 and AVR32 architectures:
http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx


However the support of AVR32 AP7000 has been removed only thing that remains is the Build Root for AVR32 AP7000: http://www.atmel.no/buildroot/
We wondered if the Linux prompt can be more snazzier that we have it by default dull type.
To something more interesting:
This magic is using the 'PS1' environment variable in Linux.
Here is the command that does this magic:
PS1="\n\[\033[1;37m\]\342\224\214($(if [[ ${EUID} == 0 ]]; then echo '\[\033[01;31m\]\h'; else echo '\[\033[01;34m\]\u@\h'; fi)\[\033[1;37m\])\342\224\200(\[\033[1;34m\]\$?\[\033[1;37m\])\342\224\200(\[\033[1;34m\]\@ \d\[\033[1;37m\])\[\033[1;37m\]\342\224\200(\[\033[1;32m\]\w\[\033[1;37m\])\342\224\200(\[\033[1;32m\]\$(ls -1 | wc -l | sed 's: ::g') files, \$(ls -lah | grep -m 1 total | sed 's/total //')b\[\033[1;37m\])\n\342\224\224\342\206\222> \[\033[0m\]"

There are 3 parts to this magic:
  1. Usage of Special Unicode characters:
    Looking at the beginning of the line you might have noticed the char '┌' which is U+0x250C. This is a UNICODE character to make top left border. In order to find the right string to code the PS1 variable you would need to the octal codes for the special char. To get that we have these commands:
    • If you know the code of the char:
      echo -e "\u250C" | hexdump -v -e '/1 "%03o "' | awk '{print "\\" $1 "\\" $2 "\\" $3 }'
      This is for the top left border char that we are talking here. It would print:
      \342\224\214
      
      This is the code you can now use in the PS1 variable definition.
    • In case you know the char it self then:
      echo ┌ | hexdump -v -e '/1 "%03o "' | awk '{print "\\" $1 "\\" $2 "\\" $3 }'
      This gives you the codes again in the same manner as the earlier one.

    In order to get further info you can visit the following links:
    http://www.unicode.org/charts/ - Here you get all the charts for Unicode characters
    https://wiki.archlinux.org/index.php/Color_Bash_Prompt
  2. Special formatting for the normal user and the root user:
    The piece of the variable that does this job is -
    ($(if [[ ${EUID} == 0 ]]; then echo '\[\033[01;31m\]\h'; else echo '\[\033[01;34m\]\u@\h'; fi)
    This would ensure that if the user is root the only the host is printed else the user name @ host is printed.
  3. Finding the Number of Files and the total size:
    This part is done in two folds -
    First part is the number of files that exist in the current working directory:
    \$(ls -1 | wc -l | sed 's: ::g') files,
    The next part is the total size of all files under the directory(no including sub-directory sizes):
    \$(ls -lah | grep -m 1 total | sed 's/total //')b
This make a nice way to work on Linux with style. The possibilities are only limited by your imagination and few time.
Inspired by the Archlinux wiki: https://wiki.archlinux.org/index.php/Color_Bash_Prompt
    We recently stumbled across a good source of concepts related to physics and nature. This has the simplest URL: http://physics.info/
    This is a helpful resource to revisit the concepts and understanding of Physics. We found this resource to be really helpful and hope it would be useful for you too.
    As you may know from our earlier post we have completely shifted our developments to Linux. This post is to describe the process of installing the pyserial package into Linux.
    You can visit the pyserial page for locating the documentation: http://pyserial.sourceforge.net/

    Here is the step by step process to perform the installation:
    [1] Getting the Files
    You need to download the pyserial: https://pypi.python.org/packages/source/p/pyserial/pyserial-2.6.tar.gz#md5=cde799970b7c1ce1f7d6e9ceebe64c98
    If this download link is not valid then go to: https://pypi.python.org/pypi/pyserial
    You might observe that the version that we are downloading is the Python 2.6 supported but do not worry - we have tested this and it works for Python 2.7.

    [2] Check if you have python installation in Linux
    We are using Ubuntu 12.04 version of Linux so our package updater is 'apt-get'.
    In Ubuntu we have python 2.7 available by default. However for some other Linux distros that might not be the case, so try to check for online help regarding installation of python v2.7/v2.6 into your specific Linux distribution.
    To test if python is present or not type python in the terminal window. you would get a prompt like this:
    Python 2.7.3 (default, Aug  1 2012, 05:16:07)
    [GCC 4.6.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>>
    
    Next type - exit() - this would exit python interpreter and bring you back to the shell prompt
    [3] Extract and install the pyserial package
    The pyserial package is a tar.gz type archive so you need first go to the directory where it has been downloaded in the terminal.
    Next give the following set of commands:
    1. Extract the Archive
      tar -zxvf pyserial-2.6.tar.gz
    2. Go the pyserial directory
      cd pyserial-2.6
    3. Build the package
      python setup.py build
    4. Install the package
      sudo python setup.py install
    Now the package is ready to use and installed.

    [4] Testing the installation

    The pyserial package comes with the miniterm.py scripted python program. We would use this to test pyserial installation. We have connected a USB to Serial Pl2303 based converter at /dev/ttyUSB0
    We can use this miniterm tool to connect to the serial terminal at 9600 baud rate.
    Give the following command on the terminal prompt:
    miniterm.py -p /dev/ttyUSB0
    You would get the following prompt:
    --- Miniterm on /dev/ttyUSB0: 9600,8,N,1 ---
    --- Quit: Ctrl+]  |  Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
    

    This means that the pyserial is successfully installed and ready for use. Hope this article has been helpful. Let us know your suggestions and feedback.
    A friend of ours is working on a commercial project for low cost timing module. He request us for some help regarding designing a Mono-Shot timer. In general the circuit was using a NE555 in mono shot configuration. The problem was that he needed the mono-shot to start at power up and also it should be re-trigger-able with a button. And all this with the minimum set of components.

    We were trying to have a complete 8-bit port on ATmega8 and at the same time implement Objective Development's V-USB stack to communicate with the chip.

    We have been using Simplicity tool for EFM32 and evaluating on how to make good use of this tool. In that quest we found several tricks and mods around this tool. So we would like to share these useful tips for the benefit of the EFM32 users.


    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.

    In our last post we came to know about the process of configuring the core clock for EFM32. Basically how to make the Coretx-M3 clock from the External Crystal source HFXO.
    Next we would take a detailed look at the Energy modes in the EFM32 microcontroller. Again we are going to use the Keil MDK with GCC and the STK3700 kit.
    In the EFM32 Microcontroller the Energy Management Unit(EMU) takes care of the setting the power, reset and clock-gating. Additionally it also takes care of Brownout detection for resetting the MCU if the voltage falls below a specified threshold to prevent spurious code execution. However we would focus more on the Energy modes that govern the operation of the Microcontroller core as well as its peripherals and clocks. This might be a bit confusing that CMU is responsible for clock then why EMU. Yes, the CMU is for conguration of the clocks, clock-gating and dividers, but the oscillator control also has additional parameters that are decided by the EMU. We would cone to clarity on this soon.

    We have been doing quite a bit of development on low power Cortex-M3 microcontrollers. There were many nice lessons in low power design that we learned on our way. We would like to share this as a series of articles to helpful for making energy efficient designs.

    We are really impressed by the low power features of EFM32 and wish to share a step by step guide in order to finally make a complete system that is more power efficient without compromising on the performance.
     One of the key components of a Microcontroller based system is the clock. This would ultimately decide the amount of switching that would take place inside the microcontroller. Finally the performance through put of the Cortex-M3 is again dependent on the clock, although not completely.
    Thus the first and most important thing in a low power design would be to design the clocks properly and make sure that unused logic on the microcontroller is "clock-gated" when not in use. The term "clock-gating" means that we would prevent the clock from entering a particular peripheral or bus or even the CPU core when its not being used. The reduction in the spurious clock to unused peripherals would result in significant reduction in power consumption due to reduced switching losses.

    Welcome to Adhar Labs's Blog

    Popular Post

    Blogger templates

    Welcome

    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 forbharat.wordpress.com and m8051.blogspot.com.

    Permissions beyond the scope of this license may be available at http://forbharat.wordpress.com/permissions/.
    Thank you for all your support.

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

    Follow by Email

    Followers

    PCB Unit Converter

    mils
    mm

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