Страница 2 из 2
Re: AVR, МС памяти и ПК
Добавлено: Чт июн 07, 2012 16:45:20
ILYAUL
Кто мешает по правилам арифметики делить побайтно?
Я думаю , что никто не мешает и главное быстро.
Код: Выделить всё
InitCRC8:
movi CRC8,0xFF
ldi temp1,0x31 // полином
ret
;*
;-
CalcCRC8:
eor CRC8,temp
ldi count,8
CRC_Loop:
lsl CRC8
brcc crc_Skip
eor CRC8,temp1
crc_Skip:
dec count
brne CRC_Loop
ret
;*
;-
Re: AVR, МС памяти и ПК
Добавлено: Чт июн 07, 2012 17:00:19
Ser60
Если нужно быстро вычислять CRC, почему-бы не применить МК со встроенным CRC модулем?
Re: AVR, МС памяти и ПК
Добавлено: Пт июн 08, 2012 09:58:51
slavokhire5
Ser60 писал(а):Если нужно быстро вычислять CRC, почему-бы не применить МК со встроенным CRC модулем?
незнание об их существовании

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

, в ближайшее время хочу попробовать MSP)
Re: AVR, МС памяти и ПК
Добавлено: Пт июн 08, 2012 17:15:21
shads
Кстати, хоть я и не съел собаки по данной теме, но все равно, не советовал бы, применять UART в радио передаче. Тут нужны более стойкие протоколы, как например манчестер (фазовая модуляция). В этом протоколе синхронизируется каждый бит, легче поймать заголовок передачи (если эфир зашумлен), и еще много плюсов по сравнению с UART.
Организовать этот протокол нужно будет конечно программно.
Re: AVR, МС памяти и ПК
Добавлено: Пт июн 08, 2012 18:44:13
Ser60
slavokhire5 писал(а): в ближайшее время хочу попробовать MSP
Очень правильный подход. После этого к AVR Вы не вернетесь никогда. Аппаратный CRC модуль имеется, например, в MSP30F5xxx микроконтроллерах, или Силабовских C801Fxxx. В обоих, конечно, и аппаратный UART имеется, и не один.
Re: AVR, МС памяти и ПК
Добавлено: Сб июн 09, 2012 17:53:40
O_l_e_g
CRC кодирование обладает как минимум 2 изюминками. Во первых Код позволяет полностью заменить весь пакет на любой произвольный, и если правильно подобрать 2 последних (в зависимости от длинны полинома) байта, ни один декодер никогда не распознает что была подмена. Во вторых я не слышал чтобы эти коды использовались для испраления ошибок.
Если посмотреть на рисунок то видно что информационная последовательность помещается в трехмерный массив, каждая ячейка которого может хранить 1 бит. Красные ячейки -- информационные, зеленые дополнение до четности строки(столбца). Последний слой (не показан) содержит только биты четности для однотипных ячеек всех слоев. При помещении в таблицу элементы располагаются так чтобы быстрее всего изменялся первый индекс массива, а медленнее всего -- последний индекс. При извлечении данных для передачи данные извлекаются таким образом чтобы быстрее всего изменялся самый последний индекс и медленнее всего самый первый. Разумеется в декодере биты в массив помещаются в обратном порядке.
Данный код не только может исправить ошибки при передаче, он позволяет восстановить данные даже в случае пропадания(повреждения) нескольких битов идущих подряд (при 8 слоях) данный код легко справиться с восстановлением целого байта который был потерян
И хотя размер посылки увеличивается (при размерности 8.8.

коэф использования 0,67. Но представьте если сбои бита идут чаще чем время передачи вашей посылки. Замирания, отражения, таксисты со своими рациями, мед кабинеты ... В этом случае CRC код просто приведет к тому что связь БУДЕТ ПОТЕРЯНА. И в самом деле каждая посылка будет содержать 1..2 ошибки и вы никогда не сможете успешно передать ни один пакет. Борьба с этим только в использовании кодов позволяющих исправлять ошибки. А тот пример который привел я относиться к классу турбо кодирования и позволяет бороться с идущими подряд ошибками, что очень актуально при условиях повышенного уровня помех.