Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: как определить конец пакета ?
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > RS232/LPT/USB/PCMCIA/FireWire
Огурцов
один мастер - много слейвов
формат пакета простейший: первый байт длина/направление, второй - команда/адрес, затем данные, затем crc16 и стоп-байт 0xff
длина данных произвольна, в пределах разумного (0x7f)

байтстаффинг не нравится
перекодировать данные 7*8 в 8*7 ?
или еще что бывает ?
Alex11
Использовать 9 бит, если контроллер позволяет.
Огурцов
Цитата(Alex11 @ Aug 15 2013, 22:28) *
Использовать 9 бит, если контроллер позволяет.

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


Цитата(Warlockwolf @ Aug 15 2013, 23:03) *

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

Можно зафиксировать начало пакета каким либо символом, при совпадении его с данными - дублировать. в качестве примера посмотреть WAKE-протокол
Про байтстаффинг, погорячился, отвлекли и пропустил нежелание с ним связываться
iosifk
Цитата(Огурцов @ Aug 15 2013, 23:46) *
один мастер - много слейвов
формат пакета простейший: первый байт длина/направление, второй - команда/адрес, затем данные, затем crc16 и стоп-байт 0xff


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

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


CODE
// Packet format ========================================================

// byte # 0
// 0.7 service bit, 0
// 0.6 destination address presece
// 0.5 source address presece
// 0.4 packet length.4
// 0.3 packet length.3
// 0.2 packet length.2
// 0.1 packet length.1
// 0.0 packet length.0

// [byte # 1]
// 1.7 service bit, 0
// 1.6 destination address.6
// 1.5 destination address.5
// 1.4 destination address.4
// 1.3 destination address.3
// 1.2 destination address.2
// 1.1 destination address.1
// 1.0 destination address.0

// [byte # 2]
// 2.7 service bit, 0
// 2.6 source address.6
// 2.5 source address.5
// 2.4 source address.4
// 2.3 source address.3
// 2.2 source address.2
// 2.1 source address.1
// 2.0 source address.0

// byte # 3
// 3.7 service bit, 0
// 3.6 command.6
// 3.5 command.5
// 3.4 command.4
// 3.3 command.3
// 3.2 command.2
// 3.1 command.1
// 3.0 command.0

// byte # 4..byte # length - 2
// 4.7 service bit, 0
// 4.6 data.6
// 4.5 data.5
// 4.4 data.4
// 4.3 data.3
// 4.2 data.2
// 4.1 data.1
// 4.0 data.0

// byte # 4 + 7
// 11.7 service bit, 0
// 11.6 data6.7
// 11.5 data5.7
// 11.4 data4.7
// 11.3 data3.7
// 11.2 data2.7
// 11.1 data1.7
// 11.0 data0.7

// byte # length - 1
// n-1.7 service bit, 0
// n-1.6 crc7.6
// n-1.5 crc7.5
// n-1.4 crc7.4
// n-1.3 crc7.3
// n-1.2 crc7.2
// n-1.1 crc7.1
// n-1.0 crc7.0

// byte # length
// n.7 service bit, 1
// n.6 service bit, 1
// n.5 service bit, 1
// n.4 service bit, 1
// n.3 service bit, 1
// n.2 service bit, 1
// n.1 service bit, 1
// n.0 service bit, 1


iosifk
Цитата(Огурцов @ Aug 16 2013, 14:38) *
байтстаффинг неопределен по длине, замена 7*8 в 8*7 кажется намного более удобной
usb ненадежен, слотов нет, остальное все коряво
эзернет всем хорош, я сам был бы только рад


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

Ну и какие проблемы с Ethernet? Гоняйте UDP пакеты. Со своим протоколом перезапроса по несовпадению данных в UDP... Например, если контроллер слабый, то к нему можно прицепить на SPI Ethernet-контроллер и все дела... И уж где при этом будет стоять РС значения иметь не будет...
Огурцов
у байтстаффинга длина пакета может недетерминированно выстрелить в два раза в случае если пойдет серия данных со значением байта подлежащего замене, вот это мне и не нравится
замена 7*8 не требует сдвига всех данных одновременно - может быть проще сдвигать каждый байт на один бит и задвигать это в восьмой байт
вообще-то, хочется чуда, какого-нибудь неизвестного метода, который не страдает обоими недостатками
вот с эзернет точно проблемы - его нет на мк, контроллеры уже куплены, так бывает
kolobok0
Цитата(Огурцов @ Aug 16 2013, 15:05) *
...хочется чуда, какого-нибудь неизвестного метода......формат пакета простейший: первый байт длина/направление, второй - команда/адрес, затем данные, затем crc16 и стоп-байт 0xff...


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

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

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

