In my previous post, I have shown the step-by-step guide to compile the basic hello-world demo of Contiki 2.7 for CC2538DK on Windows. Looking into the list of examples, the Contiki 2.7 is also delivered with a CC2538DK specific example which is located under contiki-2.7/examples/cc2538dk. The example shows basically basic input-output operation (push-button input, LED output), and also basic Rime broadcast communication (Rime is the light-weight wireless protocol used in Contiki).This blog post describes step-by-step guide to compile, run, and analyze the cc2538dk example of Contiki 2.7.
The CC3000 comes with an interesting way on how to passing the information of WLAN network (SSID and password) to the CC3000 embedded WiFi device to which it shall connect to. This technology is called the SmartConfig. It basically uses another host (could be smart phones or PCs) to send out some packets to the air which are neglected by any other devices on the network (since the packets look meaningless to the other device,will show it later), but can be interpreted by the CC3000. In this guide, I will show how a step-by-step guide on how to work with SmartConfig technology using the Basic WiFi Host from my previous post and also the SmartConfig Java Applet from TI.
I had the chance to play a bit with the CC3000 Boosterpack which can be used together with the MSP-EXP430G2 Launchpad, and it seems like a very interesting device. It enables WiFi/Internet connection for microcontrollers with small memory size. The CC3000 works such as network processor running a TCP/IP stack which basically does the whole stuffs related to the WiFi/Internet connection, and users need only to implement the application on the host microcontroller. A very nice thing from the software point of view which I found also is that the host source code uses similar API to the BSD socket which is basically the standard API for socket programming .
One of the basic example provided for this kit is called the Basic WiFi example, where basically the MSP-EXP430G2 Launchpad kit is connected via USB to a PC and receives command to execute some basic functionalities such as connecting to a WiFi Access Point, opening a UDP socket, sending and receiving data via the UDP socket, etc. It is basically a nice example to get started working with the platform, however I find it a bit hard to test the example since you need to work with hyperterminal and type in the command code manually. Therefore I decided to write a python based script tool running on the PC which can be used as a host for the CC3000 Basic WiFi example, and it can be found here.
So finally, I made it to make my first post about wireless communication. I have been playing with TI’s SimpliciTI protocol stack for a while now, and I have seen a lot of cases where people have a common issue when people trying to use the stack with their own custom hardware. There is a small guide on TI wiki on how to debug the RF link which can be found at the following link, however I found out an additional simple test mechanism which can help people deploying the stack on their custom hardware.
DISCLAIMER: before we start, just want to give a disclaimer that I am basically more a software guy than hardware guy (in fact I almost know zero about antenna tuning on RF hardware), so I am basically writing this small guide from the eye of a programmer
Referring to the MSP430 microcontroller device datasheet, the current consumption in active mode (CPU on) is usually specified around 10-40% lower if the code is executed from SRAM than from flash memory. For example:
- The MSP430F22x4 datasheet specifies the current consumption in active mode (CPU = 1MHz, Vcc = 3.3V) to be 340 uA when running code from SRAM and 390 uA when running from Flash.
- The MSP430F543xA datasheet specifies current consumption in active mode (CPU= 1MHz, PMMCOREVx=0, Vcc = 3.0V) to be 0.17 mA when running code from SRAM and 0.29 mA when running from flash.
Therefore in an application which has very limited power source and has small routines which are executed quite often, it is useful to execute the routine from SRAM instead of flash memory to reduce the current consumption. Onwards let’s call such function executed from RAM/SRAM during run-time as “RAM function”. The basic principle is quite simple: the code needs of course to be first stored in a non-volatile memory (e.g. flash memory), however these code will then be copied into RAM during initialization to enable executing it from RAM during run-time.
The following guide shows the implementation of code example for implementing RAM function in C programming language for MSP430 microcontroller device on the IAR Embedded Workbench (IAR EWB) compiler and Code Composer Studio (CCSTUDIO), inspired by the flash write code example of MSP430F543x. The example uses the MSP430G2553 on MSP-EXP430G2 Launchpad development board as target device. The MSP430G2553 microcontroller basically has 16 KB Flash (address range 0xC000 – 0xFFFF) and 512 bytes SRAM (address range 0x200 – 0x3FF) on-chip. Although practically it is not really suitable to use the MSP430G2553 for implementing RAM functions due the small SRAM memory size, the example codes basically tries to give a proof of concept on how RAM functions which can even implement ISR (In terrupt Service Routine).