[miheyk 0]

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

[Aner 3]

Принцип тот же самый.

... Конечно никому не советую слать такие ...

... может сказаться на слабых микроконтроллерах.

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

Ни объем передать, ни короткими пакетами поработать. Да и за пределами стандартов, все это у вас протокольное.

Про временную синхру, сбои ... никак, и много еще чего, что в реальных условиях нужно.

Подвис у вас один узел-транслятор, которого не обойти, пошли теряться пакеты, сеть из 200 подвисла, как восстановить?

Никак, только перезагрузка всех и пере-синхронизацией заново. Кому это нужно?

От наведеной помехи повиснет треть оконечников в сети ... и проблема вашего протокола очевидна. Итд ...

[jcxz 184]

Принцип тот же самый. Можно перенести этот принцип и на двубайтный вариант.

...

Всё это больше похоже на алгоритм сжатия с построением словаря и заменой лексем на более короткие. Это не делается на этапе канального кодирования, а делается предварительно (если нужно) для сжатия исходного кадра.

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

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

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

[fiim 0]

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

-Здесь я описал только ту часть протокола, которая касается байтстаффинга(по просьбам зрителей))). Конечно кроме байтстаффинга в протоколе есть и длина кадра и CRC16 и адресация... Кто удосужился пройти по ссылке вначале, очень надеюсь, всё это увидели :laughing: А вот преамбулы и синхронизации там нет. Если кто-то читал статейку, то увидели, что главная первоначальная задача была связать 2 микроконтроллера по УАРТу. Синхронизацией вам для этого заниматься не надо. Протокол лишь дает удобство общения между микроконтроллерами по УАРТу(с проверкой CRC и другими приятными мелочами(см. видео по ссылке). И вот к такому микроконтроллеру, опять же ПО УАРТу, вы можете подключить стандартный радиомодуль, который имеет свой протокол, и вам до него дела нет. У него есть и преамбула и все остальное для эфирной передачи, но, повторяю, вам до этого дела нет, вы на этом не заморачиваетесь: подключили к УАРТу и кидаете данные. Или, например, если речь идет о применении моего протокола в переходнике УАРТ-ЮСБ: мой протокол НЕ ЗАМЕНЯЕТ протокола ЮСБ, так же как НЕ ЗАМЕНЯЕТ эфирный протокол радиомодулей. Вы просто кидаете данные по УАРТу в переходник и не заботитесь о том как ЮСБ передает все это в компьютер. А то некоторые, не разобравшись, понавесят на мой протокол функций, которых я не заявлял, а потом говорят "фу". Ну разве вы требуете, например, от МОДБАСа, чтобы он имел преамбулу для захвата эфира? Вот и от моего не стоит требовать. А почему я написал про радиосеть? Да просто потому, что я подключил к нескольким микроконтроллерам радиомодули, это все отлично заработало и я понял, что более удобной системы я не встречал: три строчки кода- и готов полноценный обмен данными. С помощью МОДБАСа, например, так просто не получится.(Но я не уничижаю МОДБАС:он имеет свои достоинства, до которых мне далеко) Кроме того мой протокол дает возможность ретрансляции(то есть нечто типичное именно для радиосвязи). Причем никаких специальных ретрансляторов городить не надо. Неужели после этого я не мог в название этой темы добавить слово"радиосеть"?

Всё это больше похоже на алгоритм сжатия

-Никакого сжатия, просто модифицированный байтстаффинг.

Для канального кодирования здесь сразу видится минус - очень времязатратный алгоритм

-Скачайте библиотеку(по ссылке вначале):даже AVR8 на частоте всего 1 МГц справляется с максимальными пакетами(247байт) и бОльшую часть времени отдыхает.

[miheyk 0]

Кто удосужился пройти по ссылке вначале, очень надеюсь, всё это увидели

Уж простите, но я прошел по ссылке и увидел там только портянку :)

Касательно подключил и забыл - модули как минимум придется конфигурировать, а если брать CC430 и аналоги то и вовсе для них прошивку нужно ваять

[jcxz 184]

-Скачайте библиотеку(по ссылке вначале):даже AVR8 на частоте всего 1 МГц справляется с максимальными пакетами(247байт) и бОльшую часть времени отдыхает.

Мы говорили о кадрах размером >255 байт.

Берём в руки обычный калькулятор, считаем сколько времени потребуется для поиска 2-байтовой последовательности, отсутствующей в кадре.

Допустим размер кадра == 1000байт. Допустим поиск 2-байтовой последовательности идёт просто прямым сравнением подряд от начала кадра.

Допустим искомые последовательности генерим начиная от 0 и далее (если найдена) инкремент.

Получаем:

1.Для проверки вхождения одной 2-байтовой последовательности в кадр потребуется от 1 до 999 сравнений. Среднее кол-во == ~500.

2.В худшем случае придётся выполнить 501 генерацию новых последовательностей (с их последующей проверкой).

Это в случае если кадр состоит из слов: 0000, 0001, 0002, ... .

Итого получаем: 500*500 = 250000 сравнений. И это без учёта ещё сравнений с последовательностями границы кадра.

Сколько Ваш AVR8 будет кодировать такой кадр? Особенно учитывая что он 8-битный и на одно сравнение тратит кучу команд. Думаю - несколько секунд. При полной загрузке CPU.

Жесть короче.

 

Конечно это расчёт для худшего случая. При другом содержимом кадра будет меньше. Но для реалтайм-систем необходимо учитывать максимальное время.

И при этом этот процессор должен ещё выполнять и какую-то полезную работу.

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

 

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

Кодирование/декодирование кадра можно проводить хоть прямо на лету в ISR не расходуя на это драгоценное ОЗУ - записывать в выходной буфер уже декодированный кадр,

а на в буфере передачи хранить исходный кадр и кодировать его на лету при записи собственно в порт в ISR.