iosifk
Цитата(Огурцов @ Aug 16 2013, 15:05) *
у байтстаффинга длина пакета может недетерминированно выстрелить в два раза в случае если пойдет серия данных со значением байта подлежащего замене, вот это мне и не нравится
замена 7*8 не требует сдвига всех данных одновременно - может быть проще сдвигать каждый байт на один бит и задвигать это в восьмой байт
вообще-то, хочется чуда, какого-нибудь неизвестного метода, который не страдает обоими недостатками
вот с эзернет точно проблемы - его нет на мк, контроллеры уже куплены, так бывает

Например, если микроконтроллер, который у Вас куплен...., то к нему можно прицепить на SPI Ethernet-контроллер и все дела... Посмотрите у Микрела например, KSZ8851SNL...
Про байт-стаффинг. Сначала формируется пакет. Т.е. данные обрабатываются и делается стаффинг. А потом к нему добавляются заголовки... Ну и кто мешает в стаффинг ввести байт, показывающий повторы? Или при увеличении числа вставленных байт можно разбить пакет на части и передавать частями... Но в любом случае это будет быстрее, чем по-битовая обработка в РС. Я когда делал свой софт по jtag-тестированию быстор в этом убедился. Все быстро делает РС, но вот битовый поток быстро обработать не может...
Или, говоря по-другому, у Вас что, есть проблемы с временем доставки сообщений? Так при Вашей системе с одним мастером об этом и говорить не приходится... Это даже не смешно... Так строят только медленные сети...
Огурцов
Цитата(kolobok0 @ Aug 16 2013, 11:26) *
эээээээ как бы это дано

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



Цитата(iosifk @ Aug 16 2013, 11:42) *
Ну и кто мешает в стаффинг ввести байт, показывающий повторы?

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

Цитата(iosifk @ Aug 16 2013, 11:42) *
Все быстро делает РС, но вот битовый поток быстро обработать не может...

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

Цитата(iosifk @ Aug 16 2013, 11:42) *
проблемы с временем доставки сообщений?

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

Сам им уже давно пользуюсь как для связи между МК, так и между МК и ПК.
iosifk
Цитата(Огурцов @ Aug 16 2013, 15:57) *
да ничего не дано, это было дано, когда отправляли
а когда пришло, там может быть чёрте-что, битая длина, лишний конец пакета в середине пакета или наоборот пара склеенных пакетов

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

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

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



Цитата(iosifk @ Aug 16 2013, 12:38) *
В облаке плазмы?

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

Цитата(iosifk @ Aug 16 2013, 12:38) *
если вводится тайм-аут между пакетами...

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

Цитата(iosifk @ Aug 16 2013, 12:38) *
Наверняка разовая поделка

наверняка
krux
посмотрете G.7041/Y.1303 aka GFP, там много интересного.
любая топология, хочешь - точка-точка, хочешь - точка-многоточка, хочешь - кольцо.
Вот только не для микроконтроллера это.

Для МК имхо лучше всего что-то в духе:

DWORD barker-like start sequence
WORD DestSlave + WORD OpCode
DWORD Length
DWORD Header CRC16
DWORD Data1
DWORD Data2
...
DWORD DataLast
DWORD Payload CRC16
Огурцов
Цитата(Dr.NoA @ Aug 16 2013, 13:32) *
Советую использовать байтстаффинг по алгоритму Consistent Overhead Byte Stuffing

огромное респектище
даже если я не понял суть этого, то устранение "вредных" кодов в принципе возможно
причем не только одного, типа 0x00, но и нескольких, например, 0x00, 0xff, плюсом по байту на каждый код

еще что-то на тему cobs www.inescporto.pt/~jsc/publications/conferences/2007JaimeICC.pdf
Огурцов
из BABS следует интересная вещь - если длина пакета не превышает 176 байт, при одном флаге, для кодирования достаточно одного дополнительного _бита_
понятно, что один бит вполне реально расположить где-то в заголовке, не прибегая к добавлению целого байта
кроме того, весьма красиво добавляется любое необходимое количество флагов
например, для двух флагов и одного дополнительного бита длина пакета может достигать 88 байтов
для трех флагов - 58 байт
для четырех - 43
во всех этих случаях длина пакета вполне достаточна для передачи по rs232
Огурцов
есть ли какой быстрый способ разделить длинное число на 255 (или 254, 253...)
пока я нашел, что первый (младший) остаток от деления равен сумме всех байт

