Перейти к содержанию
    

fiim

Участник
  • Постов

    53
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о fiim

  • Звание
    Участник
    Участник
  1. -Здесь я описал только ту часть протокола, которая касается байтстаффинга(по просьбам зрителей))). Конечно кроме байтстаффинга в протоколе есть и длина кадра и CRC16 и адресация... Кто удосужился пройти по ссылке вначале, очень надеюсь, всё это увидели :laughing: А вот преамбулы и синхронизации там нет. Если кто-то читал статейку, то увидели, что главная первоначальная задача была связать 2 микроконтроллера по УАРТу. Синхронизацией вам для этого заниматься не надо. Протокол лишь дает удобство общения между микроконтроллерами по УАРТу(с проверкой CRC и другими приятными мелочами(см. видео по ссылке). И вот к такому микроконтроллеру, опять же ПО УАРТу, вы можете подключить стандартный радиомодуль, который имеет свой протокол, и вам до него дела нет. У него есть и преамбула и все остальное для эфирной передачи, но, повторяю, вам до этого дела нет, вы на этом не заморачиваетесь: подключили к УАРТу и кидаете данные. Или, например, если речь идет о применении моего протокола в переходнике УАРТ-ЮСБ: мой протокол НЕ ЗАМЕНЯЕТ протокола ЮСБ, так же как НЕ ЗАМЕНЯЕТ эфирный протокол радиомодулей. Вы просто кидаете данные по УАРТу в переходник и не заботитесь о том как ЮСБ передает все это в компьютер. А то некоторые, не разобравшись, понавесят на мой протокол функций, которых я не заявлял, а потом говорят "фу". Ну разве вы требуете, например, от МОДБАСа, чтобы он имел преамбулу для захвата эфира? Вот и от моего не стоит требовать. А почему я написал про радиосеть? Да просто потому, что я подключил к нескольким микроконтроллерам радиомодули, это все отлично заработало и я понял, что более удобной системы я не встречал: три строчки кода- и готов полноценный обмен данными. С помощью МОДБАСа, например, так просто не получится.(Но я не уничижаю МОДБАС:он имеет свои достоинства, до которых мне далеко) Кроме того мой протокол дает возможность ретрансляции(то есть нечто типичное именно для радиосвязи). Причем никаких специальных ретрансляторов городить не надо. Неужели после этого я не мог в название этой темы добавить слово"радиосеть"? -Никакого сжатия, просто модифицированный байтстаффинг. -Скачайте библиотеку(по ссылке вначале):даже AVR8 на частоте всего 1 МГц справляется с максимальными пакетами(247байт) и бОльшую часть времени отдыхает.
  2. Принцип тот же самый. Можно перенести этот принцип и на двубайтный вариант. Там, правда, есть пара нюансов, я о них скажу. Проще всего показать на примере. Пусть нам нужно передать последовательность из таких байт: 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байт, а для радио и того меньше, поэтому однобайтный байтстаффинг лично для меня более предпочтителен. Тем более реализация программы для длинных пакетов тоже будет сложнее, что может сказаться на слабых микроконтроллерах.
  3. -Как же вы правы! -Да, этот вариант годится только для пакетов длиной меньше, чем 256. В моем протоколе максимальная длина пакета 247байт, то есть этот вариант вполне годится. Если же вам необходимо формировать более длинные пакеты, то можно использовать 2 байта для "стартсимвола", и также два байта для кодирования. В итоге, длиннющий пакет, например в 16тысяч байт, и притом состоящий сплошь из управляющих символов, удлинится всего на 4 байта. В классическом байтстаффинге он удлинился бы на несколько тысяч байт.
  4. Вряд ли это моё изобретение. Наверняка кто-то использует этот способ уже 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.
  5. -Да, это классический байтстаффинг. У вас хорошее решение. Я тоже не боюсь менять классику так, как мне вздумается. В моем варианте байтстаффинга объем кодированного потока вообще не увеличивается, даже если сплошь состоит из сигнальных символов.
  6. -Байтстафиговым байтом МОЖЕТ выделяться и начало и конец фрейма. Да, это неплохой вариант, он даже использовался в самых первых версиях. Но использование его только в начале или только в конце плюс байт размера абсолютно равнозначный вариант. -Да я не настаиваю называть свой простенький проект каким-то "протоколом", так просто удобнее. Можно назвать "горшком", главное, что работает отлично. Любой, даже начинающий программист может сделать в 10(с половиной) раз лучше, чем я, и делают, и у них тоже все хорошо работает. А вы намного лучше меня понимаете, что делает используемый мной радиомодуль. Это же здорово! Если что, буду спрашивать у вас, уважаемый. Опять же, не обязательно использовать радиомодули для связи. Можно, например, юзать rs485. Правда, загвоздка: вы тогда не сможете сказать, что всю работу делает "именно он".
  7. Оу, я всегда лезу куда не стоило бы) По поводу байта 0xFF: зря вы на него так нападаете. Его не стоит использовать там, где нужно отделять байт от байта. А вот при разделении пакета от пакета он ведёт себя просто отлично. Не знаю, как у вас, а я делал началом пакетов разные байты, а не только фыфы, и количество ошибок ни помехоустойчивость от этого не зависят. В конце-концов никто не мешает вам у себя заменить его на любой другой. Но не стоит: ничего не изменится, я проверял -все очень чётко работает. -!))) -Размер фрейма добавлен здесь не для байтстаффинга, люди, байтстаффинг в этом ВООБЩЕ не нуждается. Размер добавляется в любом случае, если у вас фрейм может иметь разный размер. Вот USB пакеты имеют стандартную длину -64 байта, поэтому там размер указывать не надо. А если, как у меня, пакет может быть от 0 до 247 байт, тогда будьте бобры, укажите длину) Ну и третий помидор: -Это уж как кому угодно. В том и прелесть, что можно передавать данные и привязываясь и не привязываясь к эфирному фрейму, при этом простота передачи не изменится.
  8. Собственно, предлагаю обсуждение еще одного варианта USB(HID)-UART- переходника, а также связанного с ним протокола передачи данных, и использование этого протокола в построении простой радио-сети. Проект совсем новый, поэтому много недочетов, но уже сейчас переходник обеспечивает передачу на скоростях до 500кбит, годен для очень слабых микроконтроллеров(<2кБ), и очень удобен: достаточно нескольких строк кода что в компьютерной программе, что на микроконтроллере, чтобы передать данные. Вот здесь вводное описание и там же ссылка на сайт с документацией и видеоуроками:http://bextensions.wix.com/be-bdn#!history/cipy. Тухлые помидоры тоже приветствуются ;)
  9. Ну как сюда не предложить такой вариант:Основная идея, И еще ссылочка:Ссыль
  10. Тут есть статейка кажется в тему:BE-BDN
  11. Вот тоже вариант: здесь очень простой в использовании USB-HID -> UART -переходник с описанием, как с ним можно использовать дешевые радиомодули:BE-BDN. А здесь небольшая статейка, вводящая в курс:BK
  12. Продайте USB PID!

    Я просил у FTDI, но не дают, не смотря на то, что мы юзаем в некоторых наших старых приборы их чипы. Наверно надо уметь просить)) - с предоставлением инфы, в каких именно приборах это будет и с какими именно их чипами. Понятно, это было бы враньё, я же не собирался брать пид для их чипа. У LPC не пробовал, но скорее всего так же. Вот, говорят, из любой ситуации есть как минимум 2 выхода))) -надо думать дальше.
  13. Продайте USB PID!

    Sasamy, спасибо. Да, они запретили раздавать. Чужой не хочется юзать, тк если какой-ть китаец, или такая же маленькая конторка как наша уже его юзает, например как мышь, то будут конфликты, если чел уже подключал их девайс к своему компу.
  14. Продайте USB PID!

    Как бы и для себя, т.к. в нашей конторе программист я. Но сама контора очень маленькая, оборот и зарплаты даже гендиректора смешные. То есть потянуть купить ВИД на 65тыс ПИДов не представляется возможным. А тут такой казус: могу для конторы программировать юсб-хид, за что и ценюсь, а использовать она его не может((( Поэтому можно сказать, что прошу для себя. Даже не пару, одного бы хватило, т.к. свои девайсы можно дальше разделять по строковому идентификатору.
  15. Продайте USB PID!

    Всем привет! ;) Нашел в нете только здесь: mcselec.com/, но у них неразбериха какая-то. Сам ПИД у них стоит всего 10 долларов, но когда пытаешься купить, сперва пишут, что требуется еще 7,5 евро, т.к. Россия не в ЕС, на еще двумя страницами позже уже требуют 15евро, за то же самое. Заплатил бы и 7,5, а может и 15 к тем десяти(за парочку точно!), но если у них такой беспорядок, то закрадывается мысль, что это вообще кидалово! Помогите, если кто может, приобрести парочку ПИДов для своих устройств. :laughing:
×
×
  • Создать...