Кольцевой буфер uart - Страница 3

code-by · 10.01.2011, 14:10

что такое квитирование и как передавать с помощью 9 бит? как его изменять?
кто-нибудь может помочь с протоколом для моего случая?

OlegNZH · 10.01.2011, 14:20

Квитирование- это подтверждение приёма данных(бывает аппаратное - и программное) 9 бит- в мегах заложен дополнительный бит, который можно использовать для идентификации- служебная посылка - или- данные.

code-by · 11.01.2011, 11:46

кто-ниб. может посоветовать протокол для моего случая?
и всё же отправлять числа как числа или переводить в ASCII?

nml · 11.01.2011, 12:18

Сообщение от code-by

Думаю, надо отравлять код начала передачи (например, 0xBE (begin), потом 15 чисел int, их значения будут от 99 до 1499, потом конец пакета 0xED (EnD).

Правильно заметили - сколько людей, чтолько и мнений, и стилей программирования.

В вашем случае (обмен между МК) я бы сделал так (у самого так работают десятки устройств)

Протокол передачи таков - пакет всегда начинается с маркера, ну скажем 0x55. Потом идет идентификатор - что передается (его может и не быть - если поток один). Потом собственно двоичные данные - на хрена паковать - распаковывать? Ну а надо на компе посмотреть для отладки - за полчаса пишется программа на дельфях. И в конце - обязательно - контрольная сумма.

И нет никакого кольцевого буфера, а прием ведется прямо в прерывании. Обработка проста - есть глобальная переменная - индекс. Так вот, исходно он == 0. При входе в прерывание приема - switch по этому индексу, и далее

если 0 - ждем маркер. принятое == маркер? если да, то индекс=1, иначе ничего.

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

Причем длина посылок м.б. разной - при приеме идентификатора (что за данные) мы определяем эту длину посылки.

makakus · 11.01.2011, 13:07

Правильно nml написал, сам хотел такое посоветовать, именно тоже "работают десятки устройств".

В общем-то протокол похож на modbus, на нём работают миллионы устройств

.

Переменная-счётчик байтов в посылке у меня изначально стоит в 0xFF. Дождался маркера начала пакета стало 0xFE. Принял счётчик байтов - равно счётчику. Дальше принимаем байты, вычитаем из счётчика пока он не стал равным нулю. Тут тормозим приём, main видит что 0, парсит пакет и устанавливает счётчик в 0xFF. Контрольная сумма - никакие не xor или сложения, а CRC8, не так уж долго она считается. У меня пакеты данных это команды, идут с интервалами, поэтому успевает обработаться одн, пока придёт следующий.
Пакеты могут теряться. Я циклически повторяю весь набор команд со старыми значениями, если юзерь ручки не дёргает и кнопки не нажимает: хоть не сразу, но потерянный пакет будет доставлен. При этом в канале есть постоянный поток, и если он прерывается на время более чем, значит, обрыв канала связи.

Да, не надо никаких 9 бит! 8-битный поток вы спокойно подслушаете через RS232 любой терминалкой и "подбросите" программкой на дельфях или вижуал бейсике написанной за 10 минут.

nml · 11.01.2011, 13:19

Сообщение от makakus

В общем-то протокол похож на modbus, на нём работают миллионы устройств

.

Ну да. Есть вещи, которые давно придуманы и особо "улучшить" или нельзя, или смысла нету

Цитата:

Переменная-счётчик байтов в посылке у меня изначально стоит в 0xFF.

Ну это уже детали реализации.
У меня для новых пультов придуман вообще расширяемый протокол, то есть пакеты "еще неизвестные" приемнику тоже будут "париниматься", в смысле не вызывать ошибки или сбоя потока данных - просто по ним ничего не будет выставлено. Там я длину пакета кодирую 2-мя битами в идентификаторе - 0, 1, 2 или 4 байта информации.

Цитата:

Я циклически повторяю весь набор команд со старыми значениями, если юзерь ручки не дёргает и кнопки не нажимает: хоть не сразу, но потерянный пакет будет доставлен. При этом в канале есть постоянный поток, и если он прерывается на время более чем, значит, обрыв канала связи.

Примерно так же и у меня. 0.5 сек нет приема пакета - загорается красный светодиодик. Только повторять весь набор не всегда возможно - например, если в пакете передается положение ручки - можно. А дискретную команду типа "сделать то-то" - нельзя.

Но это, опять же - тонкости. Главное - маркер, данные, контрсумма, и передавать данные в программу только при хорошей контрсумме.

yeroglyph · 11.01.2011, 16:37

Если передавать int прямо в виде бвухбайтных значений, то по крайней мере младший байт гарантированно будет временами = маркеру начала или конца. Оттого и нужно разворачивать это в 4 байта. Отправлять можно разбивая на тетрады и 1000 другими способами.
Одним из самых общепринятых вариантов - перевод в ASCII коды шестнадцатиричного представления числа. Это легко осуществляется элементарными операциями (не нагрузит МК как если возится с десятичными числами) и просто контролируется терминалом при отладке, как уже заметили товарищи. И размер пакета фиксирован, где расположено какое число - известно
Примеров - уйма, поиск рулит

yeroglyph · 11.01.2011, 16:57

Э. Парр. Программируемые контроллеры: руководство для инженера. 2007.
Со с.220.

makakus · 11.01.2011, 17:19

Сообщение от yeroglyph

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

Не страшно. Пакет состоит из идентификатора начала, счётчика=N, N байт двоичных данных, принимаемых без распознавания и байта CRC. При сбое будет принят пакет с неправильной контрольной суммой ( который может включить в себя несколько правильных пакетов) и отброшен. Дальше всё восстановится. Ну, есть ещё байт-стаффинг... Всё равно нельзя рассчитывать на канал без ошибок. И надо ограничивать длину пакета, при приёме пакета с аномальной длиной отбрасывать хвост текущего пакета.
Вариантов действительно масса, бес, как всегда, в деталях, у каждого своё.

code-by · 11.01.2011, 19:15

если маркер дублировать, например 0x55, то наверное нет необходимости переводить числа в ascii