Огурцов
Код
B = 256
N0 = X0*B^0 + X1*B^1 + X2*B^2 + X3*B^3
m0 = X0 + X1 + X2 + X3
M0 = m0 mod (B - 1)
C0 = (m0 - M0) / B

N1 = (N0 - M0) / (B - 1)

N1 = (X0*B^0 + X1*B^1 + X2*B^2 + X3*B^3 - M0) / (B - 1)
N1 = (X0*B^0 + X1*B^1 + X2*B^2 + X3*B^3 - M0) / B / ((B - 1) / B )
N1 = (X1*B^0 + X2*B^1 + X3*B^2 - C0) / ((B - 1) / B )
N1 = (X1*B^0 + X2*B^1 + X3*B^2 - C0) / (1 - 1 / B )
m1 = (X1 + X2 + X3 - C0) / (1 - 1 / B )

и т.д.

вот, вроде бы красиво, сложность линейна, но что бы такое сделать с (1 - 1 / В ) ?
Огурцов
новый формат пакета c учетом предложений

CODE

// byte # 0
// 0.7 destination address presence
// 0.6 source address presence
// 0.5 stuff bit (babs) / stuff byte presence (cobs-r)
// 0.4 crc size.1
// 0.3 crc size.0
// 0.2 paket id.2
// 0.1 paket id.1
// 0.0 paket id.0

// [byte # 1]
// 1.7 destination address.7
// 1.6 destination address.6
// 1.5 destination address.5
// 1.4 destination address.4
// 1.3 destination address.3
// 1.2 destination address.2
// 1.1 destination address.1
// 1.0 destination address.0

// [byte # 2]
// 2.7 source address.7
// 2.6 source address.6
// 2.5 source address.5
// 2.4 source address.4
// 2.3 source address.3
// 2.2 source address.2
// 2.1 source address.1
// 2.0 source address.0

// byte # 3
// 3.7 command.7
// 3.6 command.6
// 3.5 command.5
// 3.4 command.4
// 3.3 command.3
// 3.2 command.2
// 3.1 command.1
// 3.0 command.0

// [byte # 4]

// 4.7 stuff byte.7
// 4.6 stuff byte.6
// 4.5 stuff byte.5
// 4.4 stuff byte.4
// 4.3 stuff byte.3
// 4.2 stuff byte.2
// 4.1 stuff byte.1
// 4.0 stuff byte.0

// byte # [5..n - 5]
// 5.7 data.7
// 5.6 data.6
// 5.5 data.5
// 5.4 data.4
// 5.3 data.3
// 5.2 data.2
// 5.1 data.1
// 5.0 data.0

// [byte # n - 4]
// n-4.7 crc31 stuff bit
// n-4.6 crc31.30
// n-4.5 crc31.29
// n-4.4 crc31.28
// n-4.3 crc31.27
// n-4.2 crc31.26
// n-4.1 crc31.25
// n-4.0 crc31.24

// [byte # n - 3]
// n-3.7 crc31.23
// n-3.6 crc31.22
// n-3.5 crc31.21
// n-3.4 crc31.20
// n-3.3 crc31.19
// n-3.2 crc31.18
// n-3.1 crc31.17
// n-3.0 crc31.16

// [byte # n - 2]
// n-2.7 crc31.15/crc15 stuff bit
// n-2.6 crc31.14/crc15.14
// n-2.5 crc31.13/crc15.13
// n-2.4 crc31.12/crc15.12
// n-2.3 crc31.11/crc15.11
// n-2.2 crc31.10/crc15.10
// n-2.1 crc31.9/crc15.9
// n-2.0 crc31.8/crc15.8

// [byte # n - 1]
// n-1.7 crc31.7/crc15.7/crc7 stuff bit
// n-1.6 crc31.6/crc15.6/crc7.6
// n-1.5 crc31.5/crc15.5/crc7.5
// n-1.4 crc31.4/crc15.4/crc7.4
// n-1.3 crc31.3/crc15.3/crc7.3
// n-1.2 crc31.2/crc15.2/crc7.2
// n-1.1 crc31.1/crc15.1/crc7.1
// n-1.0 crc31.0/crc15.0/crc7.0

