Well looks like its late again. About time we should call it a Biweekly update. Sorry about that first stuck with drivers for SX1231 and then lots of soldering on the way.

RFM69HW board, part of RFudaan project - WORKING!!
Also blogger for a change got updated recently. That's interesting, apart from blogger all other things Google have been modernized and made a lot AI.
My project to create a Golang based site generator, still needs to come out of being a paper drawing to a functional Go program. Till then I have to stay with blogger.

I had to do a lot of soldering to come up with the prototypes. Though the boards arrived 2 weeks back I think on 17th or so, it took me quite a while to chop them into pieces.
Thanks to Dangerousprototypes & Dirty PCB team for the great PCBs. Although this time around there were a bit of drill offsets all over. But my thumb rule of 20mil+ annular ring saves the day.

Its late mid week, but had to. Got busy with illness, work and failure. But for the effort invested it was worth the time.
This is a picture of the RFM69HW + Arduino Pro-Mini protype.

Well last week and first part of this week is what I am going to cover here.

Let look at the current running projects:

1. RFM69HW Light Sensor

As you have see above I have tried to make some protos after my successful experiment last week.
Here is the Proto that I had built with Old version of Seeeduino (v2.21) :
The picture is quite dark, sorry for that. Its basically a RFM69HW module soldered on to a general purpose board and then inserted into the Top Right connector of Arduino. And the red wire in front is the antenna. Apparently it broke off twice so I had to finally add some heat glue to fix it.
The best part is using a RTL SDR I could capture the transmission.
868MHz Transmission from RFM69HW - LDR sensor Values

Well of course you would remember one more proto using Arduino Micro:
So now with 3 Nodes transmitting the dance of the frequency spectra is awesome to watch.

Here are some Detailed pictures of the RFM69HW board with Arduino ProMini :

This time I had added an XC6202-3.3V regulator that is used to power the RFM69HW.
Hope that the PCB boards from DirtyPCB comes soon both LoRa and RFM.

2. RF-Udaan project

This is the LoRa board that includes the DRF1276G module. Again waiting to get both the modules as well as the PCB board.

3. Static Site Generator

After getting no where with HUGO, Pelican and Jekyll, I got an idea to write my own. Well that might be a bad idea but a good learning exercise. So some basic work is done on that too. Secretly working with golang since its the fastest and easiest for connectivity. The awesome part its a EXE which is very useful for people like me. I come from hardcore C and Assembly background. So any language that gives net connectivity within 5 lines and give Binary output is great. No framework or Virtual machine needed. Well hope that this would be another good exercise to learn the next generation language.

4. SIM900 Relay

A friend of mine asked me to design a GSM control relay. So I have started working on that too.
Currently using a Arduino UNO and a iComSat SIM900 Shield from iteadstudio.

SMS read was easy to do, now planning to make the interpreter part also.
All code would be posted soon, so watch out.

That would be all for this update, hope to see you next time.
This week lots of testing and RF sniffing. And problems with Windows.
Well my main Laptop gave up, it was Windows 7 Professional 64bit. Though its a beast of a laptop but updates caused a problem. Lenovo asked for an update to BIOS. It was already 00:30 IST and I agreed on installing that. That was all . Next day morning the same laptop stopped booting. After 3 formatting attempts , 2 hardware diagnostics attempts and banging the head 10 times on the wall. I found it was bug in the update of that night. Finally I had got the laptop to boot by disabling some thing called "Execution Prevention and Memory Protection". But by that time the Windows already had gone corrupt on the HDD. So I had to reinstall the complete Windows 7. And to add to the misery Windows Updates on Windows 7 Professional taking eternity to even search. Still waiting on that one.

