Привет всем. Помогите с реализацией приема по UART. По прерыванию я заполняю буфер приема байтами. В конце приема будет 2 байта контрольной суммы. Вопрос в том, как определить, что по UART полностью передана вся команда. Все команды будут разной длины.

Подскажите как решается подобная проблема.

Нужно определить длину команды (по заголовку например) и затем принять нужное число байт. Потом сверить сумму.


Хорошо бы знать формат команды.

Я анализирую протокол обмена прибора, чтобы сделать что-то свое. Там первый байт всегда сетевой адрес, следующий - номер команды, далее - параметры команды (которые могут иметь различную длину или могут вообще отсутствовать), последние 2 байта - контрольная сумма, вычисленная по всем байтам команды.
Сетевой адрес не может нести информацию о длине команды. Кроме того, вдруг во время передачи какой-то байт передастся неправильно, тогда ожидаемое число байт может быть определено неправильно. Для этого и существует контрольная сумма: чтобы понять, правильно принята вся команда или нет. Еще: в протоколе обмена написано "Критерием окончания передачи команды является гарантированный таймаут. Для скорости 9600 бит/сек он равен примерно 5 мс.

То есть в прерывании RxCompleteIsr запускается таймер на 5 мс. Если произошло прерывание PacketTimeoutIsr - значит пакет принят и осталось проверить его сумму.

Своё изобретать ИМХО последнее дело.
Есть сотни уже придуманных до Вас протоколов, а некоторые из них являются чуть-ли не стандартами де-факто в некоторых отраслях, как например MODBUS в некоторых промышленных системах.

Имеено MODBUS и подразумевает таймаут в конце передачи пакета. Мне интересно как эту задержку на 5 мс реализовать программно.

Не нужно её пытаться программно организовывать - у вас МК будет 5 мс NOP-ы исполнять? А если 500 мс потребуется?

Тогда как "подождать" 5 мс?

таймером:-)
Ну или можно передать 4 байта в уарт с отключенным передатчиком драйвера RS485, если такой имеется.

Ну я ж привёл пример 2-3 поcтами выше...

Как это можно сделать таймером?

Артём Вам рассказал уже об этом.

Понятно, что надо запустить функцию StartTimeouTimer(). А ее реализацию можно привести?

Нет, пока нельзя: вы же не привели тип МК и источник и частоту тактирования.
Приведёте, может кто и подскажет.
Хотя что там сложного: запустить тактирование и разрешить прерывание по совпадению или переполнению.

МК MSP430F149, тактирование от внешнего кварца частотой 8 МГц.

Спросите в гугле: семейство микроконтроллеров msp430x1xx. руководство пользователя

ТАм какой-то регистр есть CCR или типа того, ставите в нем сколько надо и разрешаете прерывание - вот вам и 5мс. Правда непонятно, зачем вам внешние 8МГц, там же внутренний кварц такого порядка. Обычно снаружи вешают 32к, как раз чтобы не заморачиваться с милисекундами

Только вот со стабильностью частоты жопа начинается... Например я обычно ставлю кварц 7.3728 MHz . Удобно задавать скорость UART.

А вот зачем ему 5мс загадка.... там всё можно по другому сделать... я ему в личку отписал с примерами, думаю разберется..

Ну, жопа периодически перекалибровывается, так что не проблема)

Я тут подумал какие команды мне надо будет отправлять. Получилось, что максимальная длина пакета - 2 байта. Что если отправку организовать так:

1. Отправляем 7 заранее определенных байт (что-то типа пароля);
2. Отправляем 2 нужных байта (собственно, сам пакет);
3. Отправляем еще 7 заранее определенных байт (вторая часть пароля).

Программа МК сравнивает приходящие байты (кроме 8 и 9 байта. Их она сохраняет в ОЗУ) с паролем во флеш. Если все байты пароля совпадают, то начинает "разбираться", какая команда пришла (те самые 2 нужных байта).
Думаю, что при таком способе, вероятность ошибочной передачи 2-х байт ничтожно мала. Да и "ждать" ничего не надо...

Прокомментируйте, пожалуйста.

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

Чем длинне пакет, тем выше вероятность что в нём будет хотя бы одна ошибка.
Если лень считать 16-битную CRC для пакета, то подсчитывайте просто сумму всех байт пакета в 16-битной переменной и добавляйте в хвост пакета эти два байта контрольной суммы, или хотя бы один (младший) байт. По крайней мере обнаружите на приёме одиночные и практически все двойные ошибки, а бОльшего и не надо, при нормальном канале.

самый оптимальный вариант [2 старт байта] - [пакет] - [сrc] - [2 стоп байта]

d7d1cd я же тебе в личку почти готовый проект скинул, зачем велосипед изобретаеш (да ещё и 3ех колесный)

нахрена пароль гонять в каждом пакете, если в серъезных проектах - то такой пароль взломается за несколько десятков засниференных пакетов...

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

Самый-не самый оптимальный, на всяко гораздо лучше чем, то что d7d1cd описал.



Так его зашифровать можно.


Где-то так конечно, но трёхколёсный велосипед устойчивей гораздо, чем наши несамоизобретённые двухколёсные (для d7d1cd конечно).

Спасибо, господа, за комментарии. Просто у меня есть несколько непреодолимых сил, которые мне диктуют условия. Некоторые из них:

1. Программирование на ассемблере;
2. Катастрофический недостаток свободной памяти для программы (ведь кроме приема пакета необходимо делать много других действий);

На счет контрольной суммы: скорее всего реализую ее проверку. Пароль никто узнать не сможет, так как с помощью него "общаться" буду только я. Да и для каждого прибора пароль будет разный.
Спасибо всем за помощь.

Реализовал так: отправляю 8 байт пароля, потом 2 байта информации, потом 2 байта контрольной суммы. Команды всегда одной длины (12 байт). При каждом прерывании происходит поэтапная проверка пришедшей команды в буфере. В общем, все работает как надо!