I2C communication in BeagleBoneBlack

A bit of a background.

I wanted to log temperature and humidity in my room for no reason and I wanted to do it on my BBB. My plan is to post this data to a web application as an experiment, because I have never ever done web apps in my life.

I’m going to use the Si7021 module which I bought from core electronics (here is the link)

Adafruit Si7021 Temperature & Humidity Sensor Breakout Board ADA3251 Adafruit in Australia - Express Delivery Australia Wide (Feature image)

Setting up the BeagleBoneBlack (BBB)


The main purpose of this blog entry is for me to remember what I did to configure the BeagleBone-Black single board computer.

A couple of years back (somewhere around 2014) I was working on projects primarily ran on Embedded Linux operating systems. I purchased a BeagleBone-Black to learn driver development, kernel internals, etc.. However, I did not have time (or rather priority) to do any projects on these boards. Fast-forward 6 years, and now, somehow I feel like I have some spare time to dedicate to hobby projects.

My BeagleBone-Black still lives in it’s original packaging and last week I decided to get it updated to the latest operating system. I checked what version I have in the eMMC and realized that it is the ancient version that the manufacturers originally flahsed way back in 2014. The Angstrom distribution which is now tagged as outdated.

I’m going to list down the steps I followed to get the board updated with the latest BeagleBone-Black image and setup wifi.

List of things to buy

  1. Micro SD card (I bought a SanDisk-Ultra microSDHC 16GB card)
  2. 5V Power supply with a center positive barrel connector (I bought one which can provide 3 A current)
  3. A wifi dongle (I bought a $4 cheap RTL8188CUS based wifi dongle)

Flashing the latest firmware


  1. Beaglebone black – Getting Started
  2. Link to latest (as at 20-05-2020) debian image


  • Download the SD Card format software (Balena-etcher)
  • Download the latest debian image
  • Flash the debian image to the microSD Card using ‘BalenaEtcher’
  • Remove power from BeagleBoneBlack
  • Insert the microSD card
  • Apply power to BeagleBoneBlack while holding the UserBoot button
  • Once the 4 blue LEDs are ON, let go of the button
  • Connect the board to PC
  • Wait for sometime for the device to boot
  • Once it is booted, connect to using your favorite SSH client
  • Issue the command:
debian@beaglebone:~$ cat /etc/dogtag
  • Output for me is:
BeagleBoard.org Debian Buster IoT Image 2020-04-06
  • Open /boot/uEnv.txt and change the following line
##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync


#enable Generic eMMC Flasher:
#make sure, these tools are installed: dosfstools rsync
  • Reboot the BeagleBoneBlack
  • Now you will see that LEDs will be fading left to right and it is the cue that the image is being flashed to eMMC
  • This took around 20~30 mins to complete.
  • Once the flash operation has completed, the LEDs switch off
  • Remove the SD CARD and apply power again
  • Now it boots from eMMC and check the version again. You should get the same dogtag as above
BeagleBoard.org Debian Buster IoT Image 2020-04-06
  • Done!

Setting the default boot to be SD CARD


  1. https://www.erdahl.io/2016/12/beaglebone-black-booting-from-sd-by.html


  • Connect to BeagleBoneBlack terminal
  • Execute ‘lsblk’ command


  • Find out what is the microSD card (In my case mmcblk0 because it is 16 GB)
  • Execute ‘sudo fdisk /dev/mmcblk1’
  • Then select ‘a’ to toggle bootable flag
  • Then select ‘w’ to save and ‘q’ to exit
  • Then execute ‘sync’ and ‘reboot’
  • Now you should be rebooting in microSD card
  • You can confirm this by using ‘sudo fdisk -l’
  • In my case it looks like below (notice the * under /dev/mmblk0p1 boot column)


  • Done!

Setting up wifi

This is super easy now with connmanctl!


  1. A guide by Digikey


connmanctl> enable wifi
connmanctl> scan wifi
connmanctl> services
output: <WifiName> <WifiLongName>
connmanctl> agent on
connmanctl> connect <WifiLongName>
connmanctl> quit

That’s it!

