как определить конец пакета ? Опции

[Огурцов]

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

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

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

[iosifk]

один мастер - много слейвов
формат пакета простейший: первый байт длина/направление, второй - команда/адрес, затем данные, затем 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]

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

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

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

[Огурцов]

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

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

[kolobok0]

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

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

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

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

[Огурцов]

эээээээ как бы это дано

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

Ну и кто мешает в стаффинг ввести байт, показывающий повторы?

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

Все быстро делает РС, но вот битовый поток быстро обработать не может...

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

проблемы с временем доставки сообщений?

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

[Dr.NoA]

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

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

[Огурцов]

Советую использовать байтстаффинг по алгоритму Consistent Overhead Byte Stuffing

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

еще что-то на тему cobs www.inescporto.pt/~jsc/publications/conferences/2007JaimeICC.pdf

Сообщение отредактировал Огурцов - Aug 17 2013, 06:49

[Огурцов]

из 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 / В ) ?

Сообщение отредактировал Огурцов - Aug 18 2013, 09:37

[Огурцов]

новый формат пакета 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 бит
содержит номер пакета

как-то так

[Огурцов]

размер crc: crc0/crc7/15/31 бит

меня терзают смутные сомнения - не хорошо совсем без crc, какая бы команда не была
по сему оставлю crc7 и crc31 или скорее crc8 и crc32 со стаффингом crc в освободившийся бит
либо со стаффингом вместе с данными
первый способ несколько предпочтительнее, ибо дает возможность проверить пакет до распаковываия данных