Tuesday, October 25, 2011

Uploading an executable program to MSB430 mote

 Even though most of the times I write programs for sensor motes with Contiki operating system, there are situations where we have to write applications that can run independently on motes without an operating system.

When working with Contiki OS, we don't have to worry about uploading our program to mote. As an example if we have a Contiki program named my_app.c we can compile it and upload to a MSB430 mote by issuing the following commnad.

make TARGET=msb430 my_app.u

It will compile our program with the Contiki OS and burn it to the flash memory of the MSB430 mote. But if we write applications without Contiki, we have to take care of compiling and burning it to mote separately. As an example take a look at the following program saved as blink.c which can blink the LEDs of MSB430 motes. It doesn't rely on any operating system routines.

1:  #include <msp430x16x.h>  
2:  int main () {  
3:  int i,j=0;  
4:  P5SEL = 0x00;  
5:  P5DIR = 0xff;  
6:  while (1) {  
7:       for (i=0 ; i<2000 ; i++){  
8:            P5OUT = 0x00;  
9:       }  
10:       for (j=0 ; j<2000 ; j++){  
11:            P5OUT = 0xff;  
12:       }  
13:  }  
14:  return 1;  
15:  }  

We can compile this program by issuing the following command.

msp430-gcc -mmcu=msp430x1612 blink.c

The parameter -mmcu is used to specify the architecture type of the microcontroller that our executable code is intended to run. Here we have given the type of MCU that resides in the MSB430 mote. This command will create an executable file as a.out which can run on MSB430 motes. So it's time to upload it to mote.   

For this, I use a little trick. Contiki source code contains a tool named as PyJTAG which will be used to write a compiled Contiki application to motes flash memory. We can use the same tool to upload our program to mote. You can find that tool in the following location in the Contiki source code.


Copy that whole pyjtag directory to some other place like your desktop. Now copy the executable program that we got (a.out) to the inside of that new pyjtag
directory. Now open a terminal and goto this pyjtag directory from it.

Connect the MSB430 mote to the parallel port of the PC and give permissions to access it by issuing the commnd,

sudo chmod 777 /dev/parport0

Issue the following command to erase the current content of flash memory of MSB430 mote.

python jtag.py -l /dev/parport0 -m

Then issue the following command to burn our a.out program to mote.

python jtag.py -l /dev/parport0 -D -D -S -R 2048 -p a.out

 After this command completed you will notice that LED of the mote is blinking. If so, you have successfully burnt an independent program to a MSB430 mote without an operating system.

Monday, October 24, 2011

Ending Words of a Chapter

Life is so much exiting and interesting. Last seven months of my life offered me so much things and added a new value to me. My time spent in the WASN laboratory was a dream that I had from a long time to be a real Computer Science researcher. It offered me to explore the potential of my capabilities. I received the opportunity to work with so many really intersting people and learn from them every bit and byte that I should have known to be a real scientist.

The project works that I have been involved through the internship period belongs to two different areas in Computer Science. First one is Computer Forensics and the other is Wireless Sensor Networks(WSN). From these two different fields I'm in love with the second one which contains almost all the things that impressed me all over my journey in Computer Science. 

    At first hand, WSN takes you to really a lower level in computers. You have to deal with embedded platforms where your capabilities are very limited. The processing power of your CPU, the capacity of your RAM are really limited. Therefore your program codes can't be written in too much highlevel languages with heavy APIs. Your preferred laguage will be C or something below it :). In simple terms, you are naked on the Silicon wafer. You are on your own.

    This is where everything that they taught you in Computer Systems, Operating Systems and System Programming courses comes to help you. If you were sleeping at those lecture halls, you will feel sorry at such a resource constraind environment like Wireless Sensor Networks.

Another intersting thing that I met in WSN related works is that there are lots of networking stuff. You have to deal with different routing protocols, data packets etc. All the communication that you will do inside a wireless sensor network has to be done in an energy efficient way. This is because it is not only the CPU power and memory capacity that puts you in trouble. You are running on a battery and it's capacity to power you is also limited. The deadliest thing that can happen to you is running out of battery power. And thats all about WSNs.

    My internship is over. Now I'm infront of another change. I'm starting my fourth year which is obviously the final one. It is a very rare opportunity since they select only 40 people out of a batch of 160 people to do a fourth year. So, I feel I'm privileged to do it. There are so many things in my mind that I have to do during that year. Specially I have to work for more publications. Publishing only final year research is not enough. I need more. Therefore I hope to continue my works in the WASN laboratory during the year ahead also. Our WASN laboratory is my fountain for new research experiences.

    Before ending this chapter I would like to remind here someone who helped me to climb the ladder of life so far. She is my grandmother. Our family have came across really hard situations from my childhood with financial problems. Aachchi(grandmother) was with us and she gave her helping hand to us when we were down. She always wanted us to study hard and achieve the best things of life. She passed away on 25th of last September. When life was hard she was with us. But when life is becoming better she isn't with us. She couldn't wait to see the best things and best achievements of her grandsons'. Thank you Aachchi for everything you've added to our lives.

Thats all about a chapter in the book of my life. Hope this book will have more chapters.

"Life is a school and we are here to learn.  Problems are simply part of the curriculum that appear and fade away like algebra class but the lessons we learn will last a lifetime"

                    - by Someone

