cc1101 - переключение из режима передачи в режим приема и наоборот. Опции

[zheka]

Господа, как правильно переключаться из одного режима в другой?
Вроде бы в даташите есть цифры, означающие время переключения RX->TX и TX->RX, то есть напрямую.
У меня же, если не переводить чип в режим IDLE перед каждым переключением, большие сложности со связью.

[Pasha_a13]

Вы можете, в зависимости от нужного режима работы, после инициализации и настройки регистров перейти в режим RX и в настройках поставить что после TX возвращаться автоматом в RX (ведь не постоянно же Вам нужно передавать что-то). Если нужно что-то передать, то данные грузите в буфер, потом строб STX.
После передачи микросхема сама вернется в RX.
Проблем с таким режимом небыло.
Один важный нюанс это не забыть включить периодическую авто калибровку при переходах между режимами.
Хотя если в Вашем применении нет сильно большой необходимости непрерывно висеть в RX с кратковременными переходами в TX, то можете ставить в настройках чтобы после передачи-приема возвращалось в IDLE. Например загрузили данные в буфер, послали строб STX, и читаете регистр состояния. Когда состояние стало IDLE, то все ОК, чистим передающий(возможно и приемный) буфер и посылаем строб SRX.
Но опять таки не забывать периодически калибровать.
А в чем именно выражаются проблемы со связью?

Сообщение отредактировал Pasha_a13 - Aug 7 2013, 16:40

[zheka]

У меня одно устройство ведущее, другое ведомое.
Ведомое постоянно висит в приеме. После обработки принятых данных отправляет ведущему ответ.
Ведущий же по таймеру периодически опрашивает ведомого - шлет команду и ждет ответ.

У меня ведомый периодически зависает в приеме. Вы как с этим боролись?

А в чем именно выражаются проблемы со связью?

Ведомый перестает отвечать на пинг. Проверяю - несущая появляется, но синхрослово не распознается.

после инициализации и настройки регистров перейти в режим RX и в настройках поставить что после TX возвращаться автоматом в RX

А где это?

Сообщение отредактировал zheka - Aug 8 2013, 15:37

[Pasha_a13]

У меня одно устройство ведущее, другое ведомое.
Ведомое постоянно висит в приеме. После обработки принятых данных отправляет ведущему ответ.
Ведущий же по таймеру периодически опрашивает ведомого - шлет команду и ждет ответ.

у меня тоже использовался в одних устройствах режим когда ведомые долго висели в режиме приема, однако при подтверждении приема они всетаки переходили в tx.
Как вариант можете сделать такую фишку как переменная, которая периодически инкрементируется-декрементируется таймером раз скажем в 100мс, и если устройство за какой-то промежуток времени не приняло ничего из эфира (но Вы точно знаете что за это время должно было), то тогда переинициализацию радиочасти делать.
Ну это не совсем правильное решение конечно, лучше всетаки найти причину почему не принимает пакет.
Кстати а по логике как у Вас настроено? Пакеты которые принимаются с неправильным CRC убиваются автоматически? У Вас фиксированная длина пакета?
Имею ввиду стоит ли флажок crc_autoflush в регистре 0x07: PKTCTRL ?

А где это?

регистр 0x17: MCSM1
RXOFF_MODE[1:0] и TXOFF_MODE[1:0]. Если TXOFF_MODE[1:0]=11 и RXOFF_MODE[1:0]=11 то после передачи-приема остается в RX

Сообщение отредактировал Pasha_a13 - Aug 8 2013, 18:43

[zheka]

пока что я не пользовался автоопустошением, но планирую его включить.

А вообще - я немного намудрил с таймаутами (моими собственными, программными), сейчас разобрался, воде работает.



Сообщение отредактировал zheka - Aug 8 2013, 18:47

[Pasha_a13]

пока что я не пользовался автоопустошением, но планирую его включить.

если его включите то тогда обязательно включите чтобы оставаться в приеме после приема, иначе при приеме битого пакета автоматом уйдет в айдл.

[zheka]

