[Serega Doc 0]

Пересылка данных между мастером и слейвом (На 64 MEGE) - мультипроцессорный обмен

В основном long числа

Как проверить правильность передачи.

1 вариант (сложный)

Можно использовать встроенний контрольчетности

Но тогда если не правильная посылка то необходимо повторять только один байт и еще и делать анализ какой байт из 4 принят.

2 вариант (IMHO проще 1-го)

Может быть лучше пятым байтом досылать еще и по XOR сложенные 4 байта long числа

И в следующем сеансе связи просить повтор того что передалось не правильно

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

[Виктория 0]

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

 

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

[visht 0]

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

Да почему много ? табличный СRС8 (выложен в прикрепленной теме) дает довольно быстрый результат.

что касается объёма то для 64к наверное найдеться место...

для 4-х long наверное лучьше подойдет CRC16...

В крайнем случае можно считать CRC для каждого байта перед отправкой, или при приеме.

[Serega Doc 0]

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

А так же простой алгоритм

[Petka 0]

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

Изменено 9 января, 2006 пользователем Petka

[Serega Doc 0]

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

 

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

[Volodymyr 0]

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

[Petka 0]

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

 

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

 

1) сформулировать критерий надёжности.

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

3) смоделировать работу мат. модели.

4) получить надёжность.

 

выбор 1 пункта должны сделать вы и только вы. напимер, для одних задач похождение 50% пакетов это надёжно, для других и прохождение 99,999% пакетов ненадёжно. Если у вас будет протокол с пересылкой плохо переданных даных, то в надёжность будет ещё входить и время прохождения пакета, с учётом вероятной пересылки его... и в том же духе.

2 пункт вы будете строить из статистических данных линии передачи, т.е. вероятность помехи, её длительность, отсюда выводится вероятность помехи в 2х битах.... и.т.д. т.е. большая работа.

3 пункт можете реализовать чисто математически. или же моделированием на компьютере "в лоб " с составлением последующей статистики.

4 пункт совсем элементарен. полученные цифры сверяете с пунктом 1! И только после этого вы сможете понять НАДЁЖНО ЛИ ВАШЕ устройство в заданных условиях.

 

 

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

Изменено 9 января, 2006 пользователем Petka

[*SERG 0]

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

Изменено 9 января, 2006 пользователем *SERG

[defunct 0]

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

 

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

 

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

[Laptop 0]

Для контроля правильности посылки вполне хватит CRC8. Не так уж и долго при табличном методе.

А вот протокол передачи будет сильно зависить от системы в которой все это будет крутится, необходимо как-то идентифицировать начало пакета. Это может быть как вариант с взведенным 9-м битом, так и более сложный вариант с анализом пауз передачи между пакетами или вариант с XON-XOFF.

В твоем случае нужно указать какие именно данные будешь передавать и уже тогда придумывать протокол. Ты ведь указал что у тебя В ОСНОВНОМ лонги. А что еще передается? Может необходимо указывать тип передаваемых данных?

Имхо, в твоем случае видимо проще передавать первый байт с девятым битом для указания длины пакета, затем сам пакет и crc.

Дополнительно конечно необходимо смотреть все ошибки в регистре статуса уарта.

[haker_fox 60]

2Serega Doc: может Вам это подойдет

http://www.spetspribor.com/support/software/wake/wake.html

применил этот протокол для связи IBM PC с девайсом на mega16, остался доволен.

Хотя в вашем случае наверно можно обойтись меньшими затратами...

Но за основу вполне этот протокол можно взять.

[Gennadiy_ 0]

Позаимствуй протокол из стандарта 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 0]

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

А так же простой алгоритм

 

Наиболее простой и достаточно надежный способ защиты

это контрольная сумма с паритетом в каждом байте.

Таким образом писали раньше на магнитную ленту.