Fortunately all the current weeks projects are on my PC which is alright. So we are safe to Proceed.
868MHz Transmission from RFM69HW - LDR sensor Values
Well this is an SDR-Sharp Plot of the RF transmission from my RFM69HW based prototype board. The Arduino + RFM69HW Sensor is sending out LDR sensor Raw values to another gateway board connected to the PC. Initially I used the RFM69 driver from Lowpower labs . Later I wrote my own to outdo the adventure.Interestingly the found that 18cm of Wire is an Ideal Antenna for RFM69HW boards. That part was success now working on Signal Reception to formulate a presentation layer protocol above the Raw communications.

Next project RF-udaan is still on track. The boards were already shipped from DirtyPCB. Hope to receive them by this month end (fingers crossed).

Not much progress on the Website porting side. As kept busy with the driver writing work.

Hope to catch up on more this week.
First of All :
Best wishes to all the readers and friends...

Well this week too even though a festive week, so work was achieved. Starting with the two main projects that are currently in progress:

1. RFM69HW Light Sensor:

Well this one got way ahead. I got to understand that RFM69HW has a Semtech Chip SX1231H which gives the +20dBm power capability. Tried out the Arduino RF69 driver from Lowpower labs. Still not happy with the performance and features available. Lot more info about this library is available on their website with better description of the packet structure. One more difficulty with this driver was that its written for the Mortino boards only so had to hack internals of the library. And after playing around with all that I got the insatiable urge that every geek knows of. Well I want to write my OWN LIB.
Bad luck radios are hard but it would be nice learning experience for me. All these days I have design RF hardware but could not venture into radio firmware. So just started to tinker around with the RFM69HW and its internals. I have made some headway in understanding the Frequency calculation for this radio module. That part and some insight would be for another post later. But watch out I will take this out and soon.

2. ESP-udaan board now RF-udaan (! Sorry !)

Well you might wonder what the heck one more name change. Well thats what developers and makers struggle with. For hardware engineers its : Naming things and Unlearning concepts.
You  might have guessed it right. ESP8266 has unfortunately removed from this board.
Well now this board has 2 Modules - RFM69HW (ISM) and DRF1276G (LoRa)
Additionally in the remaining space there is an Adapter for Arduino Pro Mini that would be used to control these boards. Also added are a DHT22 and LDR for sensing interface to Arduino board.
I placed the order with DirtyPCB service from Dangerous prototypes. I had used their service previously and was quite satisfied by the quality. Only problem it take more than 30days to get the boards some times !! Hope that it arrives in time before TheThingsNetwork deploy LoRa Gateways around Bangaluru.

Well there is more......
I could not just sit around so I started another project :

Static Site Generator

Well its in progress and its one thing I have been wanting to do for a long time. Blogger has become too unwelcoming. Its old and my idea was to move away from it. So I had already selected a few famous ones.

Evaluating all three of them , Not sure of Ruby so jekyll is ruled out.
Both Golang and Python are my favorites hence they are fighting each other in terms of features and easy implementation.
Once I have a successful theme even a bare minimum I will make a move to a per-created github website URI. Should leave the old for RIP.

That's all for this week, check out more next week.
This week was pretty hectic with lots of things going on. However there were two main projects that a currently progressing:
  1. LoRa + RFM Board
  2. RFM69 Light Sensor
LoRa RFM Board
RFM69 Light Sensor

 Well about the LoRa RFM board ( bad name sorry ! )  this one is a long time though Idea. I wanted to have an Arduino enabled LoRa board. Then I had need to work with RFM modules from HopeRF. So I combined all the requirements together + added our favorite ESP8266 into it. Then came the ESP-Udaan project. So now on this board would be called ESP-Udaan not the weird long name. The board is designed such that one can program an Arduino Pro Mini or the ESP8266 as needed. Plus the would be flexibility to expand using the edge connectors. I have also provided one small I2C connector at the bottom of the board to connect the DS3231 Raspberry Pi modules for RTC. That would make this into a good IoT node. Watch out next week for some more updates.

