Ход мысли:

а). приёмник автоматически начинает заполнение буфера сразу/только после sync word (2D D4).

Тогда надо передавать что-то типа AA AA AA . 2D D4 . первыйбайт . (AA AA AA . ?) 2D D4 . второйбайт . (AA AA AA . ?) 2D D4 . третий...
... накладных расходов не много ли?

б). приёмник автоматически начинает заполнение буфера без sync word, по VDI (несколько вариантов на выбор).

Так и будет дёргаться постоянно на мусор, зато вероятность принятия настоящих данных...
... вообще такой способ имеет ли право применяться, без sync word? зачем-то же он предусмотрен?

в). начинаем принимать первый байт пакета после sync word, а следующие байты просто по VDI?

... и я её думать.


---

В моём случае пакета иметь задумано всего два информативных байта. Номер параметра + значение.

"Посмотри мою программу разбирался тестовую короче там с каментами разберёшься вроде всё заработало в аттаче" - так не хотелось бы.
А хотелось бы идеологически+читаемо помыслить вместо коллекционирования рабочих каких-то чужих простыней. Которых простыней и в интернете уже достаточно, и на этом сайте в частности.

Ход мысли правильный, но:
1) Настраиваем на передачу
2) Передаем преамбулу AA AA AA
3) Передаем синхро 2D D4 или то, что установлено в качестве синхро...
4) Передаем сам пакет
5) Передаем опять преамбулу AA AA AA
Передача данных контроллируется по IRQ от RFM, при таймауте выходим по ошибке передачи...

В приемнике
1) Настраиваем на прием, сбрасываем FIFO
2) Ждем начала приема - это и будет первый байт из пакета
3) Принимаем байтики пакета - при таймауте приема вываливаемся по ошибке и в начало, если пакет при передаче повторяется...
4) По приему всех байт в пакете - проверяем пакет по CRC или как Вы там себе это представляете...
И типа все...
Все остальное на верхнем уровне уже.

Зачем в передатчике 5)., когда передача уже всё?
Виделись рекомендации просто один любой dummy byte передавать в конце, чтобы... что-то.

В приёмнике первый байт примется сразу после sync word 2D D4 *, а для следующих байтов получается что ли мой вариант в). ? Переключиться с заполнения буфера по sync word на заполнение по VDI (какому-то из возможных вариантов)? Или даже вообще на заполнение always?
Тогда мысль вернулась опять к вопросу б). ... тупил. Не надо встроенный модуля буфер переинициализировать перед каждым байтом.

... как приёмник, ловя мусорные биты с воздуха, определяет начало следующего байта? С sync word понимаю (понимаю? да, понимаю), а в других случаях.


Про таймаут буду постараться не забыть, да.

* оно уже выбрано производителем

---

Итого приёмник:

1). прерывание по дёрганию модулем nIRQ,
2). читаем из модуля статус = сбрасываем флаг FFIT (можно что-нибудь поделать и с другими флагами),
3). читаем из модуля содержимое его встроенного буфера, которое ложим в наш программный буфер по указателю,
4). шлём модулю команды CE84, CE87 ~ переинициализируем его встроенный буфер модуль продолжает запихивать поступающие из воздуха новые биты в свой встроенный буфер, постепенно выталкивая ими и теряя старое содержимое буфера.

5). инкрементим указатель на наш программный буфер,
6). если получился указатель меньше, чем - это был ещё не конец пакета, выходим из прерывания.

7). сейчас шлём модулю команды CE84, CE87 ~ переинициализируем его встроенный буфер, модуль начинает ждать с воздуха следующего (или следующее?) sync word.
8). обнуляем указатель на наш программный буфер...

Я "идеологически+читаемо помыслил", дальше дело Ваше как это применить, раз просили без "простыней".
Алгоритм полностью рабочий и реализованный не в одном устройстве...

Я же так и применяю *, в чём проблема?

Остался неясным смысл ААА после окончания пакета. И других способов работы с встроенным буфером модуля, отличных от старта по sync word.


* после 12 апреля, а не до первого сообщения темы