Jump to content
43oh

Anaren TI CC110L RF AIR Booster Pack


Recommended Posts

Hi. The code is for IAR. There are project files, but you may need to create a new project to make it work. You should then select option on some of the files and exclude from build. You should only have one main file (file with a main-function in it). If not it'll fail.

 

The image shows an example configuration which works for me at least. The folders on the picture are just folders that are made inside IAR that don't represent the real folders. If it doesn't work for you, post the error message and I can see what might be the problem.

 

larsrfiar.png

 

There are MSPGCC compatible files here: https://github.com/mobilars/LarsRF-mspgcc.

 

(Check out the bug fix mentioned in the posts above that I haven't checked in yet to either of those repositories)

Link to post
Share on other sites
  • Replies 128
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Here's an updated CCS project for the Anaren Air Booster Pack. It's quite obvious they're not familiar with CCS. Included directories are very vague and leave header includes looking like "../../../HA

I was similarly frustrated with Anaren but especially TI for a short while, until I realized that TI actually have some simple example RF code out there in nice BSD licenses. That's the code that http

Hi all,   Anaren has released an update of their firmware and its now also available for CCs   http://www.anaren.com/content/File/AIR/ ... upport.cfm   cheers   Cor   EDIT: just checked the

Posted Images

The demo uses the same main file on both. On one, press the button. But in reality you want to make your own main file, and maybe some more structure in the message packet than just an array. I think main acktest is the best example, though the ack is not perfect. Maybe mentioned bugfix fixes it. has very long delay and ack should really be possible to send almost immediately.

Link to post
Share on other sites
  • 2 weeks later...

Hi all,

 

I am using this Anaren boosterpack + MSP430G2553 to make an ADC-measurement with a certain frequency and send this to the other side. Now I started with the code of Larsie (great thanks for that, much easier to understand than the Anaren!!) and I managed to establish the connection between the two boards and I get the blinking led.

 

Notice I use the LED0 on P1.0 and it toggles when I push the button on the other board. Thats interesting since Anaren tells in their manual:

To use the GDO2 signal as an interrupt/status flag from the radio, the microcontroller pin must be set as an input. The LED will no longer be under processor control but is still connected to the GDO2 pin and therefore will turn on when GDO2 is driven high by the radio.

So does someone know why it actually is working and toggles my LED0?

 

Now the main question. I want to extend Larsie's code with a Timer which will trigger the ADC with a certain frequency. I have tried to use Timer0 and Timer1 both but I can't even manage to get a blinking LED6 at the sender side. I have tested the Timer0 + LED6 in a test application which does nothing more than counting and triggering the LED6 (so without Larsie's code), this works. Can anyone tell me why Larsie's code will not work in combination with the Timers? This is the main.c I use, all other headers/source files are Larsie's standards.

 

#include "include.h"

extern char paTable[];
extern char paTableLen;

char txBuffer[12];
char rxBuffer[12];
unsigned int i = 0;

void main (void)
{
 WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT

 //set timer, 12.5Hz blinking
 TA1CCTL0 = CCIE;                             // CCR0 interrupt enabled
 TA1CTL = TASSEL_2 + MC_1 + ID_3;           // SMCLK/8, upmode
 TA1CCR0 =  40000;                            // 125 Hz

 // 5ms delay to compensate for time to startup between MSP430 and CC1100/2500
 __delay_cycles(5000);

 TI_CC_SPISetup();                         // Initialize SPI port

 TI_CC_PowerupResetCCxxxx();               // Reset CCxxxx
 writeRFSettings();                        // Write RF settings to config reg
 TI_CC_SPIWriteBurstReg(TI_CCxxx0_PATABLE, paTable, paTableLen);//Write PATABLE

 // Configure ports -- switch inputs, LEDs, GDO0 to RX packet info from CCxxxx
 TI_CC_SW_PxREN = TI_CC_SW1;               // Enable Pull up resistor
 TI_CC_SW_PxOUT = TI_CC_SW1;               // Enable pull up resistor
 TI_CC_SW_PxIES = TI_CC_SW1;               // Int on falling edge
 TI_CC_SW_PxIFG &= ~(TI_CC_SW1);           // Clr flags
 TI_CC_SW_PxIE = TI_CC_SW1;                // Activate interrupt enables p1.3

 TI_CC_LED_PxDIR |= TI_CC_LED1 + BIT6;			// LED Direction to Outputs
 TI_CC_LED_PxOUT &= ~TI_CC_LED1 + BIT6;		// Outputs = 0

 TI_CC_GDO0_PxIES |= TI_CC_GDO0_PIN;       // Int on falling edge (end of pkt)
 TI_CC_GDO0_PxIFG &= ~TI_CC_GDO0_PIN;      // Clear flag
 TI_CC_GDO0_PxIE |= TI_CC_GDO0_PIN;        // Enable int on end of packet

 TI_CC_SPIStrobe(TI_CCxxx0_SRX);           // Initialize CCxxxx in RX mode.
                                           // When a pkt is received, it will
                                           // signal on GDO0 and wake CPU

 __bis_SR_register(CPUOFF + GIE);       // CPUOFF, enable interrupts
}

// Timer A0 interrupt service routine
#pragma vector=TIMER1_A0_VECTOR
__interrupt void Timer1_A0_ISR (void)
{
 P1OUT ^= BIT6;                            // Toggle P1.6
}

// The ISR assumes the interrupt came from a pressed button
#pragma vector=PORT1_VECTOR
__interrupt void Port1_ISR (void)
{
 // If Switch was pressed
 if(TI_CC_SW_PxIFG & TI_CC_SW1)
 {
   // Build packet
   txBuffer[0] = 11;                        // Packet length
   txBuffer[1] = 0x01;                     // Packet address
   txBuffer[2] = BIT0;
   //txBuffer[2] = TI_CC_LED1;
   txBuffer[3] = 0x32;
   txBuffer[4] = 0x33;
   txBuffer[5] = 0x34;
   txBuffer[6] = 0x35;
   txBuffer[7] = 0x36;
   txBuffer[8] = 0x37;
   txBuffer[9] = 0x38;
   txBuffer[10] = 0x39;
   txBuffer[11] = 0x40;
   RFSendPacket(txBuffer, 12);              // Send value over RF
   __delay_cycles(5000);                   // Switch debounce
 }
 TI_CC_SW_PxIFG &= ~(TI_CC_SW1);           // Clr flag that caused int
}

// The ISR assumes the interrupt came from GDO0. GDO0 fires indicating that
// CCxxxx received a packet
#pragma vector=PORT2_VECTOR
__interrupt void Port2_ISR(void)
{
   // if GDO fired
 if(TI_CC_GDO0_PxIFG & TI_CC_GDO0_PIN)
 {
   char len=11;                            // Len of pkt to be RXed (only addr
                                           // plus data; size byte not incl b/c
                                           // stripped away within RX function)
   if (RFReceivePacket(rxBuffer,&len))     // Fetch packet from CCxxxx
   TI_CC_LED_PxOUT ^= rxBuffer[1];         // Toggle LEDs according to pkt data
 }

 TI_CC_GDO0_PxIFG &= ~TI_CC_GDO0_PIN;      // After pkt RX, this flag is set.
}

 

For your information, I'm a newbie if it comes to MSP430 and Code Composer so excuse me if this is a silly question.

Link to post
Share on other sites

Hi. Sorry if I read this too quickly and didn't catch the right question, but I wonder:

 

... if you are setting P1.0 as an output and driving it high, I think it will drive the P1.0-LED to light, but you might be fighting for the voltage with the RF-module. So it might be dependent on how your RF-modules GDO2 is set up, and it's conceivable that you may burn the RF-module???

 

... P1.6 is probably used by the MISO-signal, so using this to drive a LED output will probably not work. You'd have to make sure the P1.6 wasn't being used as MISO (done in TI_CC_SPISetup() ), but then your radio won't work properly.

 

So, you may need to use other pins as LED-pins. Some of the free ones. I think you can reuse the LEDs for another output, if you instead of the header connect another MCU output pin to the lower pin on the header (closest to the LED). But don't shoot me if it doesn't work, since I*ve never tried.

Link to post
Share on other sites
  • 2 weeks later...

Thanks for your help! I made a lot of progress on it. I'm now doing an ADC measurement at the transmitter side at a certain frequency and I can send this value to the receiver side. Only problem is it will not receive the right value... For instance if I do an ADC measurement and I get 585.

 

So txBuffer[2]=585. When I sent this value to the other side and I try to debug I can only see a . (dot) in rxBuffer[1] after the data is received. When I do txBuffer[2]=BIT0, I can light up the LED0 on the receiver end by P1OUT ^= rxBuffer[1]. So that works. Can anyone help me whats wrong here? Maybe because txBuffer[] is from the type char and not int? Why is it txBuffer[] char anyway?

 

Thanks again!

Link to post
Share on other sites

Each of the places in buffer are chars, so they're limited to 256. So you need to split your int into two chars and put one in txBuffer[2] and one in txBuffer[3]. CorB has used a struct to manage his packet structure, which is more flexible than just a char buffer.

 

You might be able to do something like:

 

txBuffer[2] = (char) adc_value

txBuffer[3] = (char) (adc_value >> 8)

 

But I can never remember which way to shift :D

Link to post
Share on other sites
Each of the places in buffer are chars, so they're limited to 256. So you need to split your int into two chars and put one in txBuffer[2] and one in txBuffer[3]. CorB has used a struct to manage his packet structure, which is more flexible than just a char buffer.

 

You might be able to do something like:

 

txBuffer[2] = (char) adc_value

txBuffer[3] = (char) (adc_value >> 8)

 

But I can never remember which way to shift :D

 

Hi,

 

Here's a snippet of the code I am using to send packages around:

 

typedef volatile struct StatusStruct{

enum TxACKMessageType { //!< Flags to ACK transfer

REQUEST_NO_ACK = 0,

REQUEST_ACK = 1

} TxACKMessageType;

 

enum RxACKMessageType { //!< Flags to ACK transfer

RECEIVED_NO_ACK = 0,

RECEIVED_ACK = 1

} RxACKMessageType;

 

char channel;

char power;

char RSSI;

unsigned int msgNodeId;

} StatusStruct;

 

 

typedef struct PayloadFrame {

 

char addr; // payloads need to start with char addr as the receiver can check this !

char msg; // messagetype 0x00 - 0xFF options

char msgdata0; // var1 that belongs to the message

char msgdata1; // var2 that belongs to the message

StatusStruct Status;

 

// USER DESIGNED PAYLOAD SECTION

unsigned int data1;

char DataUnit;

 

} PayloadFrame;

 

The advantage of using a structure is

a) flexibility

B) easy of use all the transforms are internal

 