Next, the RFM69HW Light sensor. This is an attempt to build an out door light sensor using RFM69HW and an Arduino Nano clone. I am using a 868MHz module since that's whats legal in Bharat(India). This would gradually make the framework for the ESP-Udaan board. Since that too has the same profile. Added to the bread board crooked wiring is a TLV-2217-3.3V Texas Instruments LDO. As I wanted to have good power available so connected the RAW output of the Arduino Nano (means the USB input power) to this regulator generating 3.3V. The Tranceiver powered up comfortably and got response back. The software is still work in progress.

That would be all for this week checkout the build progress next week and more.

Its already been 2 years since I last posted.
You might already be noticing the change, and  in what way this blog will be written in future.
From now on the blog will have only myself @boseji and no more the team.

We started around 2009 a team of 8 people committed to create good content on the net about Electronics, Embedded, Linux, Physics and various other outlandish ideas. However eventually in the course of time everyone except myself dropped out.

Most people might have seen only my credentials on the blog as the final publication was only done by me. The team was suppose to create the content and hence the term "We" was used in most cases. The content for maximum cases was being compiled by @boseji and reviewed by others. It was a constant wish of everyone to get their name on the blog. That was possibly the point of departure. Unless someone brings about original content, spend hours in actually typing and proof reading the articles; they are just can't post it. No one realized that hard work that goes into doing so.
Well that might be me complaining about them.

I still kept going for the next 5 years till 2013 and then I became quite busy at work.
All contacts started dropping out since then. Even though the contributions were scanty from the team, there used to be little innovation call-ups and new product ideas. All of that came to a screeching halt. And there was silence afterwards.

It was after a lot of persuasion and recommendations of the followers still on this blog & family, that I am taking the baton again.
Even though it might be only me, I will try to keep my promise again and keep moving forward.

Thank you dear readers & friends for all your support.
We had been silent on our adventures with the latest Android version Lollipop. So here is it, the most simple and easy to follow build instructions for compiling Android Lollipop from source starting from scratch (bare minimum Ubuntu 14.04 PC with Internet and above 40GB usage remaining).

Its been long that this post has been in Draft  about 2 years so Lets go ahead and complete this.
All credit goes to : http://forum.xda-developers.com/chef-central/android/tutorial-compile-lollipop-ubuntu-t2929410

Here are the Compilation commands:

>repo init -u https://android.googlesource.com/platform/manifest -b android-5.1.0_r1 

>repo sync -j4  
>sudo apt-get install openjdk-7-jdk 

>sudo apt-get install bison g++-multilib git gperf libxml2-utils make zlib1g-dev:i386 zip 

>sudo nano /etc/udev/rules.d/51-android.rules 

>javac -version 
Should be Open JDK 7

>sudo update-alternatives --config java 

>. build/envsetup.sh 

You're building on Linux  Lunch menu... pick a combo:      
1. aosp_arm-eng      
2. aosp_arm64-eng      
3. aosp_mips-eng      
4. aosp_mips64-eng      
5. aosp_x86-eng      
6. aosp_x86_64-eng      
7. aosp_flo-userdebug     
8. full_fugu-userdebug      
9. aosp_fugu-userdebug      
10. aosp_deb-userdebug      
11. aosp_tilapia-userdebug      
12. aosp_grouper-userdebug      
13. aosp_hammerhead-userdebug      
14. aosp_mako-userdebug      
15. aosp_flounder-userdebug      
16. m_e_arm-userdebug      
17. mini_emulator_x86-userdebug      
18. mini_emulator_x86_64-userdebug      
19. mini_emulator_arm64-userdebug      
20. mini_emulator_mips-userdebug      
21. aosp_shamu-userdebug      
22. aosp_manta-userdebug  Which would you like? [aosp_arm-eng]    

Selected  12. aosp_grouper-userdebug  for Nexus 7 2012 tablet


>make -j4 

Takes 2hours 30minutes on Quad Core operation

This time its become much Simpler and easier to compile. No need to too many complex installations.

