[fiim 0]

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

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

Изменено 11 июня, 2015 пользователем fiim

[zltigo 0]

Собственно, предлагаю обсуждение...

Осуждать собственно нечего. Вы, в процессе рассуждений придя к очень правильному выводу, что фреймы нужно оформлять бит/байт стаффингом а не маяться фигней таймаутами и/или заголовками фрейма с размерами и опять-же таймаутами.... , тут-же ничтоже сумняшеся начали байтстаффинг уродовать "улучшениями" - выбором байта ломающим надежность и гробящим саму идею байтстаффинга всовыванием волшебного байта 0xFF являющегося де-факто маркером начала фрейма :(, добавлением НЕНУЖНОГО для НОРМАЛЬНОГО байтстаффинга размера фрейма.

Слово "радиосеть" вообще к "изобретенному" протоколу вообще отношения не имеет, ибо кто-то там еще оформляет полученный по описанному протоколу фрейм в эфирный фрейм.

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

[jcxz 184]

Осуждать собственно нечего. Вы, в процессе рассуждений придя к очень правильному выводу, что фреймы нужно оформлять бит/байт стаффингом а не маяться фигней таймаутами и/или заголовками фрейма с размерами и опять-же таймаутами.... , тут-же ничтоже сумняшеся начали байтстаффинг уродовать "улучшениями" - выбором байта ломающим надежность и гробящим саму идею байтстаффинга всовыванием волшебного байта 0xFF являющегося де-факто маркером начала фрейма :(, добавлением НЕНУЖНОГО для НОРМАЛЬНОГО байтстаффинга размера фрейма.

Слово "радиосеть" вообще к "изобретенному" протоколу вообще отношения не имеет, ибо кто-то там еще оформляет полученный по описанному протоколу фрейм в эфирный фрейм.

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

:a14:

+1

[fiim 0]

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

Оу, я всегда лезу куда не стоило бы)

По поводу байта 0xFF: зря вы на него так нападаете. Его не стоит использовать там, где нужно отделять байт от байта. А вот при разделении пакета от пакета он ведёт себя просто отлично. Не знаю, как у вас, а я делал началом пакетов разные байты, а не только фыфы, и количество ошибок ни помехоустойчивость от этого не зависят. В конце-концов никто не мешает вам у себя заменить его на любой другой. Но не стоит: ничего не изменится, я проверял -все очень чётко работает.

...выбором байта ломающим надежность и гробящим саму идею байтстаффинга

-!)))

...добавлением НЕНУЖНОГО для НОРМАЛЬНОГО байтстаффинга размера фрейма

-Размер фрейма добавлен здесь не для байтстаффинга, люди, байтстаффинг в этом ВООБЩЕ не нуждается. Размер добавляется в любом случае, если у вас фрейм может иметь разный размер. Вот USB пакеты имеют стандартную длину -64 байта, поэтому там размер указывать не надо. А если, как у меня, пакет может быть от 0 до 247 байт, тогда будьте бобры, укажите длину)

Ну и третий помидор:

...ибо кто-то там еще оформляет полученный по описанному протоколу фрейм в эфирный фрейм

-Это уж как кому угодно. В том и прелесть, что можно передавать данные и привязываясь и не привязываясь к эфирному фрейму, при этом простота передачи не изменится.

Изменено 26 июня, 2015 пользователем fiim

[zltigo 0]

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

Размер добавляется в любом случае, если у вас фрейм может иметь разный размер.

