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

[Огурцов]

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