Hello All,

In the hope that someone at TI will read this, we don't understand why the following code fails to work as expected. I say that I hope that TI will see this because
it's their code originally.

The two while() loops in the following routine fail to work for us. The first one waits for the GDOo line to go high and the second for it to go low.

What actually happens is that we stay in the routine permanently. This code came "out of the can" and I would think that when it was written it was working.

To get by for now we've commented out the two loops and we enter a wait loop to wait out long enough until the transmission is over. This has other nasty repercussions though and we'd like to get the two while loops working.

Has anyone experienced this before and could provide some insight ?

Thank you.

Here is the code.

//-----------------------------------------------------------------------------
// void RFSendPacket(char *txBuffer, char size)
//
// DESCRIPTION:
// This function transmits a packet with length up to 63 bytes. To use this
// function, GD00 must be configured to be asserted when sync word is sent and
// de-asserted at the end of the packet, which is accomplished by setting the
// IOCFG0 register to 0x06, per the CCxxxx datasheet. GDO0 goes high at
// packet start and returns low when complete. The function polls GDO0 to
// ensure packet completion before returning.
//
// ARGUMENTS:
// char *txBuffer
// Pointer to a buffer containing the data to be transmitted
//
// char size // The size of the txBuffer
//-----------------------------------------------------------------------------
void RFSendPacket(char *txBuffer, char size)
{
TI_CC_SPIWriteBurstReg(TI_CCxxx0_TXFIFO, txBuffer, size); // Write TX data

TI_CC_SPIStrobe(TI_CCxxx0_STX); // Change state to TX, initiating data transfer

while (!(TI_CC_GDO0_PxIN&TI_CC_GDO0_PIN)); // Wait GDO0 to go hi -> sync TX'ed <<<---------------------- PROBLEM

while (TI_CC_GDO0_PxIN&TI_CC_GDO0_PIN); // Wait GDO0 to clear -> end of pkt <<<----------------------- PROBLEM

}

Oliver
Mettrix

