February 1,
2009
Last week I received a batch
of CC2500 radio modules. ![]()
But for now, I have written a rudimentary
sniffer for my board. Here is the output on a hyper-terminal link: size:17
DEST:03
8E
75
84
SRC:FA A9 27 AC PORT:0x03 This is the EZ boards doing a join and a
couple of temperature and battery voltage packets at the end. The
packets move so fast I got an overrun in the third one, more
sophisticate software would buffer packets, but this is good enough for
me right now, I can see it working. It may be that the TI Sniffer uses
raw binary data and would make a sniffer hack pretty simple. But for
this, I assemble the ASCII string on the MSP430 so I can just send it
to a dumb terminal app. Here is the code, a quick and dirty hack. You would do what ever you have to to ship
it off to your UART. Just past the test for an echo in
dispachFrame(...), mwk_frame.c, put in: #ifdef
USER_SNIFFER And away you go, a poor man's packet
sniffer.
As I actually build my own network I'll add to this page. For now, I'm
pleased with SimpliciTI, it is easy to use. I'd say forget the LEDs and
Buttons stuff. The only question I have standing is just how compact
the code really is. With asserts on and no optimization, I'm producing
> 20k of code. It is hard to believe this will really trim down to
the advertised 8K. My hardware for this project:
February 3, 2009 Yesterday I got a network together. That was
a great moment for me. It took longer than it should have because I
assumed I could start with the disk sent with the EZ430-RF2500. If you
just want to play with the App layer and leave the radio as it is, use
the project on the disk. If you plan on writing your own network and
need to build SimpliciTI, put that disk on the shelf and leave it
there. Go to the TI site and download the latest slac139 package. That
telephone box has an FT232RL in it for the RS232 part of projects. The
TI Demo monitor works from a COM port, so:
The MSP430F149 board above is the 'Access
Point' (AP) and I've put my own 'End Device'(ED) code on the two EZ
boards. There is no AP temperature as I didn't bother, this was about
the radio project. SimpliciTI will work just about out of the box with MSPGCC. From the slac139, take the folders from: eZ430-RF2500 Wireless Sensor
Monitor\CCS_Source\Components And put them in your favorite source folder.
I put them in a sub folder called simti_source. Don't try to reorganize
it, don't change anything in these folders but for one special header.
In the following link you will find the code to add to
bsp_msp430_defs.h that supports MSPGCC. It is ready to use from there. If you have the urge to 'fix' something in
these files, don't, it is not worth it, the code works. SimpliciTI
Brief
Tutorial (PDF) (I'll keep a copy in case this link ever
expires) I use bat files to make. I'm use to it, but
the same rules apply if you make from Eclipse. Each radio project will
have a unique object so you can't make a SimpliciTI lib for general
use. I have two bat makes for a project, one for the radio and one for
the app. This way I don't have to make the radio object over and over
while working on the application. Here is my radio bat. The order of the include paths is important
in that you want to start with your workspace folder first. -I../This is because you will copy project specific headers and source from the SimpliciTI folder into your workspace folder and modify them there. You do not have to edit anything in the SimpliciTI source. The following is what I did for the MSP430F149.These files are copied into the workspace folder. bsp_config.h#define BSP_NO_LEDS #define BSP_NO_BUTTONS #define BSP_CONFIG_CLOCK_MHZ 2 That's it, you don't need the
rest of that stuff. I don't know what LEDs and buttons are doing here,
this is a radio library, shut them off.
bsp_board.cBSP_EarlyInit(...) is not used, you can delete it. Otherwise, I used the software timer (SW_TIMER defined) to get going so all the code needed here is: #include
"bsp.h"
bsp_board_defs.h#include "bsp_config.h" #include <HEUtils.h> void BSP_Delay( uint16_t usec ) { usec/= ( 20 / BSP_CONFIG_CLOCK_MHZ ); brief_pause( usec ); } I just kept the whole thing and changed this: #define BSP_BOARD_C "bsp_board.c" #define BSP_INIT_BOARD() nop( ) bsp_driver_defs.h By using bsp_config.h for the driver include, you don't need the bsp_drivers.c #define
BSP_DRIVERS_C
"bsp_config.h"
#define BSP_INIT_DRIVERS() nop( ) bsp_external/mrfi_board_defs.h bsp_external/mrfi_board.c In a folder called bsp_external in your workspace, two more files These configure the SPI interface for the flavor of MSP430 you are using. Also, if you are handling interrupts for other pins on the port you put the GDO0 and GDO2 on, the handler is in mrfi_board.c I had to change quite a bit in mrfi_board_defs.h, I won't post that here. But if you are going to use a 1xxx device, this include may be a better staring point than the one TI ships. mrfi_board_defs.h But this should do it for you. From there look at the AP and ED examples for talking on the radio network and go through some SimpliciTI docs. One other thing, the global defines. I would put those in a header but I started the why they did it. Look over them carefully! Like, the obvious can be so hard to see. At one point I had END_DEVICE defined while building an AP. I was looking for a subtle problem and just didn't see it for a while. That was an 'I feel dumb' moment. There is one file in the SimpliciTI files that you may want to modify, it is mrfi\radios\family1\mrfi_spi.h. Here you can change the likes of frequency, bandwidth, etc., for the radio. TI has a parameter tool called SmartRF Studio that will generate the defines. Thanks, Dan. Copyright © 1996 - 2010, http://www.lakeweb.net/MSP430/SimpliciTI.html |