I hope it helped.

Using ‘printf’ in microcontrollers

We, as electronics enthusiasts, daily write hundreds of firmware code segments for various microcontrollers. Unlike software, when it comes to debugging microcontroller code, the challenges we face are much more fundamental. I believe that the most common method for debugging firmware is using the good old printf (just like the cout in C++ and println in Java).

When we develop conventional C code for Linux systems, printf works without any hassle. However, to enable the same functionality in microcontrollers, we need to peel away a layer in the C library and find out how exactly printf works.

How printf works?

As you may already know, printf function is implemented within the C library. I will not go through the full printf function definition. If you want you can read http://blog.hostilefork.com/where-printf-rubber-meets-road/. It’s one of the best write-ups I have seen.

However, the important part is, at the end of this function chain, printf calls another function called write. This is a standard system call in Linux, a part of kernel API. However, for microcontrollers, we don’t have such liberties and thus, we have to implement this function ourselves.


Raspberry Pi torrent box with AWS

This post is more or less a continuation of my previous blog post, Converting your Raspberry Pi into a light weight torrent box.

If you follow this post you will be able to develop your own fully functional and easily extendable torrent box for your personal use. Please note that there may be web sites which already have services similar and better than what I have implemented. We are here to learn how to do that aren’t we? Everyday is a school day!!!

BONUS!!! If my server is running now following link would allow you to check what I am downloading now. ūüėČ Copy and paste the below in your browser.

(For mozilla)


(For other)

Right click and select view source to display the status in a better format.

So far we have set-up the deluge torrent client in our RPi (RaspberryPi) and we have confirmed that it is operational. This step is very important to have a working torrent-box.

First I will go through the design or the architecture of the solution that I am going to develop.


Architecture1.vsdx.jpg (more…)

Converting your Raspberry Pi into a light weight torrent box

Raspberry Pi is one of the most common SBC (Single Board Computer) available in the market. It’s cost and performance makes the product very popular among tech enthusiasts. Even though the hardware details of the Raspberry Pi remains a mystery, the software support for the board is quite impressive. Almost all the required packages are ported and stable for RPi which makes it one of the best choices for prototyping.

I have a Raspberry Pi 2 Model B and I would like to transform my RPi to a light weight torrent box. I would like to be able to push torrents to the torrent box from any location and download the content. That way I will be able to utilize the available bandwidth of the inernet connection in the best possible way. I would also like to schedule torrent downloading time to get the maximum out of off peak internet usage.

In order to design a reliable torrent box we need several things.

  1. A torrent client
  2. An external storage
  3. A method to remotely push torrents
  4. A method to schedule torrents


Using dynamic payload lengths for NRF24L01 with PDLIB_NRF24L01

In the previous post I have mentioned about the library which I developed for the NRF24L01 module. In the first release I could not include some of the features it had, such as Dynamic Payload capability and Ack Payload capability. I have included those features in the version 1.02. Following is a small description about the changes.

Dynamic Payload

Dynamic Payload capability is very useful in communication. This enables modules to communicate using non-static payload lengths. For example if I don’t have this feature, in order to send 10 bytes of data among the modules, I will have to configure both the devices to accept 10¬†data bytes. Later, if I want to change the number of bytes to 15, I will have to reconfigure the devices.

However, with Dynamic Payload enabled we don’t need to do that. We can simply send data between modules without configuring the data length. But the maximum data length for NRF24L01 is 32 bytes.

To configure the feature, we only need to call the function NRF24L01_EnableFeatureDynPL() with the required pipe number after we initialize the module. Then we can perform communication using the same functions we used previously. (Please refer to the previous post for more details)


A portable NRF24L01 C Library for multiple hardware platform integration in Wireless Sensor Networking

For the last couple of months I have been working on a library for the NRF24L01 modules such that it would be easy to integrate multiple hardware platforms using wireless connections. The idea is to develop a library in C and make sure that the functions can be clearly separated, which would make things easier when porting the library for a different hardware platform. There can be similar libraries in the Internet at the moment but I did not try any of them except the Energia library which can be found here.

