Перейти к содержанию
    

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

1. Отправляем 7 заранее определенных байт (что-то типа пароля);

2. Отправляем 2 нужных байта (собственно, сам пакет);

3. Отправляем еще 7 заранее определенных байт (вторая часть пароля).

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Если предположить, что вероятность искажения бита постоянна и не зависит от его местоположения в пакете...

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

 

Чем длинне пакет, тем выше вероятность что в нём будет хотя бы одна ошибка.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

 

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

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

 

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

1. Программирование на ассемблере;

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

 

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

Спасибо всем за помощь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...