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)
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
Micro SD card (I bought a SanDisk-Ultra microSDHC 16GB card)
5V Power supply with a center positive barrel connector (I bought one which can provide 3 A current)
A wifi dongle (I bought a $4 cheap RTL8188CUS based wifi dongle)
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.
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.
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.
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.
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 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)
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.
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.
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.
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.
Things you need to download. (Links are embedded and are working at the time of writing)
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.
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.