Ive just this week tested the same setup using a TI Chronos Watch and can now also communicate between watch and the network of Anaren AIR boosterpacks.

 

regards

 

Cor

Link to post
Share on other sites
Cor,

I am trying to do exactly the same thing. Is there any chance you can share your code for both the chronos and the anaren boosterpacks? That would be of enormous help.

 

thanks

 

-Andrea

Hi Andrea,

 

I got the idea how to implement the code for the Chronos from this website:

http://blog.chschmid.com/?page_id=193

 

Using the cSLight.c file in Christian Schmid's project its very simple to setup a setting comparable to the Anaren AIR boosterpacks for the CC430 (figuring out the registers you best use SmartRF 7).

 

If you need more details just send me a private mail so I can share more code with you.

 

regards

Cor

Link to post
Share on other sites
  • 2 months later...

I know the last reply is from April, however I'm doing a project involving these booster packs. The question is: how many free pins I have after connecting it into the Launchpad? I want to connect three I2C sensors and to use other three general pins. Is that possible?

Link to post
Share on other sites
I know the last reply is from April, however I'm doing a project involving these booster packs. The question is: how many free pins I have after connecting it into the Launchpad? I want to connect three I2C sensors and to use other three general pins. Is that possible?

 

Hi,

 

You have many free pins, on a G2553 P1.4 - P1.7 are used for SPI communcation with the boosterpack and pin 2.6/2.7 are also in use by the boosterpack. So you have P1.0-P1.3 and P2.0-2.5 to be used for your demands.

 

regards

CorB

Link to post
Share on other sites

Hi,

 

You have many free pins, on a G2553 P1.4 - P1.7 are used for SPI communcation with the boosterpack and pin 2.6/2.7 are also in use by the boosterpack. So you have P1.0-P1.3 and P2.0-2.5 to be used for your demands.

 

regards

CorB

 

Right. One thing I could't really notice in the boosterpack are the male headers in the top side of the boosterpack. The pins used by the boosterpack also have male headers so you could attach another boosterpack on it? Or only the unused pins actually have male headers too? (my boosterpacks will arrive by mid-July, by the way :) )

Link to post
Share on other sites

 

Right. One thing I could't really notice in the boosterpack are the male headers in the top side of the boosterpack. The pins used by the boosterpack also have male headers so you could attach another boosterpack on it? Or only the unused pins actually have male headers too? (my boosterpacks will arrive by mid-July, by the way :) )

 

Ive got a sandwich setup with a lauchpad, on top of that an AIR boosterpack and on top of that an SPI LCD (Larsie). All the pins are available at all the boards, since the LCD I use and the AIR boosterpack both use SPI the LCD needs another pin for th CS (chip_select) function but thats all possible.

 

Cor

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...