не могу понять в чем дело, настраиваю регистр MCSM1.RXOFF_MODE = 11 (3) чтоб он оставался в RX после приема пакета, но он постоянно выходит в IDLE. Что может быть причиной такого?
void CC1101_Configure(void) { CC1101_WriteReg(CCxxx0_IOCFG0,0x06); //IOCFG0 - GDO0 Output Pin Configuration CC1101_WriteReg(CCxxx0_FIFOTHR,0x47); //FIFOTHR - RX FIFO and TX FIFO Thresholds CC1101_WriteReg(CCxxx0_PKTLEN,0x3E); //PKTLEN - Packet Length CC1101_WriteReg(CCxxx0_PKTCTRL1,0x0C); //PKTCTRL1 - Packet Automation Control CC1101_WriteReg(CCxxx0_PKTCTRL0,0x05); //PKTCTRL0 - Packet Automation Control CC1101_WriteReg(CCxxx0_ADDR,0x23); //ADDR - Device Address CC1101_WriteReg(CCxxx0_CHANNR,0x01); //CHANNR - Channel Number CC1101_WriteReg(CCxxx0_FSCTRL1,0x06); //FSCTRL1 - Frequency Synthesizer Control CC1101_WriteReg(CCxxx0_FREQ2,0x10); //FREQ2 - Frequency Control Word, High Byte CC1101_WriteReg(CCxxx0_FREQ1,0xA7); //FREQ1 - Frequency Control Word, Middle Byte CC1101_WriteReg(CCxxx0_FREQ0,0x62); //FREQ0 - Frequency Control Word, Low Byte CC1101_WriteReg(CCxxx0_MDMCFG4,0xF9); //MDMCFG4 - Modem Configuration CC1101_WriteReg(CCxxx0_MDMCFG3,0x93); //MDMCFG3 - Modem Configuration CC1101_WriteReg(CCxxx0_MDMCFG2,0x43); //MDMCFG2 - Modem Configuration CC1101_WriteReg(CCxxx0_DEVIATN,0x15); //DEVIATN - Modem Deviation Setting CC1101_WriteReg(CCxxx0_MCSM0,0x18); //MCSM0 - Main Radio Control State Machine Configuration CC1101_WriteReg(CCxxx0_MCSM1,0x0F); //MCSM1 - Main Radio Control State Machine Configuration CC1101_WriteReg(CCxxx0_FOCCFG,0x16); //FOCCFG - Frequency Offset Compensation Configuration CC1101_WriteReg(CCxxx0_WORCTRL,0xFB); //WORCTRL - Wake On Radio Control CC1101_WriteReg(CCxxx0_FSCAL3,0xE9); //FSCAL3 - Frequency Synthesizer Calibration CC1101_WriteReg(CCxxx0_FSCAL2,0x2A); //FSCAL2 - Frequency Synthesizer Calibration CC1101_WriteReg(CCxxx0_FSCAL1,0x00); //FSCAL1 - Frequency Synthesizer Calibration CC1101_WriteReg(CCxxx0_FSCAL0,0x1F); //FSCAL0 - Frequency Synthesizer Calibration CC1101_WriteReg(CCxxx0_TEST2,0x81); //TEST2 - Various Test Settings CC1101_WriteReg(CCxxx0_TEST1,0x35); //TEST1 - Various Test Settings CC1101_WriteReg(CCxxx0_TEST0,0x09); //TEST0 - Various Test Settings }
Сгенеренная студией.
После инициализации периферии в МК идет такой вызов:
Код:
CC1101_Reset(); CC1101_Configure();
Далее в прерывании по падающему фронту ноги GDO0 настроенной на получение пакета попадаем в обработчик:
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Похоже, что проблема, как минимум, в том, что используется дефолтное значение регистра MCSM1, согласно которому чип после RX переходит в IDLE. Запишите в биты 3:2 этого регистра значение 11b.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Вообще, в режиме приёма пакета по GDO0, падающий уровень на нём сигнализирует о принятии лишь слова синхронизации. Для момента окончания принятия пакета следует дождаться нарастастающего уровня после того как он упал. Я это делаю обычно так (код для MSP430): Спойлер
Код:
P1IES_bit.GDO0 = 0; // set INT on low-to-high transition P1IFG = 0; // clear port IF P1IE = RST_BTN + GDO0; // enable port pin interrupts __low_power_mode_3(); // wait for receiving the sync word
P1IES_bit.GDO0 = 1; // sync word received - set INT on high-to-low transition P1IFG = 0; // clear IF P1IE_bit.GDO0 = 1; // enable GDO0 pin INT __low_power_mode_3(); // wait for receiving packet in FIFO
6 (0x06) - Asserts when sync word has been sent / received, and de-asserts at the end of the packet.
На диаграмме не видно, но уровень становится = 1, потом через 1,5 ms падает. Полагаю когда 1 - это прием синк слова, когда 0 - окончание пакета. У меня настроена автоочистка FIFO по битому пакету (CRC) и собственно пакет как видно на картинке читается корректно.
UPD: Я понял про что вы: настройка инверсии сигнала на линии:
Цитата:
0x02: IOCFG0 – GDO0 Output Pin Configuration Bit 6: Invert output, i.e. select active low (1) / high (0)
Да, пожалуй Вы правы насчёт GDO0, я уже подзабыл. Однако, я сейчас настроил один из чипов в Studio на передачу CC-дебаггером, другой на приём в дефолтной конфигурации (в ZIP архиве внизу) без выхода из режима RX. И он действительно из этого режима не выходит по приёму пакета (см. осциллограмму). Пакет состоит из слова "test" с 2 предшествующими байтами номера пакета и байтами RSSI и CRC в конце. Почитайте еррату на свою версию. Чип случаем не китайская подделка? Интересно, что у Вас лежит в регистре 0х31? У меня 0х14 - покупал его года 4 назад. Спойлер Кстати, после чтения длины принятого пакета командой 0xFB следует передёрнуть CS и уже потом в следующей сессии читать RX FIFO командой 0xFF.
Хммм, и с силлабовскими у меня никогда проблем не было - работают как часы. Правда, дело довелось иметь только с Si446x серией, приёмником Si4362, передатчиком 4060 и ещё не помню точно какими, но точно не со старой серией Si443x. Сейчас делаю проект на Si4468 с выходной мощностью +20dBm, пока он в стадии разработки. У меня тут, кстати, несколько статей в шерсти про модули на Si найдте. Модули всегда делал под них сам с одним лишь исключением в последней статье. Но в любом случае использовал некитайские модули (в последней статье) и покупал все Si чипы только у официальных дистрибъюторов. С покупкой на Али у меня нулевой опыт, только со слухов знаю, что там бывают подделки.
greeka - если то, о чём пишите, единственная проблема, что мешает Вам подать команду перевода модуля в RX после выгрузки из него пакета? Или имеется опасность пропустить какой-то пакет за время выгрузки?
Ser60 отвечу вам в своей теме. Вообщем-то проблемы нет, так и делаю. Более того, приемник не рекомендуется долго держать в состоянии приема т.к. он уплывает. Но насторожила эта ситуация, думал что я что-то упустил, ведь должно же работать как заявлено.
Еще мне непонятен такой момент - если я сразу после падения импульса на линии GDO0 буду не пытаться выгрузить пакет, а переключать в режим приема и потом выгружать текущий принятый пакет, при этом будет передаваться новый пакет, будут ли битые данные в RX FIFO?
Цитата:
У меня тут, кстати, несколько статей в шерсти про модули на Si найдте.
Подскажите как статьи искать по автору? Или дайте ссылки на них.
Details If a received data byte is written to the RX FIFO at the exact same time as the last byte in the RX FIFO is read over the SPI interface, the RX FIFO pointer is not properly updated and the last read byte is duplicated.
Workaround(s) For packets below 64 bytes, it is recommended to wait until the complete packet has been received before reading it out.
Цитата:
Более того, приемник не рекомендуется долго держать в состоянии приема т.к. он уплывает.
Если используются не амплитудная модуляция, то уход частоты можно компенсировать, в пункте 14.1 даташита сказано. Здесь пример.
Details If a received data byte is written to the RX FIFO at the exact same time as the last byte in the RX FIFO is read over the SPI interface, the RX FIFO pointer is not properly updated and the last read byte is duplicated.
Workaround(s) For packets below 64 bytes, it is recommended to wait until the complete packet has been received before reading it out.
Не понял как это относится к тому, о чем я писал. Вот пример - у меня пакет на 60 байт + системные 2 байта которые добавляет сам чип. Я получил пакет, CRC сошлось, чип дернул ногой. Я начинаю читать данные из RX FIFO и в этот же момент модуль начинает получать данные (тоже пакет на 60 байт). Под баг этот мы не попадаем, но что будет с данными, которые я еще не прочитал из буфера?
Добавлено after 4 minutes 4 seconds:
Ser60 писал(а):
У меня тут несколько статей на тему. Быстрее будет Вам нажать кнопку Профиль под этим моим сообщением, чтобы получить доступ к статьям.
что будет с данными, которые я еще не прочитал из буфера?
Они там и будут сидеть пока их не прочитаете или не очистите FIFO. Насколько я помню, последний организован как кольцевой буфер. Если для вновь принимаемых байтов не будет места в нём, чип перейдет в режим RXFIFO_OVERFLOW и приём прекратит.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 25
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
