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.