Господа, как правильно переключаться из одного режима в другой?
Вроде бы в даташите есть цифры, означающие время переключения RX->TX и TX->RX, то есть напрямую.
У меня же, если не переводить чип в режим IDLE перед каждым переключением, большие сложности со связью.
Полная версия этой страницы: cc1101 - переключение из режима передачи в режим приема и наоборот.
Форум разработчиков электроники ELECTRONIX.ru > Аналоговая и цифровая техника, прикладная электроника > Rf & Microwave Design
Вы можете, в зависимости от нужного режима работы, после инициализации и настройки регистров перейти в режим RX и в настройках поставить что после TX возвращаться автоматом в RX (ведь не постоянно же Вам нужно передавать что-то). Если нужно что-то передать, то данные грузите в буфер, потом строб STX.
После передачи микросхема сама вернется в RX.
Проблем с таким режимом небыло.
Один важный нюанс это не забыть включить периодическую авто калибровку при переходах между режимами.
Хотя если в Вашем применении нет сильно большой необходимости непрерывно висеть в RX с кратковременными переходами в TX, то можете ставить в настройках чтобы после передачи-приема возвращалось в IDLE. Например загрузили данные в буфер, послали строб STX, и читаете регистр состояния. Когда состояние стало IDLE, то все ОК, чистим передающий(возможно и приемный) буфер и посылаем строб SRX.
Но опять таки не забывать периодически калибровать.
А в чем именно выражаются проблемы со связью?
После передачи микросхема сама вернется в RX.
Проблем с таким режимом небыло.
Один важный нюанс это не забыть включить периодическую авто калибровку при переходах между режимами.
Хотя если в Вашем применении нет сильно большой необходимости непрерывно висеть в RX с кратковременными переходами в TX, то можете ставить в настройках чтобы после передачи-приема возвращалось в IDLE. Например загрузили данные в буфер, послали строб STX, и читаете регистр состояния. Когда состояние стало IDLE, то все ОК, чистим передающий(возможно и приемный) буфер и посылаем строб SRX.
Но опять таки не забывать периодически калибровать.
А в чем именно выражаются проблемы со связью?
У меня одно устройство ведущее, другое ведомое.
Ведомое постоянно висит в приеме. После обработки принятых данных отправляет ведущему ответ.
Ведущий же по таймеру периодически опрашивает ведомого - шлет команду и ждет ответ.
У меня ведомый периодически зависает в приеме. Вы как с этим боролись?
Ведомый перестает отвечать на пинг. Проверяю - несущая появляется, но синхрослово не распознается.
А где это?
Ведомое постоянно висит в приеме. После обработки принятых данных отправляет ведущему ответ.
Ведущий же по таймеру периодически опрашивает ведомого - шлет команду и ждет ответ.
У меня ведомый периодически зависает в приеме. Вы как с этим боролись?
Цитата
А в чем именно выражаются проблемы со связью?
Ведомый перестает отвечать на пинг. Проверяю - несущая появляется, но синхрослово не распознается.
Цитата
после инициализации и настройки регистров перейти в режим RX и в настройках поставить что после TX возвращаться автоматом в RX
А где это?
Цитата(zheka @ Aug 8 2013, 18:44) 
У меня одно устройство ведущее, другое ведомое.
Ведомое постоянно висит в приеме. После обработки принятых данных отправляет ведущему ответ.
Ведущий же по таймеру периодически опрашивает ведомого - шлет команду и ждет ответ.
Ведомое постоянно висит в приеме. После обработки принятых данных отправляет ведущему ответ.
Ведущий же по таймеру периодически опрашивает ведомого - шлет команду и ждет ответ.
у меня тоже использовался в одних устройствах режим когда ведомые долго висели в режиме приема, однако при подтверждении приема они всетаки переходили в tx.
Как вариант можете сделать такую фишку как переменная, которая периодически инкрементируется-декрементируется таймером раз скажем в 100мс, и если устройство за какой-то промежуток времени не приняло ничего из эфира (но Вы точно знаете что за это время должно было), то тогда переинициализацию радиочасти делать.
Ну это не совсем правильное решение конечно, лучше всетаки найти причину почему не принимает пакет.
Кстати а по логике как у Вас настроено? Пакеты которые принимаются с неправильным CRC убиваются автоматически? У Вас фиксированная длина пакета?
Имею ввиду стоит ли флажок crc_autoflush в регистре 0x07: PKTCTRL ?
Цитата(zheka @ Aug 8 2013, 18:44)
А где это?
регистр 0x17: MCSM1
RXOFF_MODE[1:0] и TXOFF_MODE[1:0]. Если TXOFF_MODE[1:0]=11 и RXOFF_MODE[1:0]=11 то после передачи-приема остается в RX
пока что я не пользовался автоопустошением, но планирую его включить.
А вообще - я немного намудрил с таймаутами (моими собственными, программными), сейчас разобрался, воде работает.
А вообще - я немного намудрил с таймаутами (моими собственными, программными), сейчас разобрался, воде работает.
Цитата(zheka @ Aug 8 2013, 21:45)
пока что я не пользовался автоопустошением, но планирую его включить.
если его включите то тогда обязательно включите чтобы оставаться в приеме после приема, иначе при приеме битого пакета автоматом уйдет в айдл.
Настроил автоматические переходы. Убрал принудительное переключение в IDLE и последующее переключение в RX .
У меня на ведомом при приеме пакета 2 раза пикает зуммер. ДО этого было ровное равномерное пиканье, как звуки сердца. После вышеописанной процедуры началась тахикардия и аритмия)))
Будем разбираться...
У меня на ведомом при приеме пакета 2 раза пикает зуммер. ДО этого было ровное равномерное пиканье, как звуки сердца. После вышеописанной процедуры началась тахикардия и аритмия)))
Будем разбираться...
Цитата(zheka @ Aug 9 2013, 06:34)
Настроил автоматические переходы. Убрал принудительное переключение в IDLE и последующее переключение в RX .
У меня на ведомом при приеме пакета 2 раза пикает зуммер. ДО этого было ровное равномерное пиканье, как звуки сердца. После вышеописанной процедуры началась тахикардия и аритмия)))
Будем разбираться...
У меня на ведомом при приеме пакета 2 раза пикает зуммер. ДО этого было ровное равномерное пиканье, как звуки сердца. После вышеописанной процедуры началась тахикардия и аритмия)))
Будем разбираться...
А как именно Вы настроили автоматические переходы? Постоянный возврат в RX или прыжки RX-TX?
Чтобы было проще понять в чем дело напишите по какому алгоритму ведущий посылает пакеты, как часто.
Скажите какая длина пакета, сколько байт преамбулы, включено ли PKTCTRL0.CRC_EN включено ли PKTCTRL1.CRC_AUTOFLUSH, по какому признаку на порт GDO выставляется флаг для контроллера что данные можно читать.
Вот код Ping_RF - на ведущем. Ping_RF_Answer() - на ведомом
CRC_EN включен, длина пакета переменная. Для пинга использую 2 байта
Пакеты посылаются раз в 50 мсек.
// --------------------------------------------------------------------------------
//
// RF PING
//
// --------------------------------------------------------------------------------
unsigned char Ping_RF()
{
RF_TX_Buffer[0]=2;
//for (i=1;i<=2;i++) RF_TX_Buffer[i]= 0xAA;
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; // заведен таймер, тикающий каждую 1 мс, он уменьшает rf_ping_timeout_tick на единицу за каждый такт и так до нуля.
while(rf_ping_timeout_tick>0)
{
if (GDO0_flag==1) // GDO0_flag становится равным единице в обработчике прерывания, который ловит спад импульса на GDO0, настроенном на приход синхрослова.
{
TX_OFF;
rf_ping_timeout_tick=0;
GDO0_flag=0;
}
}
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFTX);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
// 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;
return 0;
}
// НА ВЕДОМОМ В ЦИКЛЕ ЛОВИТСЯ ФЛАГ GDO0, посылка обрабатывается и вызывается Ping_RF_Answer()
// --------------------------------------------------------------------------------
//
// ОТВЕТ НА RF PING
//
// --------------------------------------------------------------------------------
void Ping_RF_Answer()
{
RX_OFF;
RF_TX_Buffer[0]=2;
for (i=1;i<=2;i++) RF_TX_Buffer[i]= 0xFF;
TI_CC_SPIWriteBurstReg(TI_CCxxx0_TXFIFO, RF_TX_Buffer, 3);
TX_ON;
TI_CC_SPIStrobe(TI_CCxxx0_STX);
while(!GDO0_flag);
TX_OFF;
GDO0_flag=0;
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFTX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
RX_ON;
}
А вот конфиг:
CRC_EN включен, длина пакета переменная. Для пинга использую 2 байта
Пакеты посылаются раз в 50 мсек.
Код
// --------------------------------------------------------------------------------
//
// RF PING
//
// --------------------------------------------------------------------------------
unsigned char Ping_RF()
{
RF_TX_Buffer[0]=2;
//for (i=1;i<=2;i++) RF_TX_Buffer[i]= 0xAA;
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; // заведен таймер, тикающий каждую 1 мс, он уменьшает rf_ping_timeout_tick на единицу за каждый такт и так до нуля.
while(rf_ping_timeout_tick>0)
{
if (GDO0_flag==1) // GDO0_flag становится равным единице в обработчике прерывания, который ловит спад импульса на GDO0, настроенном на приход синхрослова.
{
TX_OFF;
rf_ping_timeout_tick=0;
GDO0_flag=0;
}
}
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFTX);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
// 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;
return 0;
}
// НА ВЕДОМОМ В ЦИКЛЕ ЛОВИТСЯ ФЛАГ GDO0, посылка обрабатывается и вызывается Ping_RF_Answer()
// --------------------------------------------------------------------------------
//
// ОТВЕТ НА RF PING
//
// --------------------------------------------------------------------------------
void Ping_RF_Answer()
{
RX_OFF;
RF_TX_Buffer[0]=2;
for (i=1;i<=2;i++) RF_TX_Buffer[i]= 0xFF;
TI_CC_SPIWriteBurstReg(TI_CCxxx0_TXFIFO, RF_TX_Buffer, 3);
TX_ON;
TI_CC_SPIStrobe(TI_CCxxx0_STX);
while(!GDO0_flag);
TX_OFF;
GDO0_flag=0;
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFTX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
RX_ON;
}
А вот конфиг:
Код
void writeRFSettings(void)
{
// Write register settings
TI_CC_SPIWriteReg(TI_CCxxx0_FSCTRL1,0x0c);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCTRL0,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ2,0x5B);
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ1,0xFB);
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ0,0x04);//04 rx 7c jeep
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG4,0x2d);
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG3,0x36);
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG2,0x73);
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG1,0xc2);
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG0,0xEF);
TI_CC_SPIWriteReg(TI_CCxxx0_CHANNR,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_DEVIATN,0x01);
TI_CC_SPIWriteReg(TI_CCxxx0_FREND1,0x56);
TI_CC_SPIWriteReg(TI_CCxxx0_FREND0,0x10);
TI_CC_SPIWriteReg(TI_CCxxx0_MCSM2,0x07);
TI_CC_SPIWriteReg(TI_CCxxx0_MCSM1,0x3F);//30
TI_CC_SPIWriteReg(TI_CCxxx0_MCSM0,0x18);
TI_CC_SPIWriteReg(TI_CCxxx0_FOCCFG,0x15);
TI_CC_SPIWriteReg(TI_CCxxx0_BSCFG,0x6C);
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL2,0xc3);
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL1,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL0,0x91);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL3,0xea);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL2,0x0A);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL1,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL0,0x11);
TI_CC_SPIWriteReg(TI_CCxxx0_FSTEST,0x59);
TI_CC_SPIWriteReg(TI_CCxxx0_TEST2,0x8f);
TI_CC_SPIWriteReg(TI_CCxxx0_TEST1,0x21);
TI_CC_SPIWriteReg(TI_CCxxx0_TEST0,0x0B);
TI_CC_SPIWriteReg(TI_CCxxx0_IOCFG2,0x0E);
TI_CC_SPIWriteReg(TI_CCxxx0_IOCFG0,0x06);
TI_CC_SPIWriteReg(TI_CCxxx0_PKTCTRL1,0x0C);//05
TI_CC_SPIWriteReg(TI_CCxxx0_PKTCTRL0,0x0D);
TI_CC_SPIWriteReg(TI_CCxxx0_ADDR,0x01);
TI_CC_SPIWriteReg(TI_CCxxx0_PKTLEN,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_FIFOTHR,0x07);
}
{
// Write register settings
TI_CC_SPIWriteReg(TI_CCxxx0_FSCTRL1,0x0c);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCTRL0,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ2,0x5B);
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ1,0xFB);
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ0,0x04);//04 rx 7c jeep
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG4,0x2d);
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG3,0x36);
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG2,0x73);
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG1,0xc2);
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG0,0xEF);
TI_CC_SPIWriteReg(TI_CCxxx0_CHANNR,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_DEVIATN,0x01);
TI_CC_SPIWriteReg(TI_CCxxx0_FREND1,0x56);
TI_CC_SPIWriteReg(TI_CCxxx0_FREND0,0x10);
TI_CC_SPIWriteReg(TI_CCxxx0_MCSM2,0x07);
TI_CC_SPIWriteReg(TI_CCxxx0_MCSM1,0x3F);//30
TI_CC_SPIWriteReg(TI_CCxxx0_MCSM0,0x18);
TI_CC_SPIWriteReg(TI_CCxxx0_FOCCFG,0x15);
TI_CC_SPIWriteReg(TI_CCxxx0_BSCFG,0x6C);
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL2,0xc3);
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL1,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL0,0x91);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL3,0xea);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL2,0x0A);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL1,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL0,0x11);
TI_CC_SPIWriteReg(TI_CCxxx0_FSTEST,0x59);
TI_CC_SPIWriteReg(TI_CCxxx0_TEST2,0x8f);
TI_CC_SPIWriteReg(TI_CCxxx0_TEST1,0x21);
TI_CC_SPIWriteReg(TI_CCxxx0_TEST0,0x0B);
TI_CC_SPIWriteReg(TI_CCxxx0_IOCFG2,0x0E);
TI_CC_SPIWriteReg(TI_CCxxx0_IOCFG0,0x06);
TI_CC_SPIWriteReg(TI_CCxxx0_PKTCTRL1,0x0C);//05
TI_CC_SPIWriteReg(TI_CCxxx0_PKTCTRL0,0x0D);
TI_CC_SPIWriteReg(TI_CCxxx0_ADDR,0x01);
TI_CC_SPIWriteReg(TI_CCxxx0_PKTLEN,0x00);
TI_CC_SPIWriteReg(TI_CCxxx0_FIFOTHR,0x07);
}
я всегда использовал постоянную длину пакета, потому не знаю нюансов связанных с переменной длиной.
Сейчас посмотрю по тому что есть, может что-то увижу.
Сейчас посмотрю по тому что есть, может что-то увижу.
А у меня острая необходимость в переменной длине. ОТправлять нужно много чего но редко, а вот пинговать надо постоянно и при этом как можно меньше засорять эфир.
а зачем после строба передачи у Вас отслеживается while(!GDO0_flag); ? ведь у Вас вроде GDO0 используется для отслеживания прихода синхрослов при приеме, или где-то он потом перестраивается перед передачей?
Я вас обманул - у меня CRC_AUTOFLUSH включен.
у меня он настроен на 0x06 (стр.62 даташита). В этом режиме фронт по отправке/приходу синхрослова, а спад по окончанию передачи/приема пакета.
Если пакет длинный, то я дожидаюсь конца его отправки перед тем, как переводить в IDLE. То есть, я дожидаюсь спада.
Цитата
а зачем после строба передачи у Вас отслеживается while(!GDO0_flag); ? ведь у Вас вроде GDO0 используется для отслеживания прихода синхрослов при приеме, или где-то он потом перестраивается перед передачей?
у меня он настроен на 0x06 (стр.62 даташита). В этом режиме фронт по отправке/приходу синхрослова, а спад по окончанию передачи/приема пакета.
Если пакет длинный, то я дожидаюсь конца его отправки перед тем, как переводить в IDLE. То есть, я дожидаюсь спада.
уже понял. Я просто не использовал этой функции(опять таки, т.к. не работал с переменной длиной пакета 
)
Кстати, а Вы калибровку делаете? А то в этом коде просто я ее не увидел, потому и решил уточнить. У меня были как-то проблемы со связью связанные именно с тем что я забыл включить периодическую калибровку.
А как в дальнейшем работает логика? я имею ввиду что пакет передали, в течении таймаута ждете когда он уйдет, ушел, потом в прием, снова таймаут и в течении него опрос приема пакета. Если пакет не пришел или побился(преамбула не принялась нормально), то вышли из Ping_RF. В следующий раз при заходе, связь установилась нормально, пакет принялся. Это тоже может вызывать нестабильное пищание бузера, не равные промежутки.
Пинги идут через четкие промежутки времени? Или если пинг не прошел, то идет переповтор?
Может стоит добавить небольшую паузу в ведомом перед ответом, чтобы быть точно уверенным что ведущий перешел в прием и уже нормально готов принять пакет.
)Кстати, а Вы калибровку делаете? А то в этом коде просто я ее не увидел, потому и решил уточнить. У меня были как-то проблемы со связью связанные именно с тем что я забыл включить периодическую калибровку.
А как в дальнейшем работает логика? я имею ввиду что пакет передали, в течении таймаута ждете когда он уйдет, ушел, потом в прием, снова таймаут и в течении него опрос приема пакета. Если пакет не пришел или побился(преамбула не принялась нормально), то вышли из Ping_RF. В следующий раз при заходе, связь установилась нормально, пакет принялся. Это тоже может вызывать нестабильное пищание бузера, не равные промежутки.
Пинги идут через четкие промежутки времени? Или если пинг не прошел, то идет переповтор?
Может стоит добавить небольшую паузу в ведомом перед ответом, чтобы быть точно уверенным что ведущий перешел в прием и уже нормально готов принять пакет.
Простите, а калибровку нужно делать периодически? А не один раз при старте? Я не знал.
А нельзя ли поподробнее, как часто и как именно -в деталях. ПРосто давать строб FSCAL ?
Через четкие промежутки.
Если пинг не прошел, то инкрементируется счетчик ошибок. Если их подряд больше 20 - устанавливается флаг потери связи.
Пауза есть, 1 мсек.
В самом начале чип запускаю так:
А нельзя ли поподробнее, как часто и как именно -в деталях. ПРосто давать строб FSCAL ?
Цитата
Пинги идут через четкие промежутки времени?
Через четкие промежутки.
Если пинг не прошел, то инкрементируется счетчик ошибок. Если их подряд больше 20 - устанавливается флаг потери связи.
Цитата
Может стоит добавить небольшую паузу в ведомом перед ответом, чтобы быть точно уверенным что ведущий перешел в прием и уже нормально готов принять пакет.
Пауза есть, 1 мсек.
В самом начале чип запускаю так:
Код
TI_CC_SPISetup();
TI_CC_PowerupResetCCxxxx();
writeRFSettings433(); // Write RF settings to config reg
TI_CC_SPIWriteBurstReg(TI_CCxxx0_PATABLE, paTable, paTableLen);//Write PATABLE
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SCAL);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SFTX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
TI_CC_PowerupResetCCxxxx();
writeRFSettings433(); // Write RF settings to config reg
TI_CC_SPIWriteBurstReg(TI_CCxxx0_PATABLE, paTable, paTableLen);//Write PATABLE
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SCAL);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SFTX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
да, калибровать нужно периодически. Я не скажу насколько часто. Но даже исходя из того что в кристале заложены в настройках варианты калибровать каждое 4-е переключение и другие, я сделал вывод что всетаки будет спокойнее калибровать хотя бы раз в несколько переключений прием-передача-айдл.
Цитата
сли пакет не пришел или побился(преамбула не принялась нормально), то вышли из Ping_RF
Я из пинга выхожу в любом случае, просто функция пинг возвращает 1 или 0, в зависимости от результата.
Как калибровать-то? Там какие-то два вида калибровки описывались.
Просто команда TI_CC_SPIStrobe(TI_CCxxx0_SCAL); подойдет?
может попробуйте увеличить хотя бы до 2-3мс и посмотреть что будет, т.к. если предположить что кроме переключения происходит еще периодическая калибровка, то судя по времянкам в таблице даташита время переключения в айдл из приема-передачи и обратно с калибровкой это почти 1 мс.
Да, калибровка - строб SCAL
Да, калибровка - строб SCAL
Чип что, от переключений так частоту уводит сильно?
Цитата(zheka @ Aug 9 2013, 19:46)
Чип что, от переключений так частоту уводит сильно?
К сожалению я этого не знаю. Просто у меня была ситуация что были проблемы со связью из-за отсутствия периодической калибровки.
Продолжаю биться.
С переходом в RX после TX все получается. - А вот наоборот - нет.
Прежде чем приводить код, опишу алгоритм на пальцах.
Ведущий: отправляет посылку в 2 байта (пинг), немедленно переходит в прием. Получая ответ на пинг функция Ping_RF() завершается. Далее следует принудительная пауза в 10 мс и далее по кругу. ТАймаут на ожидание ответа - 100 мсек.
Ведомый: в цикле ловит спад на GDO0, после чего переписывает пришедший пакет из FIFO в буфер контроллера. Если пинг корректен (2 байта), то пикает динамиком ( beep() ) отправляет ответ ( Ping_RF_Answer() ).
Если все хорошо, то ведомый постоянно трещит динамиком - близко к сотне посылок в секунду, как раз соответствует паузе в цикле в 10 мсек, что говорит о том, что пропусков пакетов нет.
Далее есть 3 строки
после переписывания данных из 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);
}
Вот код ведомого:
Где я что делаю не так?
С переходом в 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);
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);
}
}
}
}
{
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, 12:01)
Далее есть 3 строки
после переписывания данных из FIFO.
Стоит закомментировать перевод в IDLE - начинает пикать около 10 раз в секунду, светодиод, который должен загораться по таймауту, начинает моргать.
Но и динамик довольно часто пикает - то есть пакеты довольно часто и причем равномерно проходят.
Что самое интересное - строб SRX можно убрать, переводится автоматом, но почему-то хочет чтобы после обработки буфера был переовд в IDLE.
Код
TI_CC_SPIStrobe(TI_CCxxx0_SIDLE);
TI_CC_SPIStrobe(TI_CCxxx0_SFRX);
TI_CC_SPIStrobe(TI_CCxxx0_SRX);
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 вручную, то Вы после этого принудительно очищаете приемный буфет после чтения из него.
Не может ли получатся что где-то не до конца что-то вычитывается из буфера?
У меня возник очередной затык на пути освоения СС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
Подскажите, что может быть?
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
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
Цитата(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
CC1101_WriteReg(CCxxx0_PKTCTRL1,0x0C); //Packet Automation Control
CC1101_WriteReg(CCxxx0_PKTCTRL0,0x05); //Packet Automation Control
у Вас переменная или фиксированная длина пакета?
У Вас стоит бил autoflush(CCxxx0_PKTCTRL1,0x0C), т.е. чтобы сбрасывать буфер в случае неправильного CRC, и в то же время стоит переменная длина пакета.
autoflush вроде бы работает только с фиксированной длиной пакета при условии что этот пакет полностью помещается в приемный буфер.
Калибровка нужна только при включении или сильной смене температуры.Как я понял ее суть — в память пишутся напряжения ГУН и ФАПЧ может потом стартовать с уже очень близкой частоты
Цитата(Pasha_a13 @ Sep 19 2013, 12:35)
у Вас переменная или фиксированная длина пакета?
У Вас стоит бил autoflush(CCxxx0_PKTCTRL1,0x0C), т.е. чтобы сбрасывать буфер в случае неправильного CRC, и в то же время стоит переменная длина пакета.
autoflush вроде бы работает только с фиксированной длиной пакета при условии что этот пакет полностью помещается в приемный буфер.
У Вас стоит бил 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. Я его установил в ходе очередного эксперимента и забыл вернуть обратно.
Цитата(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. Я его установил в ходе очередного эксперимента и забыл вернуть обратно.
packet until the CRC has been checked as OK." Попробую вообще отключить Autoflush. Я его установил в ходе очередного эксперимента и забыл вернуть обратно.
Да, точно. Главное чтобы длина пакета не превышала 63 байта.
Вообще действительно есть ощущение что как-то из SPI неправильно читаются данные. Т.к. после строба IDLE и очистки приемного буфера там никак не должно быть каких-то данных.
Цитата(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"
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.