Есть 1 передатчик 1 приемник нужно передавать 2 16-битных числа(значащих 12бит) т.е. 4 байта.
Как наиболее оптимально с вашей точки зрения организовать передачу так что бы данные корректно воспринимались приемником при периодически пропадающей связи?

Мои варианты:
1 Вести временные задержки между пакетами и/или байтами и/или словами..
2 Ввести идентификатор в каждый байт за счет не значащих бит.

Плохая связь - это ещё и ошибки. Лучше всего заголовок, помехоустойчивое кодирование, контрольная сумма и манчестер.

Вариант самый простой - передавать числа символьными кодами, а "Возврат каретки, Перевод строки" - это разделитель кадра...
Внутрь кадра можно делить контрольные суммы, можно делать перезапросы и т.д.
А если 2 байта в линии на байт данных жалко, то делайте байт-стаффинг, например как в Wake. Правда тут кодирование сложнее.

все ваши варианты это изобретение велосипеда. Реализуйте Modbus-RTU или любой другой протокол.

Я как раз и спрашиваю что бы велосипед не изобретать)

1 Modbus-RTU подразумевает двусторонний обмен тут же обмен односторонний строго от передатчика к приемнику.

2 Манчестер это что ?

Дополню: по сути передатчик это датчик 2 токов который постоянно меряет и постоянно передаёт, канал обмена оптоволоконный на стороне передатчика светодиод. При передаче основные проблемы перезагрузка датчика т.е. временный обрыв связи ну или полное пропадание связи.

Сообщение отредактировал LeDima - May 15 2015, 06:25

Мой излюбленный метод - использовать старшие биты для маркировки начала посылки. Т.е. формирую посылку такого типа:

При этом стартовый байт легко отличим по старшей единичке, а срыв синхронизации легко определяется, если эта единичка встретилась во 2-ом или 3-ем байте (в последнем случае байт единичкой считается началом новой посылки).

Правда, у меня таких байт больше трех, т.к. АЦП у меня 24-разрядный, но суть та же самая.

Есть и альтернативный вариант (более простой для МК, т.к. не требует сдвига) - выносить старшие биты числа в 1-ый байт. Выглядит это так:


Дешифровка только кажется сложной, тогда как на самом деле все биты, за исключением D15 и D7, уже стоят на своих местах, а D15 и D7 нужно только к ним добавить.

А если "D13 - D12 - D11 - D10 - D9" будут нулями? Как тогда первый байт отличить от второго?

Подразумевается, что биты внутри байт не сползают. Т.е. это что-то вроде передачи типа UART, I2C, SPI, где байт получаешь (аппаратно!) целиком и независимо от содержимого предыдущего байта. Ну, а тестируем в поступающих байтах старший бит, как признак начала посылки. При пропуске байта, потеряется всего одна посылка, но синхронизация не будет сбита.

Понятно, спасибо!

Можно слегка модифицировать код от Xenia, передавать в старших двух битах номер байта.
1 0 - 0 0 D15 ... D12
0 1 - D11 ... D6
0 0 - D5 ... D0
Еще останется комбинация 1 1 для особых случаев.

Я в таких случаях просто выводил текст а ascii.
printf("%d\t%d\r\n", x1, x2);
Числа разделяются символом табуляции, в конце строки CR и LF.
Всё это ловится терминалом и пишется в лог.
Можно глазами посмотреть, можно зачитать в excel для обработки и рисования графиков.
Своей программой тоже не сложно ловить - читаем строку, обрабатываем.
Для борьбы с обрывами связи можно либо выдавать из устройства время (или просто порядковый номер) либо в терминале настроить добавление в лог меток времени (Br@y Terminal это умеет).

Это уже перестраховка. В случае предрасположенности к паранойе имеет смысл задержать "ассимиляцию" числа, пока не убедишься, что 4-ый байт содержит старшую единичку. Вероятностью того, что два байта между двумя стартовыми байтами поменяют порядок, полагаю, можно пренебречь.


printf долго работает, а при больших скоростях передачи это слишком тормозно. Кроме того, текстовая передача числовой информации слишком избыточна, чтобы оправдывать уровень своей надежности. А он, прямо скажем, невелик. Например, потеряется в посылке один байт/цифра и вы станет в 10 раз беднее .