Я плакаль :(. Байтстафиговым байтом выделяется и начало и КОНЕЦ фрейма. Вот и получаем размер какой угодно. Им-же можно забивать гапы между фреймами для минимизации проблем пропадания байтов и потерь на раймауты. Таким образом эта Ваша фраза показывет еще большую глубину непонимания Вами содеянного :(

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

Вы просто совершенно НЕ понимаете что ЗА ВАС делает используемый Вами модуль и что ИМЕННО ОН, а СОВСЕМ НЕ Вы со всякими уродиливыми протоколами занимается именно ПРОТОКОЛОМ эфира помиаемым Вами всуе.

[fiim 0]

Я плакаль :(. Байтстафиговым байтом выделяется и начало и КОНЕЦ фрейма. Вот и получаем размер какой угодно. ...Таким образом эта Ваша фраза показывет еще большую глубину непонимания Вами содеянного :(

-Байтстафиговым байтом МОЖЕТ выделяться и начало и конец фрейма. Да, это неплохой вариант, он даже использовался в самых первых версиях. Но использование его только в начале или только в конце плюс байт размера абсолютно равнозначный вариант.

Вы просто совершенно НЕ понимаете что ЗА ВАС делает используемый Вами модуль и что ИМЕННО ОН, а СОВСЕМ НЕ Вы со всякими уродиливыми протоколами...

-Да я не настаиваю называть свой простенький проект каким-то "протоколом", так просто удобнее. Можно назвать "горшком", главное, что работает отлично. Любой, даже начинающий программист может сделать в 10(с половиной) раз лучше, чем я, и делают, и у них тоже все хорошо работает. А вы намного лучше меня понимаете, что делает используемый мной радиомодуль. Это же здорово! Если что, буду спрашивать у вас, уважаемый. Опять же, не обязательно использовать радиомодули для связи. Можно, например, юзать rs485. Правда, загвоздка: вы тогда не сможете сказать, что всю работу делает "именно он".

Изменено 26 июня, 2015 пользователем fiim

[zltigo 0]

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

 

[jcxz 184]

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

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

 

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

Работа энкодера при кодировании кадра в выходной поток:

Энкодер в начале кадра вставляет маркер "начало кадра" (последовательность N символов 'F', затем символ 'B'). Затем - передача символов исходного кадра. Если среди символов кодируемого кадра встречается последовательность из N символов 'F', то после них энкодер вставляет в вых. поток дополнительный символ 'D' (который будет удалён декодером). Также после последнего символа кадра вставляется один доп. символ не равный 'F' (который также будет удалён декодером). После конца кадра энкодер вставляет в вых. поток маркер "конец кадра" (последовательность N символов 'F', затем символ 'E'). Если после маркера "конец кадра" на вход энкодера сразу поступает новый кадр, то маркер "начало кадра" может не передаваться. Для сигнализации "канал жив" между кадрами энкодер может передавать любой символ заполнения, не равный 'F'.

Символом 'F' может выбираться любой удобный, вероятность появления которого минимальна во входном потоке.

Символы 'B', 'E', 'D' - также любые удобные.

Работа декодера думаю ясна. Могу только сказать, что при подключении декодера к потоку, он имеет начальное состояние "не синхронизирован". При получении маркеров "начало кадра" или "конец кадра", он переходит в состояние "синхронизирован" и начинает принимать кадр. В состояние "несинхронизирован" он переходит при любых ошибках приёма (переполнение буфера при приёме кадра, таймаут и т.п.).

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

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

[fiim 0]

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

 

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

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

Изменено 29 июня, 2015 пользователем fiim

[jcxz 184]

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

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

[fiim 0]

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

Вряд ли это моё изобретение. Наверняка кто-то использует этот способ уже 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.

Изменено 29 июня, 2015 пользователем fiim

[jcxz 184]

...

В итоге для отправки получим С0-77-77-DB-77-77-AA-77-DC-77-77.

И что?

Сами себе противоречите... Пишете, что не увеличивается и тут же сами же пишете, что добавляете байт...

Во-вторых - представить случай, что в пакете могут быть все байты 0...255 можете?

Байт-стаффинг имеет очень важное достоинство: кодонезависимость (мой метод тоже кодонезависим). В Вашем методе кодонезависимости нет.

[fiim 0]

И что?

Сами себе противоречите... Пишете, что не увеличивается и тут же сами же пишете, что добавляете байт...

-Как же вы правы!

Во-вторых - представить случай, что в пакете могут быть все байты 0...255 можете?

-Да, этот вариант годится только для пакетов длиной меньше, чем 256. В моем протоколе максимальная длина пакета 247байт, то есть этот вариант вполне годится. Если же вам необходимо формировать более длинные пакеты, то можно использовать 2 байта для "стартсимвола", и также два байта для кодирования. В итоге, длиннющий пакет, например в 16тысяч байт, и притом состоящий сплошь из управляющих символов, удлинится всего на 4 байта. В классическом байтстаффинге он удлинился бы на несколько тысяч байт.

[jcxz 184]

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

Интересно - как это??? Поясните.

[fiim 0]

Интересно - как это??? Поясните.

Принцип тот же самый. Можно перенести этот принцип и на двубайтный вариант. Там, правда, есть пара нюансов, я о них скажу. Проще всего показать на примере. Пусть нам нужно передать последовательность из таких байт: C0-DB-C0-DB-C0-DB... длиной в 15 тысяч байт. И пусть стартовое слово(2 байта) у нас тоже будет C0-DB. То есть допустим, что последовательность вся состоит из стартовых слов. Нам нужно всего лишь найти подходящее 2байтное слово для кодировки. Для этого точно также проходимся по последовательности, и смотрим, какое 2байтное сочетание там НЕ встречается. В нашем случае таких полно. Возьмем, например, слово 77-АА, и поставим его следом за стартовым словом, получаем первые 4 байта: C0-DB-77-AA. А в самой последовательности всё, что совпадает со стартовым словом(C0-DB) заменяем на кодовое(77-AA). В итоге получаем: C0-DB-77-AA-77-AA-77-AA... итого 15004 байта. Теперь, как и обещал, о нюансах. Первое: желательно, чтобы из последнего байта предыдущего пакета и первого байта стартового слова следующего пакета не получилось стартовое слово. Это решить очень просто: достаточно стартовое слово сделать из разных байт, то есть нельзя С0-С0, нельзя DB-DB, а можно C0-DB или DB-C0 и т.д. Второй нюанс: нельзя, чтобы любой байт у кодировочного слова совпадал с любым байтом стартового слова, иначе в процессе кодировки это может породить стартовое сочетание. То есть выбор кодировочного слова у нас уменьшается на 512+512+1. Ах, да, еще байты кодировочного слова желательно сделать разными. Поэтому максимальная длина пакета для такого байтстаффинга не 65535 байт, как могло показаться на первый взгляд, а меньше. Но в любом случае такой 2байтный вариант позволяет формировать пакеты в много тысяч байт. Конечно никому не советую слать такие длинные пакеты))). Если вдруг в результате какой-нибудь помехи вам придется посылать пакет заново, то это будет обидно. А если пакеты маленькие, то заново его переслать -это не страшно. Для UARTа я стараюсь ограничиваться максимум в 200байт, а для радио и того меньше, поэтому однобайтный байтстаффинг лично для меня более предпочтителен. Тем более реализация программы для длинных пакетов тоже будет сложнее, что может сказаться на слабых микроконтроллерах.

Изменено 29 июня, 2015 пользователем fiim