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.
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.
Texas Instruments chips are renowned for their low power operations. In this example I will go through basics of the hibernate module available with Stellaris devices which enables the user to put the device i low power mode. This module becomes trivial in low power consumption demanding applications. They claim that the processor only consumes around 6 micro amperes of current when it is configured to work in the hibernate module. Within this article I will refer to the datasheet of the device where applicable.
It is fairly easy to use the hibernation module in the Stellaris devices through their “Peripheral driver library”. Also the module is very well explained in the datasheet. So I recommend everyone to go through the datasheet and understand the behavior of the module prior to coding. At-least, that is my approach. The hibernate module related information can be found in Chapter 7.
The Stellaris launchpad PWMs will be deceiving if you start the design by reading ‘Stellaris® Peripheral Driver Library’ instead of the “LM4F120H5QR” datasheet. You will assume that it has hardware PWMs and you will directly use the PWM APIs available in the driver library. Unfortunately this is not the case with the launchpad. It does not have seperate hardware PWM modules but it has timers which can be configured as PWMs. I will be explaining how to configure the PWM modules available in timer0 andtimer1 to drive the R,G,B LEDs available in the launchpad.
First thing you need to understand is the architecture of the Timer modules. These timer modules contain six 16/32 bit timers and six 32/64 bit timers. Each of these twelve timers can be further divided into two independent timers named as TimerA and TimerB. These can be configured to operate separately or can combine.
a 32 bit Timer0 has 16 bit Timer_A and 16 bit Timer_B, a 64 bit Timer1 has 32 bit Timer_A and 32 bit Timer_B. Refer to the Chapter 11 of the datasheet for more information.
Then you need to know what are the pins connected with the Launchpads LEDs and whether we can drive them using the PWM signals. If you refer to the Stellaris Launchpad Pinmaps, you will understand that PF_1, PF_2 and PF_3 will be respectively connected to RED, BLUE and GREEN LEDs.
Also if you refer to Table 11-1, Table 11-2 and Table 10-2 in the datasheet you will understand that
PF_1 can be driven through T0CCP1 (Timer 0 Timer B),
PF_2 can be driven through T1CCP0 (Timer 1 Timer A) and
PF_3 can be driven through T1CCP1 (Timre 1 Timer B).
That is all the hardware information you need to know. After that you need to go through the ‘Stellaris® Peripheral Driver Library’ to understand how to configure the Clocks, Timers and GPIO pins. (more…)
It has been a while since I added something to the blog. These days I am working on a cheap wireless module, but it is giving me a lot of trouble due to duty cycle imperfections. Therefore I needed a logic analyzer to check the logic levels being transmitted and received.
I came across a few very useful websites which directed me to the product SLLogicLogger. You can find the product details here.
Make sure you adhere to all the guidelines given there, specially about the RB0 and RB1 pins which are not 5V tolerant.
One of the major issues of this project is that it is infact not a Logic Analyzer but a Logic Logger which can only scan the channels for a period of around 1.5ms. Which is very small period. So if the data rates that we use are really high we can get a good output. Lets say that our synchronization method is sending a stream of ‘1’s and ‘0’s with 1ms period, then this Logic Logger would not be able to assist us much. But for higher speeds this is really effective.
Last few weeks I have been working with RF modules to establish a wireless communication link between two systems. But most of the times my efforts were a failure. I had an MSP430 Launchpad, Stellaris Launchpad and two NRF24L01 modules. In order to check whether those wireless modules are working I had to setup a wireless communication link. I thought it would be easier for me if I used the available Stellaris and MSP launchpads for this task.
I started threads and followed some more on 430h and Stellaris forum.