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

[Огурцов]

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

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

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

[Alex11]

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

[Warlockwolf]

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

[Огурцов]

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

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

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

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

[редактор]

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

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

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

[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) вообще уйти от этого нафик, на более верхний уровень (изернет и иже. правда там уже логический уровень - целостность данных всё равно останется)

[iosifk]

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

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

[Огурцов]

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

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

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

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

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

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

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

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

[Dr.NoA]

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

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

[iosifk]

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

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

[Огурцов]

Consistent Overhead Byte Stuffing

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

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

В облаке плазмы?

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

если вводится тайм-аут между пакетами...

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

Наверняка разовая поделка

наверняка

[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

[Огурцов]

Советую использовать байтстаффинг по алгоритму 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 в освободившийся бит
либо со стаффингом вместе с данными
первый способ несколько предпочтительнее, ибо дает возможность проверить пакет до распаковываия данных

[Огурцов]

на 255 оказывается флетчер делил, искал остаток от деления
а вот частное, похоже, не искал (
к математикам чтоли сходить

[Nixon]

Вы бы написали что-то подобное статье - думаю многим было бы интересно. Потом и протокол в свою честь назвать бы могли

[Огурцов]

Вы бы написали что-то подобное статье - думаю многим было бы интересно. Потом и протокол в свою честь назвать бы могли

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


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

[Огурцов]

немного допиленный под этот формат список команд из позапрошлой жизни

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]

...для получения остатка от деления на 255...

OFF:
При опросе различных датчиков, с АЦП и им подобных, рекомендую расчётную формулу умнажать на 56535 (слово), и затем смело "делить" методом отбрасывания двух байт. Собственно этот подход стар как мир МК.

[Огурцов]

65535

[kolobok0]

65535

угумс. очепятался.