[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Well, don't get your hopes up! TI's sample code for the CC1100 has
more than one bug as you'll find out if you search this forum. I tryed
to use it, but after battling with it I programmed my own code from
scratch. Sure, it took me about 3 months to come up with a good code,
since the CC110x documentation is... well... one of TI's classic
HowToWriteAComplicatedDatasheet. Their LeaveSomeSpecsOut technique can
also be found on this datasheet.
Someone mentioned on this forum the CC1100 Datasheet to be Chipcons
writing, but it has the TI logo and sure as hell the TI way of writing
datasheets. I've said it before and I've said it again.

About the sample code itself, I remember it got stuck in more than one
while loop. I've never liked their use of the GDO0 pin, I prefer it
configured to 0x07 (which menans you have to change the code
accordingly). The CC1100 has a lot of usefull features to easy RF
communication, but they don't use it in their sample code. You'll
probably have alot of trouble trying to debug the code, when in fact
most of the the problems will be noise recived has if it was a packet,
making the CC1100 think it recived a packet with lenght over 63 bytes.
If you configure the chip to use CRC and maximum packet lenght to 63
you'll have far less headaches.

It's a mystery to me why TI would put such a problematic code as a
sample code for their device. I think the only part of their code I
used was the register definitions and the SPI transfer functions.

Best Regards,
Michael K.

--- In m...@yahoogroups.com, "oliver at mettrix" wrote:
>
> Hello All,
>
> In the hope that someone at TI will read this, we don't understand
why the following code fails to work as expected. I say that I hope
that TI will see this because
> it's their code originally.
>
> The two while() loops in the following routine fail to work for us.
The first one waits for the GDOo line to go high and the second for it
to go low.
>
> What actually happens is that we stay in the routine permanently.
This code came "out of the can" and I would think that when it was
written it was working.
>
> To get by for now we've commented out the two loops and we enter a
wait loop to wait out long enough until the transmission is over. This
has other nasty repercussions though and we'd like to get the two
while loops working.
>
> Has anyone experienced this before and could provide some insight ?
>
> Thank you.
>
> Here is the code.
>
//-----------------------------------------------------------------------------
> // void RFSendPacket(char *txBuffer, char size)
> //
> // DESCRIPTION:
> // This function transmits a packet with length up to 63 bytes. To
use this
> // function, GD00 must be configured to be asserted when sync word
is sent and
> // de-asserted at the end of the packet, which is accomplished by
setting the
> // IOCFG0 register to 0x06, per the CCxxxx datasheet. GDO0 goes high at
> // packet start and returns low when complete. The function polls
GDO0 to
> // ensure packet completion before returning.
> //
> // ARGUMENTS:
> // char *txBuffer
> // Pointer to a buffer containing the data to be transmitted
> //
> // char size // The size of the txBuffer
>
//-----------------------------------------------------------------------------
> void RFSendPacket(char *txBuffer, char size)
> {
> TI_CC_SPIWriteBurstReg(TI_CCxxx0_TXFIFO, txBuffer, size); // Write
TX data
>
> TI_CC_SPIStrobe(TI_CCxxx0_STX); // Change state to TX, initiating
data transfer
>
> while (!(TI_CC_GDO0_PxIN&TI_CC_GDO0_PIN)); // Wait GDO0 to go hi ->
sync TX'ed <<<---------------------- PROBLEM
>
> while (TI_CC_GDO0_PxIN&TI_CC_GDO0_PIN); // Wait GDO0 to clear ->
end of pkt <<<----------------------- PROBLEM
>
> }
> Oliver
> Mettrix
>
> [Non-text portions of this message have been removed]
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> Well, don't get your hopes up! TI's sample code for the CC1100 has
> more than one bug as you'll find out if you search this forum. I
tryed
> to use it, but after battling with it I programmed my own code from
> scratch. Sure, it took me about 3 months to come up with a good code

Three months isn't unusual to work through these problems. From
other feedback we've seen it can reasonably take as many as six
months, depending on how much time you invest before you get
frustrated and decide to start from scratch.

To help with this problem we released our MRF1611CC1100 RF modules:

http://www.softbaugh.com/ProductPage.cfm?strPartNo=MRF1611CC1100

and the companion book "MSP430 RF Applications", available on amazon:

http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%
2Fwww.amazon.com%2FMSP430-RF-Applications-MRF1611CC1100-Reference%
2Fdp%2F0975475908%3Fie%3DUTF8%26s%3Dbooks%26qid%3D1214398172%26sr%3D8-
4&tag=softcom-20&linkCode=ur2&camp=1789&creative=9325

Our intention was to help you get a realistic star network up
quickly. Our demo code lets you play around with packets and all the
options available on the CC1100 from a terminal monitor, or
disconnect and walk around with up to five nodes in a handheld
configuration.

And at $3000 for the source code, purchased only after you get to
work with the hardware to make sure it does what you want, it is a
lot cheaper than three to six months of brain damage. For a hobbyist
or student that amount seems high, but for a commercial project with
a deadline it is a great way to buy extra schedule.

Tom

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Does anyone else find this blatant self promotion a bit wearing?
Especially after the recent strong crititcism of Ti, and thinly veiled
suggestion that people stay away from certain MSp devices? No other
vendor has self promoted to this extent, and it has gone well beyond the
stage of helpful hints and suggestions.

For the record the Cc1100 is a pain to program, and the long list of
undocumneted or badly documented bugs when it was first released were
difficult to handle, especially when combined with not so great
documentation, however it wasn't that hard to get running, even based on
Ti's crude 'joystick' example code. It took me about 3 weeks to get a
simple 4 module system communicating 18 months ago using a 2131, bit
banged interface and of course assembler. The fact that I didn't
continue with the system was more related to the idiotic demands of the
client that I guarantee the absolute ranges of different system modules
under any circumstance, than it was the Cc1100 itself. For example one
had to work from 10" to 24" precisley, another had to change its range
from 10-24" then from 2' to 15', while another had to work from 2-15"
then 15' to 200'. I doin't care how good the CC1100 is this isn't feasible.

Cheers

Al

Tom Baugh wrote:

>>Well, don't get your hopes up! TI's sample code for the CC1100 has
>>more than one bug as you'll find out if you search this forum. I
>>
>>
>tryed
>
>
>>to use it, but after battling with it I programmed my own code from
>>scratch. Sure, it took me about 3 months to come up with a good code
>>
>>Three months isn't unusual to work through these problems. From
>other feedback we've seen it can reasonably take as many as six
>months, depending on how much time you invest before you get
>frustrated and decide to start from scratch.
>
>To help with this problem we released our MRF1611CC1100 RF modules:
>
>http://www.softbaugh.com/ProductPage.cfm?strPartNo=MRF1611CC1100
>
>and the companion book "MSP430 RF Applications", available on amazon:
>
>http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%
>2Fwww.amazon.com%2FMSP430-RF-Applications-MRF1611CC1100-Reference%
>2Fdp%2F0975475908%3Fie%3DUTF8%26s%3Dbooks%26qid%3D1214398172%26sr%3D8-
>4&tag=softcom-20&linkCode=ur2&camp=1789&creative=9325
>
>Our intention was to help you get a realistic star network up
>quickly. Our demo code lets you play around with packets and all the
>options available on the CC1100 from a terminal monitor, or
>disconnect and walk around with up to five nodes in a handheld
>configuration.
>
>And at $3000 for the source code, purchased only after you get to
>work with the hardware to make sure it does what you want, it is a
>lot cheaper than three to six months of brain damage. For a hobbyist
>or student that amount seems high, but for a commercial project with
>a deadline it is a great way to buy extra schedule.
>
>Tom
>
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, Onestone wrote:
> suggestion that people stay away from certain MSp devices?

Hi Onestone,
Where we can read this suggetsion?
regards
Stefan
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

This was my statement:-

"thinly veiled suggestion that people stay away from certain MSp devices"

if you follow the links in Toms post you will find why I make that
comment. .

Al

stefandk63 wrote:

>--- In m...@yahoogroups.com, Onestone wrote:
>
>
>>suggestion that people stay away from certain MSp devices?
>>
>>Hi Onestone,
>Where we can read this suggetsion?
>regards
>Stefan
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )