Talk:Ru-Devices Communication Network Protocol

Команда не поддерживается

Моя предлагать ввести код ответа "ошибка" пример - "команда не поддерживается" - например, 0x80. Дополнительные сведения об ошибке путь идут вместе с ответом. Swinemaker 09:10, 12 August 2012 (EEST)

Ок. Можем сделать, есть несколько вариантов:

• • Варианты в стиле костылей:
• Вариант №1: Известно, что команда ответа состоит из оригинального кода и выставленного страршего (седьмого) бита. В коде ответа неподдерживаемой команды предлагаю выставлять дополнительно еще и 6-й бит в единицу - это будет значить, что команда не может быть отработана сервером (устройством). Недостаток - уменьшает количество поддерживаемых команд до 64-х.
• Вариант №2: Известно, что нам не нужны большие длинны байтов в ответе. 255 байт ответа - это уже чересчур. Предлагаю выставлять длинну пакета ответа в 255 - это значит, что команда не поддерживается. Клиент проверяет, не вернули ли длинну равную 255 и в этом случае понимает, что команда не поддерживается. Все остальные длинны считает правильными. Этот вариант не позволяет выдать строку-ошибку в дополнительных данных пакета ("объяснение почему не поддерживается команда").
• Изменить двухбайтную сигнатуру заголовка пакета ответа для неподдерживаемой команды на другую. Этот вариант плохой, т.к. сигнатура нам нужна для синхронизации.
• Просто отвечать 0x80 в коде команды - плохо, т.к. команды могут поступать асинхронно, и не будет понятно, на какую команду дается ответ с кодом 0x80 (не поддерживается).

• • Варианты с хорошим подходом:
• Добавить в заголовок пакета (четырехбайтный) поле UCHAR flags, которое будет содержать дополнительные данные, в том числе ошибки и прочее. Мне нравится этот вариант, один дополнительный байт - не так уж и много.
• Отвечать не 0x80, а 0xFF, а в дополнительных данных указывать какая команда не поддерживается и объяснение, почему не поддерживается (строка). - тоже нравится этот вариант, никаких лишних данных не нужно. Код команды ответа будет равен 127, (+ старший бит выставлен, значит сумарный ответ код команды = 255).

Олег К. Sincerely, Executor 13:14, 12 August 2012 (EEST)

Агаа, я тоже думал сначала про длину в 255 байт - но потом подумал, а вдруг понадобятся пакеты бесконечной длины, т.е. "до прерывания"? *crazy* Самый хороший вариант, ИМХО, сейчас - сообщение об ошибке ч-з 0xFF, т.е. по сути, поледний вариант. Получается и без костылей, и без перегрузки пакета лишней фигней - все-таки чем заголовок короче, тем и лучше. А там уже можно наворотить в данных всякие там IFCS_ERR_GENERIC, IFCS_ERR_HEADING, IFCS_ERR_OVF, IFCS_ERR_NOT_SUPPORTED, IFCS_ERR_SIGNATURE ну, ты понял :)

Swinemaker 08:15, 13 August 2012 (EEST)

Неспецифичные команды... Обновление прошивки через тот же UART

Даешь команду на запуск бутлоадера в неспецифичные - NET_CMD_STB_UPD_FIRMWARE ;)

Swinemaker 08:38, 13 August 2012 (EEST)

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

Олег К. Sincerely, Executor 23:04, 13 August 2012 (EEST)

Сегодня написал укуренный бутлоадер под это дело - меня задолбало по полторы минуты прошивать через программатор. Буду потихоньку описывать процедуру программирования. --Swinemaker 17:14, 14 August 2012 (EEST)

Параметры UART - все выше и выше :)

А почему все же "без удвоения скорости"? С удвоением-то ошибка меньше будет: ftp://swine.mypets.ws/!/NAVI/diag/dat_err.JPG

А ведь все равно, получится битрейт 59522,8 Swinemaker 16:13, 13 August 2012 (EEST)

Скорость BAUD115200 = 115200 = 115.2 Kбод/с (битрейт будет 115.2K * 8/9 где-то (стоп-бит не входит в полезные данные)) - предел, который поддерживает и Windows и Linux. Все остальное,что высше - зависит от операционки. Если пустишь свой модуль на 115.2K - скажешь, я все остальные настрою на такую-же. Согласен с тем, что нужно максимизировать скорость приема-передачи, чтобы минимум времени контроллер находился в состоянии ожидания следующей команды. По поводу ошибки (рассогласования) - рассогласование в 3% - это не много, т.к. при каждом старт/стоп-бите приемник и передатчик по каждой из линий автоматически синхронизируются.

