CC2500 rate problem

春暖花开i

Does the delay after each CC2500 transmission have anything to do with the number of bytes sent? I found that sending two bytes only requires a delay of a few milliseconds, but sending 60 bytes requires a delay of more than 30 milliseconds so that the data will not get stuck (the receiving time in the figure below is the delay after the cyclic transmission. If there is no delay, it will get stuck, and the reception can only be received a few times). What's going on? The figure below shows the transmission rate I measured. It feels so low, only 1K per second. Isn't it 250Kbps? My program is a cyclic transmission, a cyclic reception and then sending back to the serial port. There is no other time-consuming operation. From the number of receptions calculated by the serial port, how should I increase the transmission rate? Please answer.

chunyang

As far as CC2500 is concerned, there is no delay at all. It is just that the program processing time on the receiving side may be related to the amount of data. The reason why I say "may" is determined by your receiving side programming. If the data processing speed on the receiving side is sufficient and the programming is reasonable, there is no need for delay in theory, that is, the sending side can continuously send data of any length. Your test results actually test the software, and obviously do not give full play to the performance of the hardware.

chunyang

Delay is only required under half-duplex conditions, because the switching between sending and receiving takes time. This theoretical limit is determined by the hardware, but in fact, an appropriate margin must be reserved to ensure that the error caused by the clock asynchrony between the sender and the receiver does not affect the communication, but this delay has nothing to do with the amount of data.

Jacktang

cc2500 provides an spi interface to communicate with an external mcu. cc2500 acts as an spi slave.

First check whether the hardware has any problems and determine whether the transmission is normal.

It is recommended to refer to the demo on the TI official website.

tagetage

Does the delay after each transmission of CC2500 have anything to do with the number of bytes sent? --- In theory, yes. In practice, the difference is not too big, at the microsecond level.

I found that sending two bytes only requires a delay of a few milliseconds, but sending 60 bytes requires a delay of more than 30 milliseconds so that the data will not get stuck - your program is not written well.

tagetage

The computer serial port needs a very high speed to be measured, preferably 1M. What is your serial port speed? Don't tell me 9600.

春暖花开i

chunyang posted on 2021-7-26 17:23 Delay is only required in half-duplex conditions, because it takes time to switch between sending and receiving. This theoretical limit is determined by the hardware, but in fact, additional time must be reserved...

I use SmartRF host computer to receive and send without delay. It should be that my receiving function is wrong. I use the receiving function in TI program. When the receiving interrupt occurs in the program, a flag is set. There is no other operation in the interrupt function. How should the receiving end handle it normally?

春暖花开i

tagetage posted on 2021-7-26 21:49 Is the delay after each transmission of CC2500 related to the number of bytes sent? --- In theory, yes, but in practice, the difference is not too much, it is at the microsecond level. ...

Yes, the transmission is normal. It should be that my receiving end processes the data incorrectly. The serial port baud rate is 115200, and the receiving end is the function of the routine. Will it be related to the rate at which SPI reads the tx buffer?

tagetage

I use SmartRF host computer to receive and send, so there is no need for delay---that's right.

The serial port baud rate is 115200 --- the speed is also OK.

I used the receiving function in TI history. When the receiving interrupt occurs in the program, a flag is set, and there is no other operation in the interrupt function. This is how it should be written in the interrupt. You will not do data judgment, processing, etc. in the interrupt. Data judgment and processing should be done in the main function.

Does it have anything to do with the rate at which SPI reads the tx buffer? It doesn't matter much.

春暖花开i

tagetage posted on 2021-7-27 09:57 I use SmartRF host computer to receive and send, so there is no need for delay---that's right. The serial port baud rate is 115200---the speed is also OK. I use...

It is the receiving function. The larger the number of bytes, the longer it takes. I don't know how to fix it. The function prototype is as follows:

char RFReceivePacket(char *rxBuffer, char *length)
{
char status[2];
char pktLen;
if ((TI_CC_SPIReadStatus(TI_CCxxx0_RXBYTES) & TI_CCxxx0_NUM_RXBYTES))
{
pktLen = TI_CC_SPIReadReg(TI_CCxxx0_RXFIFO); // Read packet length
if (pktLen <= *length) // Packet length is less than buffer length
{
TI_CC_SPIReadBurstReg(TI_CCxxx0_RXFIFO, rxBuffer, pktLen); // Pop data
*length = pktLen; // Return length
TI_CC_SPIReadBurstReg(TI_CCxxx0_RXFIFO, status, 2);
// Read status byte
// TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
return (char)(status[TI_CCxxx0_LQI_RX]&TI_CCxxx0_CRC_OK);
} // Return CRC check bit
else // Length exceeds buffer
{
*length = pktLen; // Return length
TI_CC_SPIStrobe(TI_CCxxx0_SFRX); // Clear RXFIFO
return 0; // Error message
}
}
else
{
return 0; // Error message
}
}

tagetage

I don't know how to fix the program you posted. I will check it step by step and find the one that takes up the most time and deal with it.

Also check the SPI speed and related functions to rule this out first. Is it hard SPI or software SPI?

春暖花开i

tagetage posted on 2021-7-27 10:55 I don't know how to fix the program you posted. Just check it bit by bit and find the program that takes up the most time and deal with it. Also check SP first ...

It is hardware SPI. The SPI read and write rates are normal. It is the pop-up of the buffered data in the receiving area that takes the most time.

tagetage

春暖花开i Published on 2021-7-27 11:27 It is hardware SPI. The SPI read and write rates are normal. It is the pop-up receiving area buffer data that takes the most time

Is this it? ? ? ? ----TI_CC_SPIReadBurstReg(TI_CCxxx0_RXFIFO, rxBuffer, pktLen); // Pop up data

春暖花开i

tagetage posted on 2021-7-27 13:18 Is this it? ? ? ? ----TI_CC_SPIReadBurstReg(TI_CCxxx0_RXFIFO, rxBuffer, pktLen); // Pop-up data

Here is my SPI problem. I have fixed it. Then I put the serial port return function in the receiving function. If it is 60 bytes, the 115200 baud rate takes 5ms, and the speed is much lower. So it seems something is wrong. Is the serial port speed too low?

春暖花开i

春暖花开i Published on 2021-7-27 15:26 Here is my SPI problem that has been corrected, and then I put the serial port return function in the receiving function. For 60 bytes, the 115200 baud rate takes 5ms...

115200 shouldn't be this low, I haven't figured it out yet

chunyang

春暖花开i Published on 2021-7-27 09:33 I use SmartRF host computer to receive and send without delay. It should be that my receiving function is wrong. I use the receiving function in TI history, the program...

Then you should analyze the program carefully. When using someone else's program, you must consider how to effectively connect it with your program.