AVR, МС памяти и ПК

slavokhire5

Доброго времени суток ) понадобилось прикрутить платку с авр к компьютеру.
суть работы: устройство с автономным питанием. авр что-то там себе считает и регулярно пишет результаты в мс памяти (1МБит) через I2C. Через некоторые промежутки времени есть необходимость считывать с ПК данные мс. планируется делать это через com-port с дальнейшим переходом на радиомодуль. интересует вопрос качественной передачи информации (контрольная сумма, проверка четности и т.д.) при минимальных затратах энергии )
если возможно, посоветуйте пожалуйста какую-нибудь библиотеку на Си для микроконтроллера (в идеале и ее аналог на делфи), чтобы не писать велосипед самому )

Реклама

O_l_e_g

[quote="slavokhire5"]Про дельфи вообще не слышал для микроконтроллеров, хотя возможно паскаль и существует. Но если вы не собираетесь использовать математическую библиотеку алгоритмов а просто работать с ком портом то тут ничего сложного нет и СИ тут ничего не ускорит. Хотите отправить байт записали его в регистр. Когда байт контроллер принял устанавливается специальный флаг и вам только требуется считать байт. Сам ком порт фактически не предусматривает никаких стандартов относительно протоколов, или фактически эти стандарты трактуются весьма вольно. Не предусматривается также никакой процедуры синхронизации скоростей приемника и передатчика, числа стоповых битов размера слова четности и тд. Поэтому все в ваших руках. И стандартные библиотеки тут вам мало помогут. Как напишите так и будет. Можно еще порыться в примерах производителя микроконтроллеров. С радио модулем будьте осторожны. Ком порт обеспечивает интерфейс точка точка, для работы в сети он не проектировался. Так что тут потребуются некоторые усилия если вы хотите использовать связь компьютера по ком порту с несколькими устройствами.

Реклама

slavokhire5

делфи мне для компьютерной части ) окна, кнопки и т.д. написаны, обмен по виртуальному кому веду.
а библиотеки хотелось бы для подсчета контрольной суммы сообщений. буду передавать большие объемы данных, какие будут условия - не знаю) нужна помехозащищенность.
Видел в WinAVR библиотеку на CRC16, попытался почитать по ней хелп, но не приуспел) математик из меня хреновый. или мб устал)

makser

slavokhire5 писал(а):делфи мне для компьютерной части ) окна, кнопки и т.д. написаны, обмен по виртуальному кому веду.
а библиотеки хотелось бы для подсчета контрольной суммы сообщений. буду передавать большие объемы данных, какие будут условия - не знаю) нужна помехозащищенность.
Видел в WinAVR библиотеку на CRC16, попытался почитать по ней хелп, но не приуспел) математик из меня хреновый. или мб устал)

Прошивка будет не сложной, по этому думаю стоит обратить внимание на http://www.mikroe.com/ там и паскаль есть и библиотеки к нему. например Манчестер.
Можно даже выбрать микроконтроллер. т.к. языки и библиотеки идентичны. А библиотеки математики можно найти в инете, они могут даже без переделки быть использованы в прошивке.

Реклама

orinoko

Этих расчётов CRC16 в инете вместе с реализацией - тьма. Найдите описание протокола MODBUS - там есть всё. Я бы дал расчёт, но он у меня на АСМе (для МК) и табличный. А на Дельфях он простой.

Реклама

O_l_e_g

[quote="slavokhire5"]Циклические суммы конечно обеспечивают высокую помехозащищенность. Но их вычисление для контроллера -- не маленькая гиря. Я бы вам посоветовал если предполагаются существенные помехи в первую очередь сосредоточиться на размере пакета. Чем меньше размер тем выше защищенность. Ограничьте размер 8 .. 32 байта. Подумайте над квитированием успешно принятой посылки. Неплохо было бы если в посылке будет поле адреса в самом простейшем случае это может быть бит четная или не четная посылка, но лучше чтобы было бы хотя бы 3..4 бита. Это обеспечит защиту от потери пакета. Хотя если на каждый переданный пакет устройство будет ожидать кватирования или ошибки то может это поле и не нужно. Выберите также тайм аут сколько вообще устройство будет ждать ответа пока не поймет что его так и не будет. Для установления связи можете создать специальные синхронизирующие пакеты. Не забывайте для надежной связи устройство должно уметь понять что данные приняты и обработаны, если они действительно важны. Может получиться так что комп принимал принимал пакеты квитировал пакеты и после того как было передано к примеру 80% компьютер свалился, синий экран, перезагрузка. И что делать, как восстановить данные. Устройство может после успешной передачи пакета также успешно удаляло его из своей памяти. так что принять без ошибки это не все, надо еще чтобы комп сообщил что данные сохранены и их можно удалить. Возможно это надо делать не для каждого пакета а для блока пакетов например размером 4кБайт. Не забывайте некоторые данные без меток времени бесполезны. А часы имееют свойство идти по разному. Неплохо было бы если бы на компе все пакеты имели сквозную нумерацию, а время было бы вспомогательно, это оградит вас от ошибок когда на компе было неправильно изменено время. Что же касается контроля правильности передачи то думаю любой код позволяющий зафиксировать двойную ошибку вполне достаточен (по крайне мере для пакетов до 8 байт и наличия бита четная и нечетная передача)

