Подскажите алгоритм проверки целостности данных

[Churchill]

Хочу сделать простейший считыватель i2c еепром через юсб на 2 мегах8 (одна - преобразователь юсб в ком, вторая - сам считыватель). Почеум так - не спрашивайте - надо ))))
Каким образом проверить правильность передаваемых данных? Данные хочу передавать непрерываемым потоком, без блоков, а посему расчет контрольного кода должен производиться на лету и в конце передачи передаваться в комп. Простого суммирования всех переаднных данных хватит?

[mrKirill]

Непрерывно откуда куда? От источника сигнала до компьютера?
Если у Вас непрерывный поток, то где же у него конец, к которому прикреплять контрольный байт?
Помните Масяню и ее "только не дисконект!"?
Чтобы такого не было принимайте пакет информации (он все равно имеет конечное значение), держите его в буфере, считайте CRC и дальше передавайте на ПК. ИМХО вроде так логичнее.

PS. "Простейший считыватель i2c" и 2шт ATMega8 как-то уж явно не стыкуется...

[ua_gruzin]

Ну да.
Посмотрим на вопрос поближе.
- для чего контроль за целосностью информации если вы не сможете определить что надо передавать при ошибке, ведь поток будет непрырывный. Прийдется передавать всю информацию заново при возникновении ошибки.
Решение: необходимое блокирование (образование блоков) информации и подальшая их нумерация.
- размер блока должен быть сопоставим с оптимальностью. Его длина должна быть оптимальной в соотношени количества информации, размера номерующего блока, и размера проверочных символов.
Решение: искать коды для обнаружение ошибок основываясь на ваше железо (в основном на разрядность системы) и на готовые оптимальные коды (искать в инете).
- обнаружение ошибок не приведет никогда к непририрывному потоку... ибо для перезапроса надо остановит основной поток.
Решение: брать за основу коды с сисправлением ошибок. Для примера код Рида-Соломона. Ибо он похож на оптимальный и в нем описаны все алгоритмы.

Одним словом - юзай код Рида-Соломона, НО!
Обрати внимание, что для его реализации необходимо очень много вычеслительных ресурсов. НО! Для реализации на PLC вопросов совсем нету, все работает на очень больших скоростях (до 10Мбит), ибо в даном случае все сделано на логике.
Есть правда готовые кодеры Рида-Соломона. Но, я их на базаре не встречал.
Там реализована ситуация след образом.
Береш кусок информации (будуший блок), пишеш в память. Дальше тупо ищеш по таблицах проверочные коды в соответствии к твоей кодовой комдинации (блока). Дальше посылаеш блок+проверочную комдинацию...

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

[ua_gruzin]

Да и, классная идея посетила.
Можно и так.
Принял код (блок), бальше выбросил его на адрессную шину ПЗУ. Данный адрес и укажет на ячейку в которой хранится проверочная комбинация. Дальше просто сичтал с памяти (она сама вывалит на шину данных) проверочную комбиначию, и записал ее в конец после того как вывалил а УАРТ код (блок). Блок можно отправить напрямую в УАРТ например перед тем, как чтото с ним делать (с блоком). Пока он ьудет обрабатыватся УАРТом, ты сможешь все сделать с памятю.
О, P.S. Знакомый делал подобную цацу на дисертацию.

[mrKirill]

Не думаю что для "простого считывателя i2c eeprom" нужно заморачиваться с кодом Рида-Соломона.

Насколько я понял контроль правильности потока нужно проверять на участке МК-ПК? Если так, то проще организовать буфер, далее кусковать на пакеты, а для контроля ошибки хватит простого CRC.

[Churchill]

По поводу простоты - у нас дешевле мег8 ничего не возят - 2 бакса - небольшие расходы.
По поводу непрерывности - "прерывность" конечно есть, еепром память больше 64КБ мне не встречалась. Просто не хотел заморачиваться с блочно структурой. Меня вполне бы устроил вариант, что считали 64К с ошибкой - передаем заново. Это типа считывателя логов, которые считываются раз в месяц. Ну и естественно, такой массив данных ни в РАМ не поместить, ни в FIFO UART не запихнуть.
Вопрос поконткретнее - есть способ подсчета CRC "на лету"?

[mrKirill]

Считали 64К информации одним куском, посчитали CRC, бац ошибка. А так как CRC только указывает на ошибку, а не исправляет ее - снова читать весь пакет, все 64К. И так до бесконечности...
Вам никто не говорит что нужно весь пакет загонять в буфер. Примите, к примеру, 512 байт, в то время пока будете принимать следующие 512 обработайте эти. Начинаете обрабатывать следующий пакет - выдавайте в порт обработанные байты и принимайте следующие.

[ua_gruzin]

Не и...пи одно место.
Все доводы изложены выше.
Я конкретно описал что и к чему.
Нада считать без ошибки - пожалуйста. Внешняя память + прога для ее заливки (для кода рида-соломона). Исправлять же ошибки будет комп, в него ресурсов хватит .

НО! СРС не даст тебе увереность об ошибке, так как несколько приведет к его неработоспособности.
По другому - читай несколько раз еепром и дальше просто сравнивай их между собой. при совпадении - получиш правильную комбинацию, ибо вероятность ошибки на одном и том же месте при 64кбайтах ОЧЕНЬ МАЛА. НО! Такой подход будет реален при длене кабеля от устройства не более метра и то в экране.

Если данный подход не катит - только ставка на коды, которые исправляют ошибки.

Да и... все можна сделать на одной меге без памяти внешней. Для 8-ми битного пакета нада 256 проверочных символов, аналогично для 10-ти битного нада 1024 ячейки с проверочными символами.

Дальше так:
Обьявляеш масив на 1024 элемента в флеше в конце (так как стандартную строку). Получиш таблицу со смещением. Дальше напрямую делаеш обращение к флеше по заданому адрессу (твоя кодовая комбинация длиной в 10бит) и чтиш одтуда твои проверочние биты.
А дальше все просто.
Пакет типа:
вервый байт: идентификатор+6 первых бит с 10-ти
второй байт: 4 бита что оталось + проверочную комбинацию.
Эти два байта по очереди в топку (в уарт).

Идентификатор необходим для синхронизации, и имеет 2 бита, например 00 или 11, как будет угодно, для определения начала двойки байт (или другими словами - для начала пакета).

P.S. Сделай раз да не будет дальше никаких проблем.