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

Определяю число принятых байтов по значению в RXBYTES и такого не наблюдал ("максимально возможное значение 0x0f"), а вот пакеты 0-й длины приходили

Аналогично, никогда не замечал аномального поведения RXBYTES (но вообще согласно эрратам, отслеживать состояние по RXBYTES надо с осторожностью, из-за ошибки в реализации SPI). А вот что до пакетов нулевой длины - а как такое может быть ? Если в RXBYTES ноль - то в FIFO ничего нет. Или там два байта состояния, а самого пакета нет ?

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

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

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

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



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

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

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

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

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

Сейчас руки дошли поковыряться с тем проектом.
Действительно, надо выставлять флаг BURST для доступа по чтению к статусным регистрам. Иначе получаются стробы и возвращается байт состояния, а там всего 4 бита под длину.
Только сечас нашел в pdf внизу страницы мелким шрифтом указание на это. В общем, внимательнее надо было читать pdf до появления проблем, а не после них.