As promised this time we would be discussing further on the Backup Power Domain and special Shutoff Mode EM4. Initially we looked at how the EFM32 can be transitions to various power states. However "there is more to this chip than that meets the eye".

The EM4 mode of this chip is way more configurable and can be very useful. Its only that we need to take some system design considerations into account before using this mode.
Let us review the conditions of the peripherals for this mode:

---- This was a 2 years old incomplete post
It looks like that EM4 is very difficult to plot with the power analyzer. I had abandon that.
Sorry folks that would be all.

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:

Rpi Connector      ST7565 LCD
3.3v (Pin01)     - LCD Back A
GND  (Pin09)     - LCD Back K
GND  (Pin06)     - GND
3.3V (Pin17)     - VCC

GPIO24           - A0
GPIO25           - nRST

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
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
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
  • sudo ./lcd sleep - Used to put the LCD into Low power mode
  • sudo ./lcd wakeup - Used to restore the LCD from low power mode

The source code of this driver is available on Github: https://github.com/boseji/Rpi-ST7565-SPI-LCD

Our next goal is to build this into a frame buffer driver then the display can be used as an output display for the Raspberry Pi. Let us know your feedback and comments.
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.

a. Check for Programmers connected
'atprogram list'
Here is a template output:
Output for list command
In this case the output shows a AVRISP mkII programmer connected with Serial Number '000200208327' . This serial number is important to distinguish the Programmer

b. Listing chip parameters:
'atprogram -t avrispmk2 -s 000200208327 -i isp -d atmega328p info'
  • '-t' specifies the Programmer Name.
  • '-s' specifies the Serial Number
  • '-i' specifies the Programming interface in this case 'ISP'
  • '-d' specifies the device name ATmega328p

Here is a sample output:

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.
  •  '-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.

  • '-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

e. Program EEPROM:
'atprogram -t avrispmk2 -s 000200208327 -i isp -d atmega328p program -ee --verify --format hex -f eeprom.eep'
This programs the EEPROM again using the program command.
  • '-ee' specifies the EEPROM memory needs to be programmed.
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.

Downloads Folder : http://goo.gl/O7TVrN

For 64bit use: avrdude-win-64bit.zip
For 32bit use: avrdude-win-32bit.zip

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 ATmega328p
avrdude -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.
We have been having difficulty in installing some of the Python packages on windows. For example PIL, GTK+ all in one .etc.

We took help from http://effbot.org/ famous for the Tkinter book that we have used several times for our other projects. There was a specific technique mentioned by which one can add the Python installation to the system Registry. This would allow us to install the other Python packages.

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.

Here is a list of the packages that we tested:
  1. Py2Exe
  2. cx-Freeze
  3. PyInstaller
We created two sample programs for this.

Command line Program:
GUI Program:

In order to use these packages here are the installations needed:
  1. Open Command prompt using cmd command in Start Menu
  2. 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.
  3. Now for pip installations use the following Commands:
    pip install cx_freeze PyInstaller virtualenv
    pip install wget - In case one needs a download manager
    pip install --upgrade cx_freeze PyInstaller virtualenv - For upgradation
  4. Download the Py2exe Installations:
  5. Download the PyWin32 Installation:
With these we are ready to for creation of the executable Apps.

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:
from distutils.core import setup
import py2exe
The command used is:
python setup.py py2exe
We have both the setup.py and runner program run-py2exe.py.


We have tested all the three, we found the cx-Freeze to be best unless we would need to many external modules then PyInstaller is better to use.

We have included all this info and created 2 Github Repositories:

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

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

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

[1] Update Raspbian on RPi:

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

[2] Load the Utilities needed:

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

[3] Configuring the I2C on Raspbian:

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

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

[4]Checking the I2C busses:

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

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

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

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

[5] Installing WiringPi on Raspbian for RPi:

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

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

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

[6] Connecting RTC to Raspberry Pi:

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

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

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

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

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

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

Welcome to Boseji's Blog

Popular Post

Blogger templates


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


PCB Unit Converter


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