Вопрос по содержимому регистра 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 (вдруг их меньше).

[rx3apf]

Нет, именно RXBYTES (с адресом 0x3b + 0x80).

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

числа байт в FIFO? Меня это смущает. Ведь не логично ориентироваться на длину пакета из самого пакета, а не на реальное число байтов в FIFO (вдруг их меньше).

Почему же ? Если пакет имеет произвольную и неконтролируемую длину, теряется замечательная возможность аппаратной CRC. Вот это - действительно нелогично. Можно использовать и байт длины перед пакетом, можно менять режим другим способом, но в любом случае - длина пакета _должна_ быть известна на принимающей стороне...

[plan]

Почему же ? Если пакет имеет произвольную и неконтролируемую длину, теряется замечательная возможность аппаратной CRC. Вот это - действительно нелогично. Можно использовать и байт длины перед пакетом, можно менять режим другим способом, но в любом случае - длина пакета _должна_ быть известна на принимающей стороне...

Не согласен с Вами. В сс1100 и сс2500(с другими не работал) работает описанная возможность. К примеру я отправляю 60 байт и на приемной стороне чип сам определяет длину пакета и декодирует конечную crc и после этого выдает инфу о достоверности принятого пакета. Отправлял пакеты от 1 до 62 байт и приемник аппаратно все определяет. На приемной стороне устанавливаю максимальную длину пакета 255.

[rx3apf]

Не согласен с Вами. В сс1100 и сс2500(с другими не работал) работает описанная возможность. К примеру я отправляю 60 байт и на приемной стороне чип сам определяет длину пакета и декодирует конечную crc и после этого выдает инфу о достоверности принятого пакета. Отправлял пакеты от 1 до 62 байт и приемник аппаратно все определяет. На приемной стороне устанавливаю максимальную длину пакета 255.

"Сам определяет" - это только в том случае, когда первый байт пакета содержит его длину. И он доступен на принимающей стороне. Этот вариант я, кстати, назвал. А другие варианты - пакет фиксированной длины либо "бесконечной" (когда приемник меняет режим на "фиксированный" в процессе приема, также исходя из "знания" длины пакета). Других вариантов нет.