Контроль правильности передачи по USART, Подскажите как проверить надежность Опции

[Serega Doc]

Пересылка данных между мастером и слейвом (На 64 MEGE) - мультипроцессорный обмен
В основном long числа
Как проверить правильность передачи.
1 вариант (сложный)
Можно использовать встроенний контрольчетности
Но тогда если не правильная посылка то необходимо повторять только один байт и еще и делать анализ какой байт из 4 принят.
2 вариант (IMHO проще 1-го)
Может быть лучше пятым байтом досылать еще и по XOR сложенные 4 байта long числа
И в следующем сеансе связи просить повтор того что передалось не правильно
Думал 5 байтом применить CRC8 контроль но это много ресурсов и времени для расчетов

[Виктория]

Основной критерий выбора - какой? И ограничения временные?

Можно ведь и исправляющие коды применить. Чтобы не переспрашивать в следующем сеансе.

[andrvisht]

Думал 5 байтом применить CRC8 контроль но это много ресурсов и времени для расчетов

Да почему много ? табличный СRС8 (выложен в прикрепленной теме) дает довольно быстрый результат.
что касается объёма то для 64к наверное найдеться место...
для 4-х long наверное лучьше подойдет CRC16...
В крайнем случае можно считать CRC для каждого байта перед отправкой, или при приеме.

[Serega Doc]

Основной критерий это как можно меньше слать байт и делать повторов
А так же простой алгоритм

[Petka]

Понимаю, что вам хочется по-надёжнее, но задайтесь вопросом: так ли на самом деле нужна надёжность? Задумайтесь, если вы используете механизм передачи, который допускает ошибки, а вам они не нужны, зачем вам такой механизм передачи? програмные средства коррекции и учёта ошибок это уже последняя возможность поправить дело в уже готовом проекте. Мой совет: если у вас чистый UART работает с ошибками, навесьте на него 485й. на мой взгляд хватит примитивной програмной проверки на целостность пакета, например XORа всего пакета. если XOR не сошёлся, просто игнорируйте пакет. да, и не забудьте так организовать протокол передачи, что один пропущенный пакет ни на чём серьёзно не скажется. (например стоит пересылать абсолютные значения величин, а не события их увеличения/уменьшения)

Сообщение отредактировал Petka - Jan 9 2006, 11:39

[Serega Doc]

Насколько надежно будут пересылатся данные это вопрос - поет на стадии разработки. Теоретически помех быть не должно но когда это все встанет на линию не известно какие помехи могут появится при эксплуатации устройства. Пересылка абсолютных величин и проверка на правильность изменения допустим +1 за 10 сек и не как не больше - так и задумывалось.

Вот и возникает вопрос как оценить надежность

[Volodymyr]

Возможно использовать помехозащищённые коды. Единственное - нужно как-то спрогнозировать количество ошибок на одну посылку.

[Petka]

Вот и возникает вопрос как оценить надежность

если вы хотите действительно точно и верно оцнить надёжность, то должны:

1) сформулировать критерий надёжности.
2) построить мат. модель в которой будут необходимые параметры для расчёта надёжности.
3) смоделировать работу мат. модели.
4) получить надёжность.

выбор 1 пункта должны сделать вы и только вы. напимер, для одних задач похождение 50% пакетов это надёжно, для других и прохождение 99,999% пакетов ненадёжно. Если у вас будет протокол с пересылкой плохо переданных даных, то в надёжность будет ещё входить и время прохождения пакета, с учётом вероятной пересылки его... и в том же духе.
2 пункт вы будете строить из статистических данных линии передачи, т.е. вероятность помехи, её длительность, отсюда выводится вероятность помехи в 2х битах.... и.т.д. т.е. большая работа.
3 пункт можете реализовать чисто математически. или же моделированием на компьютере "в лоб " с составлением последующей статистики.
4 пункт совсем элементарен. полученные цифры сверяете с пунктом 1! И только после этого вы сможете понять НАДЁЖНО ЛИ ВАШЕ устройство в заданных условиях.


