Обработка команд по UART Опции

[d7d1cd]

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

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

[_Артём_]

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

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

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

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

[d7d1cd]

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

[_Артём_]

Для этого и существует контрольная сумма: чтобы понять, правильно принята вся команда или нет. Еще: в протоколе обмена написано "Критерием окончания передачи команды является гарантированный таймаут. Для скорости 9600 бит/сек он равен примерно 5 мс.

Код

void StartTimeouTimer()
{
//.....
}

void RxCompleteIsr()
{
    RxBuffer[RxIndex++]=ReadNewByte();
    StartTimeouTimer();
}

volatile unsigned char PacketTimeot;
void PacketTimeoutIsr()
{
    PacketTimeot=1;
    DisableTimeoutTimer();
}

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

[demiurg_spb]

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

[d7d1cd]

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

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

[_Артём_]

как эту задержку на 5 мс реализовать программно.

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

[d7d1cd]

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

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

[demiurg_spb]

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

[_Артём_]

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

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

Код

void StartTimeouTimer()
{
//.....
}

#define BUF_LENGTH 100
unsigned char RxBuffer[BUF_LENGTH];
volatile unsigned char RxIndex;
void RxCompleteIsr()
{
    RxBuffer[RxIndex++]=ReadNewByte(); // чтение принятого байта в буфер
    StartTimeouTimer();// запуск таймаута 5 мс
}

volatile unsigned char PacketTimeot;
void PacketTimeoutIsr()
{
    PacketTimeot=1; // пакет принят
    DisableTimeoutTimer();// запрет прерываний от таймаута
}


void main ()
{
    // настройка uart-а для приёма на нужной скорости и с разрешением прерываний по приёму
    InitUart();

    while (1) {
        if (PacketTimeot) {
            PacketTimeot=0;
            // пакет принят
            // проверка и тд
        }
        // другие нужные действия


    }
}

[d7d1cd]

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

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

[demiurg_spb]

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

[d7d1cd]

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

Код

void StartTimeouTimer()
{
//????????????????????????????????????????????????
}

Сообщение отредактировал d7d1cd - Aug 21 2012, 17:33

[_Артём_]

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

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

[d7d1cd]

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

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

[_Артём_]

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

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

[vasta]

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

[hash20]

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

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

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

[vasta]

Только вот со стабильностью частоты жопа начинается....

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

[d7d1cd]

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

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

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

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

[SSerge]

Думаю, что при таком способе, вероятность ошибочной передачи 2-х байт ничтожно мала. Да и "ждать" ничего не надо...

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

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

[hash20]

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

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

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

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

[_Артём_]

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

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

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

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

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

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

[d7d1cd]

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

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

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

[d7d1cd]

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