Thursday, October 13, 2011

Working With XEN Virtualization

Recently I faced to a situation of loggin in to a Xen server and managing the domains of it. Our SVN version control system and a lot more runs on a linux server which is not actually running on real hardware. It runs on another linux operating system with the Xen virtualization. Our SVN recently got stuck due to lack of memory provided by the Xen virtual machine for it. This is where I have been asked to fix it by logging in to our main server where all these Xen virtualizations runs.

In simple terms, Xen is a virtual machine monitor for X86 architecture. You can install it on top of a linux operating system and then more guest operating systems can be installed on this host operating system to be run simultaneously on the host operating system. Xen provides tools to manage these guest operating systems. Xen is an open source software with GNU general public license.

Xen is very useful to utilize the actual hardware resources we have at the bottom level. As an example we have several servers with different public IPs running on the same computer under Xen virtualization. I think there may be so many advantages of Xen virtualization like security on the virtualized guest systems. However I know very few things about it because I just came through it very recently. There are so many things that I have learnt by experience rather by a formal method. This is another one of that experience list.

Since I'm not the guy who installed Xen on our main server, I have no proper knowledge about how to install and do the initial things with it. What had to do is to log into the main server and do different things with the currently running Xen virtualization. Xen provides a nice command called 'xm' which it the command that we use to do most of the things with the Xen server.

First I log in to the main server remotely using secure socket layer.

   ssh user_name@xxx.xxx.xxx.xxx

(these x values are representing the servers IP address)

After entering the password correctly I'm in. Then I can look at the current domains or the guest systems running on this main server. They can be listed by running this command.

    xm list

Each domain has a name. These domains are created by using configuration files that are resides in /etc/xen directory. Each configuration file name ends with the extension '.cfg'. Those configuration files can be used to create domains. Content of the configuration files can be viewed by openning them using the VI editer. The path to the kernel of the guest operating system, the mount of memory assigned to it, name of the domain are few of the information that is written in the configuration files.

The below command can be used to reboot a current domain which was listed by the previous command.

    xm reboot domain_name

You can destroy a current domain by issuing the following command.

    xm destroy domain_name

When you want to create a destroyed domain again with the help of available configuration file of it, you can do it with the follwing command.

    xm create -c configuration_file_name.cfg

This create command may take some time to complete.

These are the things that I've learnt unexpectedly. I know that I should read more about the Xen servers to have a more complete understanding about how the installation and configuration stuff is carried on. I will do it in the future. This is for now.

Monday, October 3, 2011

Tmote Sky Sensor Boards

Tmote Sky is a widely used sensor board in wireless sensor network research area. It is very light weight and operates with very ultra-low power. It contains Texas Instruments MSP430F1611 MCU module at the heart of the sensor board. This MCU contains 10kb of RAM and 48kb of flash memory. Tmote Sky is powered by 2 AA batteries. However unlike most of the other sensor boards, Sky motes contains a USB port on board which makes it possible to directly plug in to a PC.
Front Side

When connected to a PC, Sky motes can be powered from the power supply of the USB port. When using Sky motes as sink node(base station) in a sensor network, communication can be done with the PC through USB port. Wireless communication can be done with the CC2420 radio module. For sensing instruments Sky mote contains humidity, temparature and radiation sensors.

WSN operating systems like TinyOS and Contiki can be burnt into Tmote Sky motes for using in various wireless sensor network applications. Here I write down the way to burn a Contiki program into the Tmote Sky motes. The most advantages fact of Contiki programming in Tmote Sky sensor boards is that there exists hardware simulators to test programs before deploying on real motes.

Back Side

1) Since Sky motes contains a MSP430 MCU, we need GCC compiler tool chain to compile our program into Sky motes. If you haven't installed the toolchain yet, issue the following command on the Linux terminal to install these tools.

    apt-get update
    apt-get install binutils-msp430 gcc-msp430 msp430-libc msp430-jtag

2) We need Contiki operating system for this testing program. Therefore download it from here (http://www.contiki-os.org/p/download.html). Uncompress it to somewhere in your Linux machine.

3) In Contiki-2.4 there is an example LED blink application in the "contiki-2.4/platform/sky/apps" directory named blink.c. Copy this file to the "contiki-2.4/examples/sky" directory. Now go to that direcorty ("contiki-2.4/examples/sky") from the Linux terminal.

4) It's time to compile and test out program. Here we have two options. First one is to compile the program and run on MSPSIM simulators Tmote Sky mode. The other option is to run our program directly on real Tmote Sky sensor boards. To compile and run on MSPSIM simulator, issue the following command.
    make TARGET=sky blink.mspsim

Now the MSPSIM simulator will open up in the Sky mote mode. Simulator will show a graphical representation of the Tmote Sky sensor board and you will notice that its LEDs are blinking. To stop the simulator, type "exit" on the MSPSIM simulators prompt.

MSPSIM Simulator

5) Now we are going to run our application on real Tmote Sky sensor boards. For that purpose, connect a Tmote Sky mote to a USB port of the Linux machine and issue the following command.
    make TARGET=sky blink.upload

Now it will take few seconds to compile and burn the flash memeory of the Tmote Sky mote. Then it will start running. So, you will see its LEDs are blinking.