miheyk 0 29 июня, 2015 Опубликовано 29 июня, 2015 · Жалоба Преамбулу никто не отменял, даже самые дубовые передатчики используют ее для захвата эфира и синхронизации с приемником. Если реализовать прерывание по приему то и городить ничего не нужно. В пакет можно добавить заголовок с метрикой и длиной кадра, а в конец обязательно CRC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 29 июня, 2015 Опубликовано 29 июня, 2015 · Жалоба Принцип тот же самый. ... Конечно никому не советую слать такие ... ... может сказаться на слабых микроконтроллерах. я б тоже не советовал никому использовать то что вы тут намутили, кошмар и только. Ни объем передать, ни короткими пакетами поработать. Да и за пределами стандартов, все это у вас протокольное. Про временную синхру, сбои ... никак, и много еще чего, что в реальных условиях нужно. Подвис у вас один узел-транслятор, которого не обойти, пошли теряться пакеты, сеть из 200 подвисла, как восстановить? Никак, только перезагрузка всех и пере-синхронизацией заново. Кому это нужно? От наведеной помехи повиснет треть оконечников в сети ... и проблема вашего протокола очевидна. Итд ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 187 30 июня, 2015 Опубликовано 30 июня, 2015 · Жалоба Принцип тот же самый. Можно перенести этот принцип и на двубайтный вариант. ... Всё это больше похоже на алгоритм сжатия с построением словаря и заменой лексем на более короткие. Это не делается на этапе канального кодирования, а делается предварительно (если нужно) для сжатия исходного кадра. Для канального кодирования здесь сразу видится минус - очень времязатратный алгоритм. Поиск последовательности байт, не встречающейся в кадре - может съедать очень много процессорного времени. И время обработки кадра недетерминированное - очень сильно зависит от содержимого. Если уж идти по такому пути, то тогда обычно пропускают кадр через алгоритм сжатия, а потом делают его канальное кодирование. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fiim 0 30 июня, 2015 Опубликовано 30 июня, 2015 · Жалоба Преамбулу никто не отменял, даже самые дубовые передатчики используют ее для захвата эфира и синхронизации с приемником. Если реализовать прерывание по приему то и городить ничего не нужно. В пакет можно добавить заголовок с метрикой и длиной кадра, а в конец обязательно CRC.-Здесь я описал только ту часть протокола, которая касается байтстаффинга(по просьбам зрителей))). Конечно кроме байтстаффинга в протоколе есть и длина кадра и CRC16 и адресация... Кто удосужился пройти по ссылке вначале, очень надеюсь, всё это увидели :laughing: А вот преамбулы и синхронизации там нет. Если кто-то читал статейку, то увидели, что главная первоначальная задача была связать 2 микроконтроллера по УАРТу. Синхронизацией вам для этого заниматься не надо. Протокол лишь дает удобство общения между микроконтроллерами по УАРТу(с проверкой CRC и другими приятными мелочами(см. видео по ссылке). И вот к такому микроконтроллеру, опять же ПО УАРТу, вы можете подключить стандартный радиомодуль, который имеет свой протокол, и вам до него дела нет. У него есть и преамбула и все остальное для эфирной передачи, но, повторяю, вам до этого дела нет, вы на этом не заморачиваетесь: подключили к УАРТу и кидаете данные. Или, например, если речь идет о применении моего протокола в переходнике УАРТ-ЮСБ: мой протокол НЕ ЗАМЕНЯЕТ протокола ЮСБ, так же как НЕ ЗАМЕНЯЕТ эфирный протокол радиомодулей. Вы просто кидаете данные по УАРТу в переходник и не заботитесь о том как ЮСБ передает все это в компьютер. А то некоторые, не разобравшись, понавесят на мой протокол функций, которых я не заявлял, а потом говорят "фу". Ну разве вы требуете, например, от МОДБАСа, чтобы он имел преамбулу для захвата эфира? Вот и от моего не стоит требовать. А почему я написал про радиосеть? Да просто потому, что я подключил к нескольким микроконтроллерам радиомодули, это все отлично заработало и я понял, что более удобной системы я не встречал: три строчки кода- и готов полноценный обмен данными. С помощью МОДБАСа, например, так просто не получится.(Но я не уничижаю МОДБАС:он имеет свои достоинства, до которых мне далеко) Кроме того мой протокол дает возможность ретрансляции(то есть нечто типичное именно для радиосвязи). Причем никаких специальных ретрансляторов городить не надо. Неужели после этого я не мог в название этой темы добавить слово"радиосеть"?Всё это больше похоже на алгоритм сжатия-Никакого сжатия, просто модифицированный байтстаффинг.Для канального кодирования здесь сразу видится минус - очень времязатратный алгоритм-Скачайте библиотеку(по ссылке вначале):даже AVR8 на частоте всего 1 МГц справляется с максимальными пакетами(247байт) и бОльшую часть времени отдыхает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
miheyk 0 30 июня, 2015 Опубликовано 30 июня, 2015 · Жалоба Кто удосужился пройти по ссылке вначале, очень надеюсь, всё это увидели Уж простите, но я прошел по ссылке и увидел там только портянку :) Касательно подключил и забыл - модули как минимум придется конфигурировать, а если брать CC430 и аналоги то и вовсе для них прошивку нужно ваять Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 187 3 июля, 2015 Опубликовано 3 июля, 2015 · Жалоба -Скачайте библиотеку(по ссылке вначале):даже 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться