Вопрос по содержимому регистра RXBYTES для CC1100 Опции

[Alechin]

Вопрос в следующем - попытался определять число принятых байтов по значению в RXBYTES и натолкнулся на следующее - максимально возможное значение 0x0f, при том что в буфере лежит гораздо больше.
Т.е. при реальной длине пакета до 15 байтов - все нормально: значение в RXBYTES равно длине пакета плюс 2 (статус добавляется), а если длина принятого пакета больше 15 - значение в регистре все-равно 0x0f, хотя весь пакет успешно принят и находится в буфере, статус в конец пакета добавлен.
Сейчас выкрутился через чтение числа байтов, которое лежим вверху FIFO, но грызут сомнения, вдруг я все-таки что-то не так делаю? Хотя в TI-шном примере они то-же его (RXBYTES) не используют при чтении пакета из буфера (только проверяют, что он не равен нулю).

[ksv198]

Вопрос в следующем - попытался определять число принятых байтов по значению в RXBYTES и натолкнулся на следующее - максимально возможное значение 0x0f, при том что в буфере лежит гораздо больше.

Наверное Вы имели ввиду FIFO_BYTES_AVAILABLE в статусном байте. Там реально 4 бита и если пакет больше, то все равно 15

Пакет нулевой длины может "получиться" если не совпала контрольная сумма, а чип сконфигурен на очистку в этом случае. Тогда если в IOCFGх 0х06 то нога дернется, показывая что пакет принят, а в RXBYTES будет ноль.

[Alechin]

Наверное Вы имели ввиду FIFO_BYTES_AVAILABLE в статусном байте. Там реально 4 бита и если пакет больше, то все равно 15

Нет, именно RXBYTES (с адресом 0x3b + 0x80). А почему тогда в TI-шных примерах они его тоже не используют для определения числа байт в FIFO? Меня это смущает. Ведь не логично ориентироваться на длину пакета из самого пакета, а не на реальное число байтов в FIFO (вдруг их меньше).

[ksv198]

...А почему тогда в TI-шных примерах они его тоже не используют для определения числа байт в FIFO?

Потому что пакет может быть длинее чем размер RXFIFO

Вообще-то +0xC0...

Кстати, да. Может в этом и проблема?