Реклама

orinoko

Но их вычисление для контроллера -- не маленькая гиря

Тут разрешите мне не согласиться. Конечно, если например, размер пакета большой и вычислять CRC сразу всего пакета, то да, довольно затратно. Но и то, это понятие относительное. Но никто не запрещает вести расчёт по мере передачи побайтно. И в конце дослать 2 байта. Можно использовать табличный метод (занимает, правда, две таблицы по 256 байт и 56 команд). Кстати есть вполне конкретные цифры - МК ATmega кварц 11 МГц, скорость линии 115200, пакет 1 кбайт, при расчёте сразу скорость передачи была в ~1,5 раза ниже.

slavokhire5

to O_l_e_g

прошу прощения за свою безграмотность, но что такое "квитирование" в данном случае? ) какие-то ответные посылки?

вообще планируемый формат посылок такой:
1) стартовый байт (внимание, сейчас начинается передача)
2) количество байт в посылке
3) байт команды (чтобы устройство могло понять, куда именно эти данные пихать)
4) N байт "полезных" данных
5) контрольная сумма
6) стоповый байт

в КС входят пункты 2-4, количество байт - пункты 3-5.

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

насколько это удачная "конструкция"? )

мб это важно: com буду использовать обрезанный: только RxD, TxD и GND

ILYAUL

Нормальный. Samsung так с телевизорами работает. Только стоповый не нужен , у Вас и так известно количество байт которые нужно принять

slavokhire5

я подумал, если в порт будет какой-то мусор наводиться и случайно совпадет со значением стартового байта, стоповый байт нам даст возможность сразу определить что посылка ошибочная, без всяких КС (не пинайте сильно, я и теоретик хреновый, а о практике можно и не говорить)

orinoko

Насколько я понимаю, будет использовать "запрос-ответ".
Тогда запрос - Команда, Параметры (начальный адрес, количество байт), CRC (пакета без CRC). Взводим таймер таймаута
Ответ - Команда, Данные (в соответствии с параметрами), CRC (пакета без CRC). По мере поступления блоков байт (в программу данные идут не побайтно, а блоками, как ни крути) расчёт CRC, как обнулился, считаем, что пакет принят. Обрабатываем.
По таймауту повтор запроса или аварийные мероприятия.

slavokhire5

спасибо. с обработкой CRC по ходу поступления, пожалуй, будет быстрее работать =)

ILYAUL

Самый простой метод подсчёта CRC и самый "дешёвый" , зато самый быстрый - тупое суммирование всех полученных байтов , сумма должна совпасть с последним полученным байтом (CRC) , где он или младший или старший байт суммы.

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

а если он совпадёт со стоповым байтом. Основная проверка в посылке CRC, так чтобы костюмчик сидел. Не совпал Ваш подсчёт CRC с полученным - пипец , посылка выбрасывается. Ну и схемные меры защиты от муссора тоже бы надо предусмотреть

orinoko

Так в том и особенность CRC (настояще-посчитанного) - что если рассчитать CRC всего пакета (вместе с CRC), то получается ноль. Как было сделано у меня
1. Со стороны контроллера.
Включён приёмник. инициализация CRC.
пришёл байт.
обновили CRC. взводим таймер на ~ на время прохождения 3-5 байт. Если пришёл новый байт, добавляем в приёмный буфер, инкремент счётчика байт, повторяем (эту строчку).
Если колич. байт стало больше допустимого, то пакет игнорируется, инициализация приёма, начинаем сначала.
Возник таймаут - смотрим, что у нас с CRC. Если ноль, производятся доп. проверки (мин. длина пакета, адрес устройства), сообщаем в основной цикл, что пришёл новый пакет - обработать надо. Если не срослось, пакет отбрасывается, инициализация приёма (счётчик байт, CRC). Опять ждёмс...

Если нужно, напишу со стороны ПК, там похоже, но немного иначе, всё же ресурсов больше

.

Alkul

ILYAUL писал(а):Самый простой метод подсчёта CRC и самый "дешёвый" , зато самый быстрый - тупое суммирование всех полученных байтов

