larsie 121 Posted April 5, 2012 Share Posted April 5, 2012 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. 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) Quote Link to post Share on other sites
cheverecamachidoche 13 Posted April 6, 2012 Share Posted April 6, 2012 Ok It was my first time with IAR, I checked the bug fix mentioned in the posts above, I uploaded the files as you told me and all went well, now I dont know which main file should to upload to one micro and which main file to the another micro, please can you explain me Quote Link to post Share on other sites
larsie 121 Posted April 6, 2012 Share Posted April 6, 2012 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. Quote Link to post Share on other sites
cheverecamachidoche 13 Posted April 6, 2012 Share Posted April 6, 2012 Thank you larsie, now is working Quote Link to post Share on other sites
Tomeindhoven2 0 Posted April 14, 2012 Share Posted April 14, 2012 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. Quote Link to post Share on other sites
larsie 121 Posted April 14, 2012 Share Posted April 14, 2012 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. Tomeindhoven2 1 Quote Link to post Share on other sites
Tomeindhoven2 0 Posted April 24, 2012 Share Posted April 24, 2012 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! Quote Link to post Share on other sites
larsie 121 Posted April 24, 2012 Share Posted April 24, 2012 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 Tomeindhoven2 1 Quote Link to post Share on other sites
CorB 64 Posted April 24, 2012 Share Posted April 24, 2012 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 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 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 speedsthatbeat 1 Quote Link to post Share on other sites
speedsthatbeat 2 Posted April 24, 2012 Share Posted April 24, 2012 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 Quote Link to post Share on other sites
CorB 64 Posted April 24, 2012 Share Posted April 24, 2012 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 Quote Link to post Share on other sites
jaeger92 2 Posted July 5, 2012 Share Posted July 5, 2012 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? Quote Link to post Share on other sites
CorB 64 Posted July 6, 2012 Share Posted July 6, 2012 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 jaeger92 1 Quote Link to post Share on other sites
jaeger92 2 Posted July 6, 2012 Share Posted July 6, 2012 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 ) Quote Link to post Share on other sites
CorB 64 Posted July 6, 2012 Share Posted July 6, 2012 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 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.