все советы типа "надёжно будет так-то" или "так будет ненадёжно" безсмыслены в общем случае. т.к. даются обычно без учёта всех условий. а учитывать все условия кроме вас никто не будет =) откуда я знаю будут ли рядом с вашей линией радиостанции? или откуда я могу знать что линия связи 1км, и экспуатироваться будет непросыхающими электриками, окончившими 9 классов. ясно, что даже самый "надёжный" способ связи в моём понимании будет ненадёжным для вас.

Сообщение отредактировал Petka - Jan 9 2006, 13:22

[*SERG]

может эхо использовать

Сообщение отредактировал *SERG - Jan 9 2006, 13:59

[defunct]

может эхо использовать

У эхоплекса тоже есть недостатки.. Высокая избыточность, сложность фильтрации пакета на приемной стороне (т.е. передающая сторона по эху легко определит, что пакет битый, а с принимающей стороной сложнее).

CRC imho надежнее..

[Laptop]

Для контроля правильности посылки вполне хватит CRC8. Не так уж и долго при табличном методе.
А вот протокол передачи будет сильно зависить от системы в которой все это будет крутится, необходимо как-то идентифицировать начало пакета. Это может быть как вариант с взведенным 9-м битом, так и более сложный вариант с анализом пауз передачи между пакетами или вариант с XON-XOFF.
В твоем случае нужно указать какие именно данные будешь передавать и уже тогда придумывать протокол. Ты ведь указал что у тебя В ОСНОВНОМ лонги. А что еще передается? Может необходимо указывать тип передаваемых данных?
Имхо, в твоем случае видимо проще передавать первый байт с девятым битом для указания длины пакета, затем сам пакет и crc.
Дополнительно конечно необходимо смотреть все ошибки в регистре статуса уарта.

[haker_fox]

2Serega Doc: может Вам это подойдет
http://www.spetspribor.com/support/software/wake/wake.html
применил этот протокол для связи IBM PC с девайсом на mega16, остался доволен.
Хотя в вашем случае наверно можно обойтись меньшими затратами...
Но за основу вполне этот протокол можно взять.

[Gennadiy_]

Позаимствуй протокол из стандарта Irda там используется PPP и CRC16, только вместо таблицы
Перед вызовом таблицы
eor CRC_L,Ir_byte_buf ;считаем FCS

таблица может быть вызвана перед выходом из обработчика,
если используется полный дуплекс я делал две подпрограммы для экономии времени.



CRC_V_table:
mov temp_a,CRC_L ; 1
swap temp_a ; 1
andi temp_a,$F0 ; 1
eor CRC_L,temp_a ; 1 FCS_L = FCS_L XOR (FCS_L << 4)

mov temp_a,CRC_L ; 1
swap temp_a ; 1
andi temp_a,$0F ; 1
lsr temp_a ; 1
eor temp_a,CRC_L ; 1 temp_a = FCS_L XOR (FCS_L >> 5)

lsl CRC_L ; 1
lsl CRC_L ; 1
lsl CRC_L ; 1
eor CRC_L,CRC_H ; 1 FCS_L = (FCS_L << 3) XOR FCS_H

mov CRC_H,temp_a ; 1 FCS_H = temp_a

swap temp_a ; 1
andi temp_a,$0F ; 1
eor CRC_L,temp_a ; 1 FCS_L = FCS_L XOR (temp_a >> 4)
; /17 CLOCK
ret ;/21 CLOCK

www.scenix.com
Application Note 16
February 15, 1999
SX IrDA Virtual Peripheral
Implementation

рекомендую,ссылки нет, есть документ:
Ross N. Williams
Элементарное руководство
по CRCалгоритмам
обнаружения ошибок
Все, что Вы хотели бы знать о CRCалгоритмах, но боялись спросить,
опасаясь, что ошибки Ваших знаний могут быть обнаружены
A painless guide to CRC error detection algorithms

Ross N. Williams

[vm1]

Основной критерий это как можно меньше слать байт и делать повторов
А так же простой алгоритм

Наиболее простой и достаточно надежный способ защиты
это контрольная сумма с паритетом в каждом байте.
Таким образом писали раньше на магнитную ленту.