один мастер - много слейвов
формат пакета простейший: первый байт длина/направление, второй - команда/адрес, затем данные, затем crc16 и стоп-байт 0xff
длина данных произвольна, в пределах разумного (0x7f)

байтстаффинг не нравится
перекодировать данные 7*8 в 8*7 ?
или еще что бывает ?

Сообщение отредактировал Огурцов - Aug 15 2013, 19:48

Использовать 9 бит, если контроллер позволяет.

https://sites.google.com/site/warlockwolf/H...stu-asinhronnyj

проблема в том, что с одной стороны pc, где девятым битом управлять получается весьма криво
да и везде он плохо пролазит
вообще, для себя я бы конвертор rs232-can поставил - снимает кучу головняка, в т.ч. сабж



к сожалению, у 4 в 8 очень большой оверхед

ввести в заголовок пакета его размер, определить минимальную паузу между пакетами (таймаут).

Можно зафиксировать начало пакета каким либо символом, при совпадении его с данными - дублировать. в качестве примера посмотреть WAKE-протокол
Про байтстаффинг, погорячился, отвлекли и пропустил нежелание с ним связываться

Сообщение отредактировал редактор - Aug 16 2013, 09:52

Задача не определена...
Кто сидит в сети? Если РС, то это одно, а если микроконтроллеры, то несколько другое...
Скорости и расстояния не определены... Потребность в квитировании - не определена... Прерывания от слэйвов???
Какой физический стык? Провод или оптика? Какая топология?
И что плохого в байтстаффинге, если речь идет о РС?
И какие проблемы с тем, чтобы в РС воткнуть модуль связи? Или чем плох Ethernet?
И как Вы задумали вот это: "длина/направление". Это как будет идти прием данных: по одной паре или по разным???

А так, поставьте LIN... и будет Вам протокол....

с пк на мк
115200, 10 метров
квитирование не определено, но я склоняюсь к необходимости
думаю, слейвы должны иметь возможность сигналить при необходимости
rs232/rs422 дуплекс, медь, очевидно
байтстаффинг неопределен по длине, замена 7*8 в 8*7 кажется намного более удобной
usb ненадежен, слотов нет, остальное все коряво
эзернет всем хорош, я сам был бы только рад

Вот про байтстаффинг так не надо. Сначала готовится пакет данных. Там и есть все, вместе с байтстаффингами...
А потом к нему добавляете заголовки, а их длина и местоположение известно... Да и считается быстрее и легче, чем кодирование на уровне бит. Т.к. при перекодировании бит, придется сдвигать байты в разные посылки в контроллер...
Замена "7*8 в 8*7" говорит о том, что Вы будете передавать не 8-ми битовые hex, а 7-ми битовые символьные коды?

Ну и какие проблемы с Ethernet? Гоняйте UDP пакеты. Со своим протоколом перезапроса по несовпадению данных в UDP... Например, если контроллер слабый, то к нему можно прицепить на SPI Ethernet-контроллер и все дела... И уж где при этом будет стоять РС значения иметь не будет...

у байтстаффинга длина пакета может недетерминированно выстрелить в два раза в случае если пойдет серия данных со значением байта подлежащего замене, вот это мне и не нравится
замена 7*8 не требует сдвига всех данных одновременно - может быть проще сдвигать каждый байт на один бит и задвигать это в восьмой байт
вообще-то, хочется чуда, какого-нибудь неизвестного метода, который не страдает обоими недостатками
вот с эзернет точно проблемы - его нет на мк, контроллеры уже куплены, так бывает

Сообщение отредактировал Огурцов - Aug 16 2013, 11:07

я явно что то не догоняю:
1) у вас в первом байте есть длина пакета.
2) у вас есть признак конца пакета.

и Вас интересует как определить конец пакета?
эээээээ как бы это дано.

я так понимаешь, что рассматриваются три варианта?
1) по тайм ауту
2) по разборке данных
3) вообще уйти от этого нафик, на более верхний уровень (изернет и иже. правда там уже логический уровень - целостность данных всё равно останется)

Например, если микроконтроллер, который у Вас куплен...., то к нему можно прицепить на SPI Ethernet-контроллер и все дела... Посмотрите у Микрела например, KSZ8851SNL...
Про байт-стаффинг. Сначала формируется пакет. Т.е. данные обрабатываются и делается стаффинг. А потом к нему добавляются заголовки... Ну и кто мешает в стаффинг ввести байт, показывающий повторы? Или при увеличении числа вставленных байт можно разбить пакет на части и передавать частями... Но в любом случае это будет быстрее, чем по-битовая обработка в РС. Я когда делал свой софт по jtag-тестированию быстор в этом убедился. Все быстро делает РС, но вот битовый поток быстро обработать не может...
Или, говоря по-другому, у Вас что, есть проблемы с временем доставки сообщений? Так при Вашей системе с одним мастером об этом и говорить не приходится... Это даже не смешно... Так строят только медленные сети...

да ничего не дано, это было дано, когда отправляли
а когда пришло, там может быть чёрте-что, битая длина, лишний конец пакета в середине пакета или наоборот пара склеенных пакетов




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


да не занимать ей скорости, уж на пересылку одного бита (скорее проверку знака) время найдется


проблемы с медленным каналом, каждый лишний байт уменьшает скорость чуть ли не в два раза
на частоте 500гц нужно обмениваться статистикой с устройством

Советую использовать байтстаффинг по алгоритму Consistent Overhead Byte Stuffing. Для Ваших длин пакетов всегда будет только 1 лишний байт после кодирования, при чем не зависимо от содержимого пакета.

Сам им уже давно пользуюсь как для связи между МК, так и между МК и ПК.

115200, 10 метров - и будут "склеенные пакеты"? Это где же такие 10 метров? Внутри электрогидрогенератора на миллион киловатт? В облаке плазмы? У сварочного агрегата?
Ну не совпадет байт, так произойдет запрос повторно... Или сделайте гальваническую развязку... Или экраны... "Склеенных пакетов " быть не может, если вводится тайм-аут между пакетами...
На самом деле, все это обсуждение - полная ерунда. Есть стандартные протоколы, есть промышленные компьютеры, у которых есть выходы на такие линии связи. Так вот, не надо изобретать "самопал"... Все это мне напоминает большую "Гайку М3", о которой написано у меня на сайте... Есть задача. Есть алгоритмы. Вот под них и надо подбирать оборудование. Не проходит 115200, так и бог с ним. Добавляете к каждому Вашему микроконтроллеру по 10 долл., переходите на Ethernet. А у пром-компьютеров он уже есть. И все. Более никаких проблем не будет. Либо покупаете готовый переходник RS-Ethernet... Или хоть для начала самый простой стартовый набор, в котором есть Ethernet... Кажется у микрочипа был микроконтроллер со встроенным 10 Мбит Ethernet... И все проблемы уходят. Какая у Вас серийность? Десятки тыс. в месяц?
Наверняка разовая поделка. Что Вы экономите! Ну купили микроконтроллеры, и что? Их тысячи лежат на складе? Стоимость контроллеров? А стоимость отладки и проводов? А программную совместимость с десятком программ, которые потом будут обрабатывать данные от Ваших контроллеров? А возможность дистанционно мониторить и перепрошивать из другого города? Считайте деньги... Считайте!

прочитал по-английски - не понял
прочитал по-русски - не понял еще сильнее
вывихнул моск об код
ушел курить

зы: если это работает, то это реально оно




да, с плазмой народ еще как борется


не представляю, как на пк управлять таймаутами


наверняка