| |
 cc1101 - переключение из режима передачи в режим приема и наоборот. |
|
|
|
|
 Aug 9 2013, 16:43
|
Гуру
Группа: Участник
Сообщений: 2 072
Регистрация: 14-01-06
Пользователь №: 13 164
|
Цитата сли пакет не пришел или побился(преамбула не принялась нормально), то вышли из Ping_RF Я из пинга выхожу в любом случае, просто функция пинг возвращает 1 или 0, в зависимости от результата. Как калибровать-то? Там какие-то два вида калибровки описывались. Просто команда TI_CC_SPIStrobe(TI_CCxxx0_SCAL); подойдет?
|
|
|
|
|
|
|
|
Aug 9 2013, 16:55
|
Частый гость
Группа: Участник
Сообщений: 166
Регистрация: 8-09-09
Из: Украина
Пользователь №: 52 244
|
Цитата(zheka @ Aug 9 2013, 19:46)  Чип что, от переключений так частоту уводит сильно? К сожалению я этого не знаю. Просто у меня была ситуация что были проблемы со связью из-за отсутствия периодической калибровки.
|
|
|
|
|
|
|
|
Aug 10 2013, 09:01
|
Гуру
Группа: Участник
Сообщений: 2 072
Регистрация: 14-01-06
Пользователь №: 13 164
|
Продолжаю биться. С переходом в RX после TX все получается. - А вот наоборот - нет. Прежде чем приводить код, опишу алгоритм на пальцах. Ведущий: отправляет посылку в 2 байта (пинг), немедленно переходит в прием. Получая ответ на пинг функция Ping_RF() завершается. Далее следует принудительная пауза в 10 мс и далее по кругу. ТАймаут на ожидание ответа - 100 мсек. Ведомый: в цикле ловит спад на GDO0, после чего переписывает пришедший пакет из FIFO в буфер контроллера. Если пинг корректен (2 байта), то пикает динамиком ( beep() ) отправляет ответ ( Ping_RF_Answer() ). Если все хорошо, то ведомый постоянно трещит динамиком - близко к сотне посылок в секунду, как раз соответствует паузе в цикле в 10 мсек, что говорит о том, что пропусков пакетов нет. Далее есть 3 строки Код TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX); после переписывания данных из FIFO. Стоит закомментировать перевод в IDLE - начинает пикать около 10 раз в секунду, светодиод, который должен загораться по таймауту, начинает моргать. Но и динамик довольно часто пикает - то есть пакеты довольно часто и причем равномерно проходят. Что самое интересное - строб SRX можно убрать, переводится автоматом, но почему-то хочет чтобы после обработки буфера был переовд в IDLE. Вот код ведущего Код
unsigned char Ping_RF()
{
RF_TX_Buffer[0]=2;
RF_TX_Buffer[1]= 0xAA;
RF_TX_Buffer[2]= RF_RX_Buffer[0];
TI_CC_SPIWriteBurstReg(TI_CCxxx0_TXFIFO, RF_TX_Buffer, 3);
// TX_ON;
TI_CC_SPIStrobe(TI_CCxxx0_STX);
rf_ping_timeout_tick=RF_PING_TIMEOUT;
while(rf_ping_timeout_tick>0)
{
if (GDO0_flag==1)
{
TX_OFF;
rf_ping_timeout_tick=0;
GDO0_flag=0;
TI_CC_SPIStrobe(TI_CCxxx0_SFTX);
}
}
// RX_ON;
rf_ping_timeout_tick=RF_PING_TIMEOUT;
while(rf_ping_timeout_tick>0)
{
if (GDO0_flag==1)
{
rf_ping_timeout_tick=0;
GDO0_flag=0;
st=RFReceivePacket(RF_RX_Buffer,&leng);
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
return 1;
}
}
RX_OFF;
LED2_ON;
delay_ms(10);
LED2_OFF;
return 0;
}
............................
while(1)
{
Ping_RF();
delay_ms(10);
} Вот код ведомого: Код void Ping_RF_Answer(unsigned char code)
{
RX_OFF;
RF_TX_Buffer[0]=2;
for (i=1;i<=2;i++) RF_TX_Buffer[i]= code;
TI_CC_SPIWriteBurstReg(TI_CCxxx0_TXFIFO, RF_TX_Buffer, 3);
//TX_ON;
TI_CC_SPIStrobe(TI_CCxxx0_STX);
rf_ping_timeout_tick=RF_PING_TIMEOUT;
while(rf_ping_timeout_tick>0)
{
if (GDO0_flag==1)
{
TX_OFF;
rf_ping_timeout_tick=0;
GDO0_flag=0;
TI_CC_SPIStrobe(TI_CCxxx0_SFTX);
}
}
// RX_ON;
}
........................
while(1)
{
rf_ping_timeout_tick=RF_PING_TIMEOUT;
GDO0_flag=0;
while(rf_ping_timeout_tick>0)
{
if (GDO0_flag==1)
{
GDO0_flag=0;
LINK_PRESENT_flag=1;
rf_ping_timeout_tick=RF_PING_TIMEOUT;
ping_error_count=0;
st=RFReceivePacket(RF_RX_Buffer,&leng);
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
if (leng==2)
{
beep();
delay_ms(10);
Ping_RF_Answer(0x44);
}
}
}
} Где я что делаю не так?
Сообщение отредактировал zheka - Aug 10 2013, 09:05
|
|
|
|
|
|
|
|
Aug 11 2013, 16:04
|
Частый гость
Группа: Участник
Сообщений: 166
Регистрация: 8-09-09
Из: Украина
Пользователь №: 52 244
|
Цитата(zheka @ Aug 10 2013, 12:01) Далее есть 3 строки Код TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX); после переписывания данных из FIFO. Стоит закомментировать перевод в IDLE - начинает пикать около 10 раз в секунду, светодиод, который должен загораться по таймауту, начинает моргать. Но и динамик довольно часто пикает - то есть пакеты довольно часто и причем равномерно проходят. Что самое интересное - строб SRX можно убрать, переводится автоматом, но почему-то хочет чтобы после обработки буфера был переовд в IDLE. Так Вы комментируете только переход в IDLE? Просто тут же есть еще такие нюансы, типа как очищать буфер (SFRX-SFTX) можно только когда устройство либо в IDLE либо в режиме переполнения буфера. А по логике настройки как у Вас настроены переходы после RX и после TX? В IDLE или в RX? Дело в том что когда Вы переходите в IDLE вручную, то Вы после этого принудительно очищаете приемный буфет после чтения из него. Не может ли получатся что где-то не до конца что-то вычитывается из буфера?
Сообщение отредактировал Pasha_a13 - Aug 11 2013, 16:11
|
|
|
|
|
|
|
|
Sep 19 2013, 05:44
|
Участник
Группа: Участник
Сообщений: 65
Регистрация: 28-11-07
Пользователь №: 32 772
|
У меня возник очередной затык на пути освоения СС1101. Использую MCU STM8L. Еще вчера у меня получалось обмениваться данными между двумя платками: одна передавала, другая все время принимала. Все пакеты проходили успешно. Решил настроить двухсторонний обмен. Т.е. чтобы после получения пакета высылалось подтверждение. После очередной доработки, вообще все перестало работать. SPI, вроде, работает: регистры пишутся и читаются правильно. Одна плата совсем выключена, при этом вторая все время что-то принимает. Даже если предположить, что эфир сильно засорен, некоторые моменты совсем не понятны: 1. RXBYTES все время равен 0x1F. Из RXFIFO читается все время одна и та же последовательность. 2. После команд TI_CC_SPIStrobe(TI_CCxxx0_SIDLE); TI_CC_SPIStrobe(TI_CCxxx0_SFRX); RXBYTES возвращает 0xF. 3. MARCSTATE равен 0x5F, PKTSTATUS - 0x2F - значения этих регистров вызывают подозрение на проблемы в SPI Подскажите, что может быть? CODE CC1101_WriteReg(CCxxx0_IOCFG2, 0x45); //GDO2 Output Pin Configuration
CC1101_WriteReg(CCxxx0_IOCFG0, 0x41); //GDO0 Output Pin Configuration
CC1101_WriteReg(CCxxx0_PKTLEN, 0xFE); //Packet Length
CC1101_WriteReg(CCxxx0_PKTCTRL1,0x0C); //Packet Automation Control
CC1101_WriteReg(CCxxx0_PKTCTRL0,0x05); //Packet Automation Control
CC1101_WriteReg(CCxxx0_CHANNR, 0x15); //Channel Number
CC1101_WriteReg(CCxxx0_FSCTRL1, 0x0C); //Frequency Synthesizer Control
CC1101_WriteReg(CCxxx0_FREQ2, 0x10); //Frequency Control Word, High Byte
CC1101_WriteReg(CCxxx0_FREQ1, 0xB1); //Frequency Control Word, Middle Byte
CC1101_WriteReg(CCxxx0_FREQ0, 0x3B); //Frequency Control Word, Low Byte
CC1101_WriteReg(CCxxx0_MDMCFG4, 0x2D); //Modem Configuration
CC1101_WriteReg(CCxxx0_MDMCFG3, 0x3B); //Modem Configuration
CC1101_WriteReg(CCxxx0_MDMCFG2, 0x13); //Modem Configuration
CC1101_WriteReg(CCxxx0_DEVIATN, 0x62); //Modem Deviation Setting
CC1101_WriteReg(CCxxx0_MCSM1, 0x3F); //Main Radio Control State Machine Configuration
CC1101_WriteReg(CCxxx0_MCSM0, 0x18); //Main Radio Control State Machine Configuration
CC1101_WriteReg(CCxxx0_FOCCFG, 0x1D); //Frequency Offset Compensation Configuration
CC1101_WriteReg(CCxxx0_BSCFG, 0x1C); //Bit Synchronization Configuration
CC1101_WriteReg(CCxxx0_AGCCTRL2,0xC7); //AGC Control
CC1101_WriteReg(CCxxx0_AGCCTRL1,0x20); //AGC Control
CC1101_WriteReg(CCxxx0_AGCCTRL0,0xB0); //AGC Control
CC1101_WriteReg(CCxxx0_WORCTRL, 0xFB); //Wake On Radio Control
CC1101_WriteReg(CCxxx0_FREND1, 0xB6); //Front End RX Configuration
CC1101_WriteReg(CCxxx0_FSCAL3, 0xEA); //Frequency Synthesizer Calibration
CC1101_WriteReg(CCxxx0_FSCAL2, 0x2A); //Frequency Synthesizer Calibration
CC1101_WriteReg(CCxxx0_FSCAL1, 0x00); //Frequency Synthesizer Calibration
CC1101_WriteReg(CCxxx0_FSCAL0, 0x1F); //Frequency Synthesizer Calibration
CC1101_WriteReg(CCxxx0_TEST0, 0x09); //Various Test Settings
|
|
|
|
|
|
|
|
Sep 19 2013, 08:35
|
Частый гость
Группа: Участник
Сообщений: 166
Регистрация: 8-09-09
Из: Украина
Пользователь №: 52 244
|
Цитата(Boriska @ Sep 19 2013, 08:44) CC1101_WriteReg(CCxxx0_PKTLEN, 0xFE); //Packet Length
CC1101_WriteReg(CCxxx0_PKTCTRL1,0x0C); //Packet Automation Control
CC1101_WriteReg(CCxxx0_PKTCTRL0,0x05); //Packet Automation Control у Вас переменная или фиксированная длина пакета? У Вас стоит бил autoflush(CCxxx0_PKTCTRL1,0x0C), т.е. чтобы сбрасывать буфер в случае неправильного CRC, и в то же время стоит переменная длина пакета. autoflush вроде бы работает только с фиксированной длиной пакета при условии что этот пакет полностью помещается в приемный буфер.
|
|
|
|
|
|
|
|
Sep 19 2013, 11:01
|
Участник
Группа: Участник
Сообщений: 65
Регистрация: 28-11-07
Пользователь №: 32 772
|
Цитата(Pasha_a13 @ Sep 19 2013, 12:35) у Вас переменная или фиксированная длина пакета?
У Вас стоит бил autoflush(CCxxx0_PKTCTRL1,0x0C), т.е. чтобы сбрасывать буфер в случае неправильного CRC, и в то же время стоит переменная длина пакета.
autoflush вроде бы работает только с фиксированной длиной пакета при условии что этот пакет полностью помещается в приемный буфер. Длина пакета - переменная. Но Autoflush работает и в этом режиме. Там, правда, есть условие "The MCU must not read from the current packet until the CRC has been checked as OK." Попробую вообще отключить Autoflush. Я его установил в ходе очередного эксперимента и забыл вернуть обратно.
|
|
|
|
|
|
|
|
Sep 19 2013, 11:18
|
Частый гость
Группа: Участник
Сообщений: 166
Регистрация: 8-09-09
Из: Украина
Пользователь №: 52 244
|
Цитата(Boriska @ Sep 19 2013, 14:01) Длина пакета - переменная. Но Autoflush работает и в этом режиме. Там, правда, есть условие "The MCU must not read from the current
packet until the CRC has been checked as OK." Попробую вообще отключить Autoflush. Я его установил в ходе очередного эксперимента и забыл вернуть обратно. Да, точно. Главное чтобы длина пакета не превышала 63 байта. Вообще действительно есть ощущение что как-то из SPI неправильно читаются данные. Т.к. после строба IDLE и очистки приемного буфера там никак не должно быть каких-то данных.
|
|
|
|
|
|
|
|
Sep 19 2013, 17:41
|
Участник
Группа: Участник
Сообщений: 65
Регистрация: 28-11-07
Пользователь №: 32 772
|
Цитата(Pasha_a13 @ Sep 19 2013, 15:18) Вообще действительно есть ощущение что как-то из SPI неправильно читаются данные. Т.к. после строба IDLE и очистки приемного буфера там никак не должно быть каких-то данных. Вообщем, разобрался. Упустил один момент: "For register addresses in the range 0x30- 0x3D, the burst bit is used to select between status registers when burst bit is one, and between command strobes when burst bit is zero"
Сообщение отредактировал Boriska - Sep 19 2013, 17:42
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