"Тупое суммирование" даст именно контрольную сумму, а не Cyclic Redundancy Code (циклический избыточный код).
для пакета 0х01, 0x02, 0x03, 0x02 и для пакета 0x02, 0x02, 0x03, 0x01 "тупой подсчет" даст одинаковое значение 0x08. А всего лишь две однократные ошибки!

O_l_e_g

orinoko писал(а):.

Вы ошибаетесь CRC сумма вычисляется путем ДЕЛЕНИЯ всего пакета на специальный полином например x**16 + x**5 + x**2 + 1 (где ** это возведение в степень) Причем важно что весь пакет рассматривается как единое число Например если пакет представляет собой 8 байт то это будет 64 разрядное битовое число. Остаток от деления это и есть CRC контрольная сумма. Полиномы могут быть разные. От выбора полинома существенным образом зависит точность защиты. Все остальные алгоритмы это есть другие алгоритмы (в том числе и всевозможные суммирования) и никакого отношения НИ к CRC контролю они не имеют НИ к той высокой степени контроля ошибок, который обеспечивает CRC. Недостаток этого метода огромное количество вычислений, которое необходимо произвести. Поэтому на практике используются микросхемы аппаратно вычисляющие CRC коды. Попробуйте ка разделить 8192 битовое число на 16р полином. А это ведь всего пакет размером 1кБайт. Не всем контроллерам это под силу. В данной задаче самым оптимальным будет использовать какую либо разновидность контроля четности -- и ориентироваться на пакеты небольшой длинны. В настройках ком порта отключить буферизанию данных и xon/xoff управление потоком. При необходимости это довольно легко можно будет организовать самому.

orinoko

Я знаю, что такое CRC. И что он собой представляет. Есть вполне конкретные методики расчёта. Например, можно посмотреть об этом в спецификации на протокол MODBUS (CRC-16), или в ДШ на DS18x20 (CRC-8). И варианты есть - и чисто программные, где производится побитный сдвиг каждого байта в пакете с накладыванием полинома, и с помощью заранее подготовленных таблиц и соответствующей методики. Первый вариант занимает меньше памяти, то более затратный по времени (но вполне подъёмный для МК), второй больше памяти и более быстрый.
Так вот, у CRC есть одно интересное свойство, вытекающее из математики расчёта - это т.н. эффект "самоуничтожения". На всякий случай повторюсь: Есть пакет данных "DDDDD", посчитали его CRC-16 "CC". Если посчитать CRC-16 пакета "DDDDDCC", то получим ноль. Об этом я и поведал, не вдаваясь в подробности. А рассчитывать CRC-16 вполне по силам 8-битному контроллеру. И формировать CRC не обязательно всего пакета сразу, а побайтно по мере приёма (отсылки). При этом нагрузка на МК размазывается по времени и никому не мешает.

Попробуйте ка разделить 8192 битовое число на 16р полином

А зачем делить всё и сразу? Кто мешает по правилам арифметики делить побайтно? А про сумму говорил товарищ ILYAUL, ему объяснили, где он заблуждается и вопрос закрыли.
Конечно, если требуется скорость обмена мегабайты в секунду, то нужны какие-то аппаратные добавки. Но, согласитесь, это не тот случай.

Jack_A

orinoko писал(а): эффект "самоуничтожения". На всякий случай повторюсь: Есть пакет данных "DDDDD", посчитали его CRC-16 "CC". Если посчитать CRC-16 пакета "DDDDDCC", то получим ноль.

Лет 10 уже использую CRC, потому хотел броситься в атаку : путаете Вы, товарисч, это для прстого суммирования катит или для XOR, а не... Попробовал - убедился. Действительно, блин, оно работает! Вот век живи -- и приблизительно столько же учись

Только у меня CRC записывался младшим байтом вперед, потому "в лоб" такой вариант не журчал бы, но поскольку и на компе, и в МК я считал CRC одинаково, то никакого "раздвоения личности" не происходило.
Мой работодатель, очень ученый д`оцент, мне указывал : у нас настолько надежная линия связи, что никаких CRC не нужно ! Я с учеными никогда не спорю. Выматерился про себя и сделал как положено - с CRC .

А вычисляю таблично. Памяти хватало, а быстродействие намного лучше.

slavokhire5

немного подзабил на CRC) занимаюсь я контроллерами на работе в свободное время) а сейчас его стало меньше.

решил использовать табличный расчет. алгоритм буду брать отсюда: www.piclist.ru/S-CRC16-RUS/CRC16.html
в CRC разбирался по статье Ross N. Williams "Элементарное руководство по CRCалгоритмам обнаружения ошибок". Неплохая книженция

orinoko

Вот предлагаю в пользование всем желающим модуль для расчёта CRC16 по стандарту MODBUS табличным методом. На асме для AVR (извините, если кому не угодил).