Настроил автоматические переходы. Убрал принудительное переключение в IDLE и последующее переключение в RX .
У меня на ведомом при приеме пакета 2 раза пикает зуммер. ДО этого было ровное равномерное пиканье, как звуки сердца. После вышеописанной процедуры началась тахикардия и аритмия)))

Будем разбираться...

[Pasha_a13]

Настроил автоматические переходы. Убрал принудительное переключение в IDLE и последующее переключение в RX .
У меня на ведомом при приеме пакета 2 раза пикает зуммер. ДО этого было ровное равномерное пиканье, как звуки сердца. После вышеописанной процедуры началась тахикардия и аритмия)))

Будем разбираться...

А как именно Вы настроили автоматические переходы? Постоянный возврат в RX или прыжки RX-TX?
Чтобы было проще понять в чем дело напишите по какому алгоритму ведущий посылает пакеты, как часто.
Скажите какая длина пакета, сколько байт преамбулы, включено ли PKTCTRL0.CRC_EN включено ли PKTCTRL1.CRC_AUTOFLUSH, по какому признаку на порт GDO выставляется флаг для контроллера что данные можно читать.

[zheka]

Вот код 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;  
    }

А вот конфиг:

Код

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);

}

Сообщение отредактировал zheka - Aug 9 2013, 13:24

[Pasha_a13]

я всегда использовал постоянную длину пакета, потому не знаю нюансов связанных с переменной длиной.
Сейчас посмотрю по тому что есть, может что-то увижу.

[zheka]

А у меня острая необходимость в переменной длине. ОТправлять нужно много чего но редко, а вот пинговать надо постоянно и при этом как можно меньше засорять эфир.

[Pasha_a13]

а зачем после строба передачи у Вас отслеживается while(!GDO0_flag); ? ведь у Вас вроде GDO0 используется для отслеживания прихода синхрослов при приеме, или где-то он потом перестраивается перед передачей?

Сообщение отредактировал Pasha_a13 - Aug 9 2013, 13:39

[zheka]

Я вас обманул - у меня CRC_AUTOFLUSH включен.

а зачем после строба передачи у Вас отслеживается while(!GDO0_flag); ? ведь у Вас вроде GDO0 используется для отслеживания прихода синхрослов при приеме, или где-то он потом перестраивается перед передачей?

у меня он настроен на 0x06 (стр.62 даташита). В этом режиме фронт по отправке/приходу синхрослова, а спад по окончанию передачи/приема пакета.
Если пакет длинный, то я дожидаюсь конца его отправки перед тем, как переводить в IDLE. То есть, я дожидаюсь спада.

Сообщение отредактировал zheka - Aug 9 2013, 13:43

[Pasha_a13]

уже понял. Я просто не использовал этой функции(опять таки, т.к. не работал с переменной длиной пакета )

Кстати, а Вы калибровку делаете? А то в этом коде просто я ее не увидел, потому и решил уточнить. У меня были как-то проблемы со связью связанные именно с тем что я забыл включить периодическую калибровку.

А как в дальнейшем работает логика? я имею ввиду что пакет передали, в течении таймаута ждете когда он уйдет, ушел, потом в прием, снова таймаут и в течении него опрос приема пакета. Если пакет не пришел или побился(преамбула не принялась нормально), то вышли из Ping_RF. В следующий раз при заходе, связь установилась нормально, пакет принялся. Это тоже может вызывать нестабильное пищание бузера, не равные промежутки.
Пинги идут через четкие промежутки времени? Или если пинг не прошел, то идет переповтор?
Может стоит добавить небольшую паузу в ведомом перед ответом, чтобы быть точно уверенным что ведущий перешел в прием и уже нормально готов принять пакет.

Сообщение отредактировал Pasha_a13 - Aug 9 2013, 14:25

[zheka]

Простите, а калибровку нужно делать периодически? А не один раз при старте? Я не знал.

А нельзя ли поподробнее, как часто и как именно -в деталях. ПРосто давать строб 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);

Сообщение отредактировал zheka - Aug 9 2013, 16:37