Олег К. Sincerely, Executor 23:04, 13 August 2012 (EEST)

Так не обязательно раз удвоение, ставить 115200 - можно и с удвоением 57600, но рассогласование будет меньше (+0.9% против -1.4% без удвоения) - такой уж там алгоритм :) Просто без удвоения битрейт считается по формуле BAUD = fosc / 16*(UBRRn + 1), а с удвоением - по ф-ле BAUD = fosc / 8*(UBRRn + 1). Получается, что с удвоением скорость повыше будет.

Скорость выше, ИМХО, ставить не стоит, т.к. контроллер все равно не будет долго ожидать команды - обработка интерфейса реализована через буфер и по прерыванию. Если бы я каждый раз ждал конца пакета, никакого реал-тайм преобразования бы не получилось десу. Конечно, в этой авр'ке можно ставить хоть до 2.5Мбит/с, но это уже какой-то 2.5BASE-UART хДД.

З.Ы. Эти горизонтальные линии меня пугают ;) http://ru.wikipedia.org/wiki/%D0...D0.B9

--Swinemaker 06:20, 14 August 2012 (EEST)

Нет кросплатформенного подхода к обработке такого удвоенного по скорости варианта. Сложность в том, что нам нужно связать не два контроллера между собой, а контроллер и UART компьютера. Удвоенная скорость означает, что количество считываний каждого фронта меньше в два раза, поэтому он менее надежен чем не удвоенный по количеству выборок, а с нормальным (16 раз) количеством выборок но с удвоенной аппаратно скоростью. На отклонения ошибки особого внимания, наверное, не обращай - 2% выигрыша по синхронизации за транзакцию (до стоп-бита) недостаточно, чтобы перекрыть преимущество в двукратном увеличении количества выборок (больше помехоустойчивость). Детально вопрос не разбирал, возможно не прав. Кратко: если и делать удвоение (увеличение) скорости, то через увеличение частоты до предела поддерживаемой повсеместно. Олег К. Sincerely, Executor 21:28, 14 August 2012 (EEST)

Не-не-не, Девид Блейн :) Передача данных с удвоением скорости отличается от оной без удвоения только способом генерации такта в блоке UART контроллера - см. ftp://swine.mypets.ws/!/NAVI/diag/dat_u2x.JPG, U2Xn как раз задает "режим удвоения". По сути, этот "режим удвоения" - это всего лишь отключение предделителя системной частоты на 2 для тактирования подсистемы UART. Снаружи абсолютно невозможно определить, как генерируется частота у ней внутре (с), к тому же ничто не мешает задать произвольную частоту UART с помощью регистра UBRRn - см. ftp://swine.mypets.ws/!/NAVI/diag/dat_equ.JPG. И еще раз взгляни на эту таблицу: ftp://swine.mypets.ws/!/NAVI/diag/dat_err.JPG - каким способ задания частоты (либо то будет с U2Xn = 1, либо же с U2Xn = 0) влияет только на значение внутреннего предделителя - всего-то. Можно задать хоть 14400 "с удвоением".

--Swinemaker 09:07, 15 August 2012 (EEST)

AVR семплирует каждый бит UART, в обычном режиме в 16 отсчетов (считываний) в удвоенном - в 8 отсчетов (считываний). Удвоение - это ухудьшение точности.

Из документации ATMega8:

Setting this bit will reduce the divisor of the baud rate divider 
from 16 to 8, effectively doubling the transfer rate for asynchronous
communication. Note however that the Receiver will in this case only 
use half the number of samples (reduced from 16 to 8) for data sampling
and clock recovery, and therefore a more accurate baud rate setting and
system clock are required when this mode is used. For the Transmitter,
there are no downsides.

Олег К. Sincerely, Executor 09:55, 15 August 2012 (EEST)

Семплирует меньше, но за то:

For the Transmitter, there are no downsides. 

А ошибка все равно меньше получается, ftp://swine.mypets.ws/!/NAVI/diag/dat_err2.JPG

Хотя черт его знает, надо будет прогнать на стабильность так и так

--Swinemaker 10:03, 15 August 2012 (EEST)