USB-UART и радиосеть Опции

[fiim]

Собственно, предлагаю обсуждение еще одного варианта USB(HID)-UART- переходника, а также связанного с ним протокола передачи данных, и использование этого протокола в построении простой радио-сети.
Проект совсем новый, поэтому много недочетов, но уже сейчас переходник обеспечивает передачу на скоростях до 500кбит, годен для очень слабых микроконтроллеров(<2кБ), и очень удобен: достаточно нескольких строк кода что в компьютерной программе, что на микроконтроллере, чтобы передать данные. Вот здесь вводное описание и там же ссылка на сайт с документацией и видеоуроками:http://bextensions.wix.com/be-bdn#!history/cipy. Тухлые помидоры тоже приветствуются

Сообщение отредактировал fiim - Jun 11 2015, 11:56

[zltigo]

Уже все сказано. Думайте. Повторять в третий раз не вижу сысла.

[jcxz]

Уже все сказано. Думайте. Повторять в третий раз не вижу сысла.

Зря распинаетесь, пациент безнадёжен - в морг.

ЗЫ: Кстати я иногда модифицирую стандартный байт-стаффинг - в качестве флага использую не один спец-символ как в байт-стаффинге, а последовательность из N символов 'F'. Так минимизируется недостаток классического байт-стаффинга состоящий в удвоении объёма кодированного потока при передаче исходного потока состоящего сплошь из сигнальных символов.
Работа энкодера при кодировании кадра в выходной поток:
Энкодер в начале кадра вставляет маркер "начало кадра" (последовательность N символов 'F', затем символ 'B'). Затем - передача символов исходного кадра. Если среди символов кодируемого кадра встречается последовательность из N символов 'F', то после них энкодер вставляет в вых. поток дополнительный символ 'D' (который будет удалён декодером). Также после последнего символа кадра вставляется один доп. символ не равный 'F' (который также будет удалён декодером). После конца кадра энкодер вставляет в вых. поток маркер "конец кадра" (последовательность N символов 'F', затем символ 'E'). Если после маркера "конец кадра" на вход энкодера сразу поступает новый кадр, то маркер "начало кадра" может не передаваться. Для сигнализации "канал жив" между кадрами энкодер может передавать любой символ заполнения, не равный 'F'.
Символом 'F' может выбираться любой удобный, вероятность появления которого минимальна во входном потоке.
Символы 'B', 'E', 'D' - также любые удобные.
Работа декодера думаю ясна. Могу только сказать, что при подключении декодера к потоку, он имеет начальное состояние "не синхронизирован". При получении маркеров "начало кадра" или "конец кадра", он переходит в состояние "синхронизирован" и начинает принимать кадр. В состояние "несинхронизирован" он переходит при любых ошибках приёма (переполнение буфера при приёме кадра, таймаут и т.п.).
При получении "конец кадра", из буфера удаляется последний символ, кадр передаётся на следующий уровень обработки, обнуляется приёмный буфер и приёмник остаётся в состояние "синхронизирован".
Такой алгоритм полезен для каналов с ограниченной пропускной способностью, которые могут переполниться при передаче произвольного потока байт с использованием стандартного байт-стаффинга. У этого алгоритма меньший коэффициент увеличения размера кадра (при условии что кадры довольно большие) при передаче флаговых байт в исходном потоке.

[fiim]

Зря распинаетесь, пациент безнадёжен - в морг.

ЗЫ: Кстати я иногда модифицирую стандартный байт-стаффинг - в качестве флага использую не один спец-символ как в байт-стаффинге, а последовательность из N символов 'F'. Так минимизируется недостаток классического байт-стаффинга состоящий в удвоении объёма кодированного потока при передаче исходного потока состоящего сплошь из сигнальных символов...

-Да, это классический байтстаффинг. У вас хорошее решение. Я тоже не боюсь менять классику так, как мне вздумается. В моем варианте байтстаффинга объем кодированного потока вообще не увеличивается, даже если сплошь состоит из сигнальных символов.

Сообщение отредактировал fiim - Jun 29 2015, 05:00

[jcxz]

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

Это невозможно.

[fiim]

Это невозможно.

Вряд ли это моё изобретение. Наверняка кто-то использует этот способ уже 100лет. В классическом варианте начало пакета обозначается байтом 0хС0, а если он встречается в самом пакете, то его заменяют на 0хDBDC. А если в пакете встречается 0xDB, то он заменяется на 0xDBDD. Собственно, не особо важно какие именно выбраны байты, но, заметьте, что замена идет заранее определенными байтами, которые тоже могут встретиться в последовательности. Поэтому их и приходится заменять на двойные последовательности, от чего и разрастается исходная последовательность. А вот если вы не будете использовать для замены константу, которая может тоже встретиться в вашей последовательности, а возьмёте для замены байт, которого просто нет в пакете, тогда этим байтом вы можете спокойно заменить все стартовые 0xC0, если они вдруг встретятся внутри пакета. Единственное, что вам нужно -это указать приёмнику(декодеру), каким байтом вы заменяете стартовый. Пример. Пусть вам надо переслать последовательность DB-C0-DC-DD. В начале пакета вы ставите C0, а потом просматриваете весь пакет, чтобы определить, какой байт там НЕ встречается. В нашем случае там не встречается много байт, берём любой, например 0xAA, и вставляем его сразу за стартовым байтом, получаем C0-AA. Далее передаем саму последовательность, но в ней встречающиеся С0 меняем на АА. В итоге получаем: C0-AA-DB-AA-DC-DD. Всё! Приёмник(декодер)читает байт, следующий за стартовым байтом, то есть АА, и далее все байты АА меняет на С0, восстанавливая таким образом всю последовательность. Попробуем взять еще один пример, где необходимая для передачи последовательность содержит очень много управляющих символов, например C0-DB-C0-C0-AA-C0-DC-C0-C0. Определяем, какого байта здесь нет, берем любой из них, например, 0х77, и добавляем его к стартовому байту. В итоге для отправки получим С0-77-77-DB-77-77-AA-77-DC-77-77.

Сообщение отредактировал fiim - Jun 29 2015, 06:38