// byte # n
// n.7 stop bit, 1
// n.6 stop bit, 1
// n.5 stop bit, 1
// n.4 stop bit, 1
// n.3 stop bit, 1
// n.2 stop bit, 1
// n.1 stop bit, 1
// n.0 stop bit, 1


минимальная длина пакета - 2 байта (заголовок и команда) + разделитель пакетов 1 или 2 байта, в зависимости от дуплекс/симплекс
адаптируется под:
безадресный режим
мастер-слейв
слейвы с прерываниями
каждый с каждым
произвольную длину данных
размер crc: crc0/crc7/15/31 бит
содержит номер пакета

как-то так
Огурцов
Цитата(Огурцов @ Aug 18 2013, 13:17) *
размер crc: crc0/crc7/15/31 бит

меня терзают смутные сомнения - не хорошо совсем без crc, какая бы команда не была
по сему оставлю crc7 и crc31 или скорее crc8 и crc32 со стаффингом crc в освободившийся бит
либо со стаффингом вместе с данными
первый способ несколько предпочтительнее, ибо дает возможность проверить пакет до распаковываия данных
Огурцов
на 255 оказывается флетчер делил, искал остаток от деления
а вот частное, похоже, не искал (
к математикам чтоли сходить
Nixon
Вы бы написали что-то подобное статье - думаю многим было бы интересно. Потом и протокол в свою честь назвать бы могли sm.gif
Огурцов
Цитата(Nixon @ Aug 20 2013, 19:55) *
Вы бы написали что-то подобное статье - думаю многим было бы интересно. Потом и протокол в свою честь назвать бы могли sm.gif

какой-то обмен уже запустил - могу назвать, и без статьи
в общем-то описание дано выше, вы спрашивайте более конкретно
остается решить задачу по оптимизации стаффинга по babs, было бы вообще красиво
Огурцов
немного допиленный под этот формат список команд из позапрошлой жизни

CODE

#define Bus_resynch 0x00 // 0x00

// Bus_system_command
#define Bus_system_reset 0x10 // H 0x10 C R
#define Bus_system_start 0x11 // H 0x11 C R
#define Bus_system_config 0x12 // H 0x12 C R
#define Bus_system_wakeup 0x13 // H 0x13 C R
#define Bus_system_sleep 0x14 // H 0x14 C R
#define Bus_system_standby 0x15 // H 0x15 C R
#define Bus_system_set_time 0x16 // H 0x16 C-C-C-C T-T-T-T D-D-D-D C R
#define Bus_system_set_bitrate 0x17 // H 0x17 B-B-B-B C R
#define Bus_system_set_address 0x18 // H 0x18 U-U-U-U-U-U-U-U-U-U-U-U-U-U-U-U A C R
#define Bus_system_enumeration 0x19 // H 0x19 M-M-M-M-M-M-M-M-M-M-M-M-M-M-M-M C R

// Bus_pipe_command
#define Bus_pipe_a 0x1A // H 0x1A D..D C R
#define Bus_pipe_b 0x1B // H 0x1B D..D C R
#define Bus_pipe_c 0x1C // H 0x1C D..D C R
#define Bus_pipe_d 0x1D // H 0x1D D..D C R

// Bus_device_command
#define Bus_device_loopback 0x21 // H 0x21 A D..D C R
#define Bus_device_read_config 0x22 // H 0x22 A A-A-A-A C R
#define Bus_device_write_config 0x23 // H 0x23 A A-A-A-A D..D C R
#define Bus_device_simulate_flash 0x24 // H 0x24 A A-A-A-A D..D C R
#define Bus_device_write_flash 0x25 // H 0x25 A A-A-A-A D..D C R
#define Bus_device_check_flash 0x26 // H 0x26 A A-A-A-A D..D C R

#define Bus_user_command_mask 0x40
#define Bus_answer_mask 0x80

Огурцов
еще интересная фича по флетчеру - для получения остатка от деления на 255 массив можно складывать не только по байтам, но и словами, а только затем байтами

kolobok0
Цитата(Огурцов @ Aug 22 2013, 00:03) *
...для получения остатка от деления на 255...


OFF:
При опросе различных датчиков, с АЦП и им подобных, рекомендую расчётную формулу умнажать на 56535 (слово), и затем смело "делить" методом отбрасывания двух байт. Собственно этот подход стар как мир МК.
Огурцов
65535
kolobok0
Цитата(Огурцов @ Aug 23 2013, 09:49) *
65535


угумс. очепятался.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.