I believe Energia is a very good platform for rapid prototyping, but the Arduino like language is not close to the actual hardware modules. Following is the solution I have prepared which is written in C and is very much close to hardware. I believe this library can be used to connect different types of hardware platforms through nrf24l01 module. This is very important in Wireless Sensor Networking solutions because wireless nodes can have MCUs with different architectures. It reduces firmware complexity and module compatibility due to the uniformity of configuration.


Creating the ‘bin’ file using Code Composer Studio application.

This post is basically a memo rather than a comprehensive blog post. But it might be useful to someone out-there.

Code Composer Studio (CCS) is the main Integrated Development Environment (IDE) that is used to develop firmware for Stellaris and TIVA processors. The tool which is provided by Texas Instruments (TI) to write to the flash of the micro-controller is ‘LM Flash Programmer’.

In order to write our firmware to the micro-controller we need to convert it to the binary format. For this task we can usesome of the tools coming with the CCS distribution.


As shown in the above figure, we can add the following command to the Post-build steps section in the CCS build options dialog box.

“${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin” “${BuildArtifactFileName}” “${BuildArtifactFileBaseName}.bin” “${CG_TOOL_ROOT}/bin/armofd” “${CG_TOOL_ROOT}/bin/armhex” “${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin”

This line basically instructs the IDE to execute the ‘tiobj2bin’ application with some parameters. This will create the ‘bin’ file and store it in the build directory. Now we can use this ‘bin’ file with the LM Flash Programmer application to write to the flash of the Stellaris or TIVA micro-controllers.

Thank you.

Using ‘FreeRTOS’ in STM32 DISCOVERY board

Recently I have been learning bits about RTOS (Real Time Operating System). I decided to try one on the STM32-DISCOVERY board. There are many RTOSs that can be used for this task. But I wanted a very simple RTOS which could quickly get me started. I’ve heard about FreeRTOS and decided to use it as an experiment.


FreeRTOS is a very well documented RTOS. It is also free and open. It has many demonstrations(examples) and it even has general steps required to port the system to different compilers, processors and evaluation kits. To get things started quickly I wanted a compiling Keil project. I found a full project here which is compiling and can be directly put to the DISCOVERY board.

But the version of RTOS used in the sample project above is not the latest. (At the time of writing the post the RTOS version is FreeRTOS V8.1.2) I wanted to use the latest FreeRTOS and wanted to learn how to develop the project from scratch. I believe following guidelines and steps would help anyone who would require to create a FreeRTOS project in Keil for the DISCOVERY board.st

Things you need to download. (Links are embedded and are working at the time of writing)

  1. FreeRTOS package.
  2. STM32F4 Standard Peripheral Driver Library
  3. DISCOVERY board GPIO library. (Used in the main.c)
  4. Keil uVision IDE ( I will soon post a GCC port as well )


Configuring the UART for debugging Stellaris/Tiva launchpads

Both the Stellaris and TIVA launchpads have in-built USB VCP connections which can be used for debugging purposes. When the boards were connected to the PC we can see the COM ports appearing n the Device Manager. The post today will have a quick guide as how to use these to print some debug information. I have used the Stellaris launchpad for the experiment, but the TIVA launchpad also provides a similar interface.

By going through the schematics of the launchpads we can understand how the USB debug connection is made.


Here we can see that the UART0 of the IC is connected to the In-Circuit Debugger. UART0 means PA0 and PA1 pins, therefore we need to configure them in order to use this interface.

Following code will configure the UART0 and write a character to the console window.

<pre>	SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);





        UARTCharPut(UART0_BASE, 'a');

Above code can be used to configure the UART0 interface and put the letter ‘a’ to the terminal window.

In order to make it more debug friendly I have created two functions, one for Init and another to display a string and a hex data value. It is very helpful when debugging firmware. More comprehensive library is available at ‘Stellarisware / Utils /’ directory with the name ‘uartstdio.c’. But it is quite large. This link¬†will have a miniature version of the required components.

Currently I am using it for debugging purposes. Might come in handy to you too. If you come across any issue, put a comment here.

Thank you.