Вопрос по формату кадра UART в ATmega-х, Может быть одновременно и Bit8 и P Опции

[Дон Амброзио]

Тут с одним поспорили. Он говорит, что по даташифту в кадре UART не может быть более 9 бит. Я же говорю, что может быть 10 (имеется ввиду информационных бит, а не служебных). А он говорит, что нельзя использовать в кадре сразу и Bit8 и бит чётности - P. А я говорю, что можно. Кто прав?

ST + Bit0 + Bit1 + Bit2 + Bit3 + Bit4 + Bit5 + Bit6 + Bit7 + Bit8 + P + SP1 + SP2

[Aesthete Animus]

Тут с одним поспорили. Он говорит, что по даташифту в кадре UART не может быть более 9 бит. Я же говорю, что может быть 10 (имеется ввиду информационных бит, а не служебных). А он говорит, что нельзя использовать в кадре сразу и Bit8 и бит чётности - P. А я говорю, что можно. Кто прав?

ST + Bit0 + Bit1 + Bit2 + Bit3 + Bit4 + Bit5 + Bit6 + Bit7 + Bit8 + P + SP1 + SP2

Ну а что вам мешает прошить мегу нужным кодом и пощупать осцилографом, что же она все-таки шлет?

[Дон Амброзио]

Ну а что вам мешает прошить мегу нужным кодом и пощупать осцилографом, что же она все-таки шлет?

Прошил... Уже лет 5 юзаю формат какой я описал выше.... Только может в новых Мегах чё изменилось про которые я пока не в курсе? Как например я не знал, что в новых можно пины инвертировать одной командой out PinX, Maska

[SasaVitebsk]

В ATMega полный USART, в отличие от 89с51

• Supports Serial Frames with 5, 6, 7, 8, or 9 Databits and 1 or 2 Stop Bits
• Odd or Even Parity Generation and Parity Check Supported by Hardware

В at90s8515 был несколько урезанный. В результате для формирования 7 битной передачи пришлось городить огород.

[=GM=]

Бит паритета, кстати, это не информационный, а служебный бит.

[Дон Амброзио]

Бит паритета, кстати, это не информационный, а служебный бит.

Им и инфу можно передавать меняя нужным образом функцию с "бит чётности" на "бит нечётности" и наоборот

[=GM=]

Им и инфу можно передавать меняя нужным образом функцию с "бит чётности" на "бит нечётности" и наоборот

Нельзя так передавать, поскольку бит паритета формируется Исключающим ИЛИ из передаваемых бит данных, следовательно, не является независимой величиной.

Кстати уж, откуда вы извлекаете бит паритета на приёмной стороне?

[Dog Pawlowa]

Им и инфу можно передавать меняя нужным образом функцию с "бит чётности" на "бит нечётности" и наоборот

Можно, док. Так и делают люди, желающие секса.

[zltigo]

Так и делают люди, желающие секса.

Ну иногда и не желающие оного, например, для отметки этим девятым битом начал фреймов для простейших микроскопических протоколов, когда SLIPообразные тяжеловаты для перифериных контроллеров а то и вообще чистых железок.

..поскольку бит паритета формируется Исключающим ИЛИ из передаваемых бит данных, следовательно, не является независимой величиной.

Обычно можно перепрограммировать контроллер и для передачи/приема фиксированного бита четности (mark/space).

[Дон Амброзио]

Нельзя так передавать, поскольку бит паритета формируется Исключающим ИЛИ из передаваемых бит данных, следовательно, не является независимой величиной.

В нормальных контроллерах можно варьировать функцию этого бита:
можно генерить как бит чётности, так и бит нечётности - т.е. можно сформировать любое требуемое Вам значение. Хотя конечно при формировании и выборе функции чётность/нечётность разумеется следует учитывать значения всех остальных бит байта

Кстати уж, откуда вы извлекаете бит паритета на приёмной стороне?

Из флага ошибки чётности

[Dog Pawlowa]

Ну иногда и не желающие оного, например, для отметки этим девятым битом начал фреймов для простейших микроскопических протоколов...

Не знаю-не знаю. Есть стандартные символы STX, ETX, ETB, ENQ... В трех десятках протоколов с которыми мне приходилось разбираться, никто иначе не делал.
Кстати, применение этих символов регламентируется ENxxxxx, низзя Вам нарушать.
"Мне - можно" Но я так никогда не буду делать.
Да и потеря быстродействия может быть критична.

[Дон Амброзио]

Да и потеря быстродействия может быть критична.

Уважаемая "Собака Павлова"!!!!
Потеря быстродействия в Вашем случае несравнимо больше, поскольку Вы передаёте данные в ASCII-формате, а я в бинарном

[Dog Pawlowa]

Уважаемая "Собака Павлова"!!!!
Потеря быстродействия в Вашем случае несравнимо больше, поскольку Вы передаёте данные в ASCII-формате, а я в бинарном

Доктор,
я то знаю, что Вам больше нечего делать, как людей на флейм разводить.
Я поработаю, а Вы подумайте о том, что есть быстродействие, и ... быстродействие.

[Дон Амброзио]

Доктор,
я то знаю, что Вам больше нечего делать, как людей на флейм разводить.
Я поработаю, а Вы подумайте о том, что есть быстродействие, и ... быстродействие.

Я подумал ещё когда писал Вам предыдущий пост.
Объясняю. Если передавать данные в бинарном формате у меня девайс за секунду успевает опросить 12 датчиков. А если в ASCII-формате, то только 7. Потеря быстродействия налицо... Я не прав?

[Igor26]

Я подумал ещё когда писал Вам предыдущий пост.
Объясняю. Если передавать данные в бинарном формате у меня девайс за секунду успевает опросить 12 датчиков. А если в ASCII-формате, то только 7. Потеря быстродействия налицо... Я не прав?

Да уж...
У меня хост четыре раза в секунду опрашивает 16 устройств, на борту у которых от 16-ти датчиков, плюс исполнительные всякие там механизмы и прочая периферия. Времени хватает и опрашивать состояния устройств (не только датчики), но и управлять этими устройствами. Скорость обмена - 9600.
Так что прав Dog Pawlowa. Нужно шире ДУМАТЬ, а не хвататься за "верхушки". Да плюс еще флейм/флуд в конференциях разводить.

[zltigo]

..никто иначе не делал.

Все когда-то "иначе не делалость", до того, как кто-то взял и сделал. Напомню, что я речь веду не о массированной передаче информации маханием 9 битом через заднепроходное отверстие, а эпизодическом использовании 9 бита для, например, отметок начала фреймов.

[Dog Pawlowa]

Все когда-то "иначе не делалость", до того, как кто-то взял и сделал. Напомню, что я речь веду не о массированной передаче информации маханием 9 битом через заднепроходное отверстие, а эпизодическом использовании 9 бита для, например, отметок начала фреймов.

Нет, напоминание не требуется, ув. zltigo
А с идеей все равно не соглашусь. Хотя бы из соображений подключения других устройств (платформы, прослушки, конвертеры интерфейсов).

[zltigo]

А с идеей все равно не соглашусь.

Никогда-никогда? Например, среди самодельщиков протоколов (меня это не нравится и я даже пару раз с таким подходом резко спорил)очень популярно посылать бинарные фреймы ввиде, например,
<0x55><размер><тело....> при этом при потерях начинается поиск маркера <0x55>, соответственно ложные синхронизации и понеслось... Теперь слека усовершенствуем - посылаем Маркер <0x55> со сбитой четностью получаем УНИКАЛЬНЫЙ разделитель в чисто бинарном потоке - синхронизироваться становится легко, собственно и размер можно исключить. Да, конечно есть, например, классические SLIPобразные протоколы, UUEобразные,..но тем не менее и это вполне жизненный вариант.

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

Что такое "платформы" не понял, но прослушки будут работать, а конверторы либо должны знать конвертируемые протоколы, либо соответственно накладывать ограничения на то, что конвертирут. Ну
и системы без конверторов тоже имеют право на существование

[Dog Pawlowa]

Никогда-никогда? Например, среди самодельщиков протоколов...

Сам отношусь к самодельщикам протоколов. Но бинарные - только в формате STX data ETX/ETB checksum. Бывает грешок - в текстовых вместо служебных использую читаемые символы.
Да, есть проблемы с прозрачностью передачи текста, но их правильнее решать байт-стаффингом, а не 9-ым битом.

Что такое "платформы" не понял, но прослушки будут работать, а конверторы либо должны знать конвертируемые протоколы, либо соответственно накладывать ограничения на то, что конвертирут.

Если я могу использовать X-Port или покупной расширитель USB - 4 COM, это большой плюс, я считаю. А если нет, соответственно большой минус.
А платформы я имел ввиду микроконтроллерные. УАРты разные, а проекты такие живучие бывают, никак не умирают, приходится переводить на другие типы контроллеров.

Ну и системы без конверторов тоже имеют право на существование

Ага. Но так лениво думать, что происходит в системе, если можно просто посмотреть.

[=GM=]

...я речь веду не о массированной передаче информации маханием 9 битом через заднепроходное отверстие, а эпизодическом использовании 9 бита для, например, отметок начала фреймов

В атмелах есть штатная фича Multi-processor Communication mode (MPCM), которую можно использовать для фильтрации входящих фреймов. Установлен 9-й бит, значит принят адрес (начало пакета), не установлен - значит входной байт игнорируется, ждём следующего.

...среди самодельщиков протоколов очень популярно посылать бинарные фреймы в виде, например, <0x55><размер><тело....> при этом при потерях начинается поиск маркера <0x55>, соответственно ложные синхронизации и понеслось...

Уточните, потери чего? Пакета? И из-за чего? Из-за сбоя в линии передачи или недостатка времени на обработку? Если из-за недостатка времени, то плохо спроектирована программа или система, мы это не рассматриваем. Если из-за сбоя в линии, то значит необходим контроль ошибок. А паритет - это и есть нулевой уровень контроля, крайне нежелательно использовать его не по назначению.

Теперь слегка усовершенствуем - посылаем Маркер <0x55> со сбитой четностью получаем УНИКАЛЬНЫЙ разделитель в чисто бинарном потоке - синхронизироваться становится легко, собственно и размер можно исключить

Проблема синхронизации давно решена байт-стаффингом для байт-ориентированных протоколов и бит-стаффингом для бит-ориентированных. Или можно применить MPCM какой-нибудь. Если вопрос серьёзный и/или помеховая обстановка плохая, то ставят синхрослово подходящей длины. Я тут на форуме уже рассказывал, у меня в одном проекте было синхрослово длиной 288 бит. Можно и м-последовательность замутить длиной 4096 или около того, зависит от задачи.

[Дон Амброзио]

У меня ...

Не надо хвастаться, потому что:
во-первых за это банят (когда я тоже как и Вы только упомянул, что у меня реализовано так-то и так-то, так сразу же последовало предупреждение);

а во-вторых, тот пример, который я приводил, взят мной чиста для иллюстрации своей мысли и никакого отношения к моим реальным разработкам он не имеет. Потому что если бы я сказал слово "а у меня", то меня тут же бы обвинили в хвастовстве и забанили... Пожтому о своих разработках я промолчу

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

Так что прав Dog Pawlowa. Нужно шире ДУМАТЬ, а не хвататься за "верхушки". Да плюс еще флейм/флуд в конференциях разводить.

Вот и не хватайтесь... Вот и не разводите... А то других учить мы мастера, а сами не выполняем того, чему других учим

А паритет - это и есть нулевой уровень контроля, крайне нежелательно использовать его не по назначению.

Ну если у Вас есть CRC16 на хвосте, то побайтовый онтроль чётности, ИМХО, уже лишнее. Конечно если Вам не важно как можно более раннее обнаружение ошибки.

А так .. Ну не обнаружу я что у меня 3-й байт 24-х байтного пакета покоцался в момент окончания передачи 3-го байта.. И что... После приёма всех 24-х байт я всё равно обнаружу что пакет коцаный

Сообщение отредактировал Дон Амброзио - Mar 20 2008, 13:18

[zltigo]

Уточните, потери чего? Пакета?

Потери/Искажения Байта.

И из-за чего? Из-за сбоя в линии передачи

Да.

Если из-за сбоя в линии, то значит необходим контроль ошибок.

Естественно, ну и что?

А паритет - это и есть нулевой уровень контроля, крайне нежелательно использовать его не по назначению.

Если-бы ВНИМАТЕЛЬНО прочитали хотя-бы пример, то поняли, что паритет остается совершенно штатно рабочим во время передачи тела фрейма.

Проблема синхронизации давно решена байт-стаффингом для байт-ориентированных протоколов и бит-стаффингом для бит-ориентированных.

Это Вы мне? Зачем, если я об этом сам дважды поминал?

[=GM=]

Если-бы ВНИМАТЕЛЬНО прочитали хотя-бы пример, то поняли, что паритет остается совершенно штатно рабочим во время передачи тела фрейма

Я читал достаточно внимательно. Но подумайте, что будет, если байт начала пакета 0х55 передастся с ошибкой? Паритет на приёме изменится, станет правильным, и вы потеряете пакет. А что будет, если байт 0х55 в пакете передастся с ошибкой? Вы захватитесь за ложное начало пакета и потеряете настоящий. Ну и еще масса вариантов есть, когда ваш пример протокола будет глючить.

[zltigo]

Я читал достаточно внимательно. Но подумайте, что будет, если байт начала пакета 0х55 передастся с ошибкой? А что будет, если байт 0х55 в пакете передастся с ошибкой?

Тогда он не будет 0x55 . И речь идет не о предложении некого чудесного протокола на parity, который позволит избежать ошибок, а о выходе из ситуации после потери фреймовой синхронизации быстрее и минимальными потерями пакетов.

Ну и еще масса вариантов есть, когда ваш пример протокола будет глючить.

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

[galjoen]

Но подумайте, что будет, если байт начала пакета 0х55 передастся с ошибкой?

Ради примера могу предложить началом пакета приём байта с ошибкой стоп бита считать. С помощью изложенных в этой теме способов сформировать байт с правильной чётностью, но с 0м на месте стоп бита. Для этого понадобится 10 бит данных. Т.е. 9 бит собственно данных, а 10й бит - использованный в извращённой форме бит чётности =0. Тогда приёмник примет 8 бит данных передатчика, 9й бит данных передатчика приёмник примет как бит чётности (верный - таким он был сформирован при передаче), а бит чётности передатчика, сформированный =0, примет как ошибку формата. В таком случае лучше 1й байт делать равным не 0x55, а длине пакета - нет, тут я конечно погорячился.
Я бы конечно так делать не стал. Но если начало пакета байтом с ошибкой чётности отмечают, то с ошибкой формата - способ лучше.

[=GM=]

Тогда он не будет 0x55 . И речь идет не о предложении некого чудесного протокола на parity, который позволит избежать ошибок, а о выходе из ситуации после потери фреймовой синхронизации быстрее и минимальными потерями пакетов

Естественно. Речь идёт о том, что в линии с ошибками подобный протокол слабо помогает, если не сказать больше.

Не так написал, пусть будет так. Передаёте 0x55 с искажённым паритетом, как начало пакета. Налетела помеха и сбила паритет, считайте, пакет потерян.

Далее, в следующем пакете передаётся 0x57 в теле пакета, налетела ошибка на 5-й бит, вместо 0x57 стало 0x55, да и паритет изменился, следовательно мы зацепились за ложное начало пакета. Да вы и сами можете придумать парочку вариантов. Или вот, скажем, одна помеха длительностью в один бит, испортила сразу два рядом стоящих бита.

Ну если у Вас есть CRC16 на хвосте, то побайтовый контроль чётности, ИМХО, уже лишнее. Конечно если Вам не важно как можно более раннее обнаружение ошибки. А так .. Ну не обнаружу я что у меня 3-й байт 24-х байтного пакета покоцался в момент окончания передачи 3-го байта.. И что... После приёма всех 24-х байт я всё равно обнаружу что пакет коцаный

К слову сказать, CRC16 иногда тоже не спасает. Применение бит паритета идёт с давних времён, причём, не отдельно само по себе, а в сочетании с контрольной суммой, которая была просто суммой передаваемых байт, без учета переносов. Таким образом осуществлялся контроль по "строкам" и "столбцам", как в бухгалтерии. Отдельное применение бита паритета в наше время - это нонсенс.

Использование вами бита паритета для передачи дополнительного бита данных ещё больший нонсенс, поскольку существенно увеличивает время обработки, существенно затрудняет отладку, не позволяет вести дуплексный обмен и т.д. И вообще это ночной кошмар разработчика. Вы меня извините, ничего личного, но за одно это вас гнать надо в шею из программистов, и как можно быстрее. А я всё думаю, что это пожары в Москве участились...

[Дон Амброзио]

Вы меня извините, ничего личного, но за одно это вас гнать надо в шею из программистов, и как можно быстрее. А я всё думаю, что это пожары в Москве участились...

Злой Вы какой-то... В нашей работе эмоциям не место... А потом просто/сложно понятия относительные и зависят от уровня знаний и профессионализма разработчика.... Если мне надо, то я из чего угодно сделаю что угодно... Если потребуется использовать бит чётности как 9-й бит, то я его буду использовать и не буду "упираться рогами" что мол это не правильно. И я не плохой танцор и мне ничего не мешает, в отличии от некоторых, а наоборот, мне всё помогает. Я любую особенность железа могу использовать в своих целях.

Например

когда у меня приёмник имеет UART, умеющий работать в режиме фильтрации адресных кадров, а передатчик не может генерить 9-й бит но может бит чётности.. Выход... Использовать в программе передатчика бит чётности как 9-й бит, а приёмник этого даже не заметит и его программу менять не надо. Экономия? Да.. Вместо переделки двух программ и/или железа - переделка программы одного девайса

Сообщение отредактировал Дон Амброзио - Mar 20 2008, 15:26

[zltigo]

вместо 0x57 стало 0x55, да и паритет изменился, следовательно мы зацепились за ложное начало пакета.

Ужас. Только вот какя незадача - гипотетическому протоколу из приводимого мною примера наплевать на наличие 0x55 в теле пакета, хоть с верной parity, хоть с неверной. Никакого ложного начала пакета не будет. Последний раз напоминаю, что никаких ультраглобальных задач не ставится. Задача собственно декларирована мной в приведенном примере всего одна - быстрое и с миимальными потерями восстановление фреймовой сигнализации. Это работает.

[Dog Pawlowa]

Да.. Вместо переделки двух программ и/или железа - переделка программы одного девайса

Офф. Док, а когда Вы успели что-то сделать, что уже нужно переделывать ?

Давайте остановимся, ввиду явно видного интеллекта участников дискуссии (кто против?! ) подходы каждого понятны.

[Дон Амброзио]

Офф. Док, а когда Вы успели что-то сделать, что уже нужно переделывать ?

Вы всё подъё ...пардон, подкалываете... Не надоело? Что за мода отвечать не по существу вопроса а переходить на личности?
А вообще мне часто приходиться программно исправлять ляпы других горе-разработчиков, так что описанная мной выше задача вполне реальна..
Очень часто начальство приходит встаёт на колени и просит: "Спаси!!! Сделай хоть что-нибудь".. И делаю.. И спасаю

Давайте остановимся, ввиду явно видного интеллекта участников дискуссии (кто против?! ) подходы каждого понятны.

Давно пора.. Тем более что дискуссия давно уже ушла в сторону от темы.

Админ!!!! Проблема решена!!! Тему можно закрыть

Сообщение отредактировал Дон Амброзио - Mar 20 2008, 15:55

[Reton]

Извеняюсь может не в тему. Вот здесь проект http://www.microsyl.com/moodlight/moodlight.html в котором одно мастер-устройство управляет яркостью яркостью RGB-светодиодов, подключенных к слейв-устройствам. Используется какой-то простой протакол, но мне всеравно не совсем понятно, как формируется начало кадра и как каждое слейв-устройство выделяет свой адрес. Насколько я понял вот кусок кода отвечающий за это:
void SerialRx(void)
{
static int Pointer;
ushort Byte;

Pointer++;

if (UCR & (1<<RXB8))
{
Pointer = 0;
Byte = UDR;
}

if (Pointer == ((Address * 3) - 2)) Red = UDR;
else if (Pointer == ((Address * 3) - 1)) Green = UDR;
else if (Pointer == ((Address * 3) - 0)) Blue = UDR;
else Byte = UDR;
}

[IgorKossak]

Админ!!!! Проблема решена!!! Тему можно закрыть

По идее автор темы сам может её закрыть. Или я кое-что подзабыл? Посмотрите внимательно есть ли ы Вас такая возможность.
Будете настаивать - закрою, но по-моему продолжение пошло.

[WHALE]

насколько я ничего не понимаю,это как раз использован режим UARTа MPCM.Взведен 9 бит
if (UCR & (1<<RXB8)) -пришел маркер начала фрейма.А вот дальше не совсем понятно-ху есть Address?
В коде намеков не просматривается,где-то он должен фигурировать в другом месте,поищите.
Понятно только,что посылки кратны 3.

[=GM=]

Используется какой-то простой протокол, но мне все равно не совсем понятно, как формируется начало кадра и как каждое слейв-устройство выделяет свой адрес

Мне кажется, здесь всё достаточно прозрачно. Каждый слейв имеет свой собственный адрес, который находится в переменной Address. По приходу байта с взведённым RXB8=1, все слейвы сбрасывают указатель Pointer в 0. Начиная со следующего байта слейвы увеличивают указатель и сравнивают номер байта со своим утроенным адресом (плюс 0, плюс 1 и плюс 2). При совпадении принятый байт попадает в соответствующую переменную (Red, Green, Blue). Вот и весь протокол.

[SasaVitebsk]

По-моему, это всё с х51 пошло. Именно там 9 бит пошёл как информационный, для упрощения. Аппаратная чётность там была только для аккумулятора. То есть при таком подходе этот бит можно было заюзать под чётность. Но, соответственно можно было и заюзать как самостоятельный бит. Ну и некоторые повелись в связи с простотой картины. Хотя, при размере фрейма 512 байт, к примеру, избыточность такого подхода составит 512 бит, что соответствует 64 байтам. Что явно превышает избыточность любого протокола с байт стафингом.

Я один раз, уже на AVR применял такой подход, так как до этого применял параллельный 9 битный интерфейс (один бит - указатель комманды). А потом, с целью экономии ног перешёл к последовательному интерфейсу. А бит остался. Следующий переход - SPI+байт потери -> вообще перенёс всё в один МК.

Всё таки считаю лучше применять стандартные решения.

[zltigo]

.. избыточность такого подхода составит 512 бит, что соответствует 64 байтам. Что явно превышает избыточность любого протокола с байт стафингом.

А контроль четности имеющийся при этом тоже заодно всегда к "избыточности" относите ?

Всё таки считаю лучше применять стандартные решения.

Лучше то, что лучше в конкретных условиях. Для связки с мелкой CPLD байтстафинг явно менее предподчтителен. Для связки вспомогательного контроллера с основным в пределах одной платы тоже следует подумать, причем и для случая SPI в том числе. Ну за SLIP, меня агитировать не надо - я и сам кого угодно сагитирую, если нужно будет, что даже на этом форуме не раз проделывал . Ну HDLC с его битстафингом это тоже близкое и родное для любого разработчика коммуникационного оборудования.

[svs39]

А контроль четности имеющийся при этом тоже заодно всегда к "избыточности" относите ?

Лучше то, что лучше в конкретных условиях. Для связки с мелкой CPLD байтстафинг явно менее предподчтителен. Для связки вспомогательного контроллера с основным в пределах одной платы тоже следует подумать, причем и для случая SPI в том числе. Ну за SLIP, меня агитировать не надо - я и сам кого угодно сагитирую, если нужно будет, что даже на этом форуме не раз проделывал . Ну HDLC с его битстафингом это тоже близкое и родное для любого разработчика коммуникационного оборудования.

1) помогите-чем хорош SLIP?
2) HDLC- синхронный поток- достал в свое время (сделали в 1985г на серии 580 - до сих пор работает)

[Дон Амброзио]

Лучше то, что лучше в конкретных условиях.

Золотые слова.

Не существует той единственной "серебрянной пули", применение которой одинаково хорошо в любых условиях.

Выше я объяснял как кажущееся кое-кому извращением ( за которое инженера "нужно гнать поганой метлой из разработчиков") использование бита чётности в качестве обычного бита данных оказалось наиболее оптимальным решением для описанной мной конкретной задачи.

[SasaVitebsk]

А контроль четности имеющийся при этом тоже заодно всегда к "избыточности" относите ?

Я не имел ввиду конкетно Ваш пример. Я брал общий случай. Контроль чётности не применяю обычно. Но был случай, когда в битовом потоке применял код Хеминга. Естественно, необходимо учитывать специфику...

Лучше то, что лучше в конкретных условиях. Для связки с мелкой CPLD байтстафинг явно менее предподчтителен. Для связки вспомогательного контроллера с основным в пределах одной платы тоже следует подумать, причем и для случая SPI в том числе. Ну за SLIP, меня агитировать не надо - я и сам кого угодно сагитирую, если нужно будет, что даже на этом форуме не раз проделывал . Ну HDLC с его битстафингом это тоже близкое и родное для любого разработчика коммуникационного оборудования.

Я не за что не агитирую. Сам же пишу, что в разных случаях использовал разные подходы. Но, следует признать, что в повседневной практике, в рядовых приложениях, всётаки устоканиваются рядовые решения.

[zltigo]

1) помогите-чем хорош SLIP?

Классический пример байтстафинга, позволяющий в потоке (бинарном) байтов зарезервировать уникальный байт в качестве разделителя фреймов. Дальше естественно просто и надежно выделяются и востанавливаются фреймы в потоке. Есть более навороченные вариации на тему SLIP, позволяюшие еще минимизировать количество вставляемых байтов.

[Dog Pawlowa]

А контроль четности имеющийся при этом тоже заодно всегда к "избыточности" относите ?

Кстати, да.
По большому счету, наличие контроля четности имеет смысл, если это поддерживается протоколом, когда получатель может оборвать передающую сторону. А это бывает, по моей статистике, в 3% протоколов.
Если нет, да еще блоки данных большие, то при использовании более сложной CRC контроль четности каждого байта не нужен.

[Дон Амброзио]

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

Именно так.

Или если сама передающая сторона ведёт самоприём и при обнаружении покоцанного байта прекращает передачу - сама себя обрывает


Могу придумать только одно применение когда применение бита чётности имеет хоть какое-то значение при блочной/пакетовой передаче при отсутствии у передатчика и приёмника возможности обрывания передачи в случае обнаружения покоцанного байта.

Например, если передаётся большой пакет (например 1024 байта) с CRC32. А контроллер мелкий и он долго считает CRC. В этом случае обнаружение покоцанного байта позволяет избежать долгой и мучительной процедуры вычисления CRC32 для такого большого пакета... Но повторяю, это для "мелких" контроллеров с малым быстродействием

Сообщение отредактировал Дон Амброзио - Mar 21 2008, 07:47

[zltigo]

..наличие контроля четности имеет смысл, если это поддерживается протоколом

Трудно возразить - если поддерживается, то нужно, а если не поддерживается, то не нужно

, когда получатель может оборвать передающую сторону.

Или оборвать, или просто проигнорировать. И SLIP и CRC это конечно хорошо, и еще лучше (навороченей) есть и вообще нет и не будет предела совершеству. Но как минималистичный вариант поток байтов со старым, добрым, поддерживаемым аппаратно битом четности и c уникальным 9bit разделителем фреймов совершенно нормален и не является наказуемым извращением.

...да еще блоки данных большие, то...

Большие блоки данных - "большим устройствам" - копили, обрабатывали и послали и не дай бог пропадет труд. Для мелочевки это обычно не характерно - чаще сыпет хоть и много, но мелких. Если что случилось - проще заново спросить (или сам повторит), чем переспрашивать а чего-там было до того как...

[Igor26]

По-моему, это всё с х51 пошло.

Точно так! После х51 перешли на AVR, и для приемственности со старыми устройствами используем 9-й бит в том виде, как почти так описАл zltigo.

Золотые слова.

Не существует той единственной "серебрянной пули", применение которой одинаково хорошо в любых условиях.

+1. Полностью согласен.

А Вы посмотрите, как общаются между собой Люди. Как Вы определяете, что собеседник закончил фразу и настала очередь Вам отвечать? Собеседник выдержал паузу? Или он сказал - "Конец цитаты"? Или ему вообще нечего сказать?

[zltigo]

Точно так! После х51..

Нет - не надо все "валить" на 51 . Там просто подстраивались под необходимость с одной стороны его иметь, а с другой стороны сделать экстремально просто аппаратно. Например, "ручное" управление битом четности вполне естественно реализовано и на классических 8250 работающих начиная с 8080 и до всех нынешних PCшек.

[svs39]

Классический пример байтстафинга, позволяющий в потоке (бинарном) байтов зарезервировать уникальный байт в качестве разделителя фреймов. Дальше естественно просто и надежно выделяются и востанавливаются фреймы в потоке. Есть более навороченные вариации на тему SLIP, позволяюшие еще минимизировать количество вставляемых байтов.

почему не использовать более простой байтстафинг - удваивать в данных уникальный байт?

Именно так.

Или если сама передающая сторона ведёт самоприём и при обнаружении покоцанного байта прекращает передачу - сама себя обрывает
Могу придумать только одно применение когда применение бита чётности имеет хоть какое-то значение при блочной/пакетовой передаче при отсутствии у передатчика и приёмника возможности обрывания передачи в случае обнаружения покоцанного байта.

Например, если передаётся большой пакет (например 1024 байта) с CRC32. А контроллер мелкий и он долго считает CRC. В этом случае обнаружение покоцанного байта позволяет избежать долгой и мучительной процедуры вычисления CRC32 для такого большого пакета... Но повторяю, это для "мелких" контроллеров с малым быстродействием

бит четности в байте совместо с байтом "продольной" суммы использовался при матричной кодозащите, например, в протколах обмена ВМО(Всимирной Метеорологической Озганизации) в 1960-1980гг.

[zltigo]

почему не использовать более простой байтстафинг - удваивать в данных уникальный байт?

А подумать? Два уникальных байта подряд это и есть разделитель фреймов - конец предыдущено-начало следующего. Если вводить еще и размер, то это уже другая опера - и уникальный байт может спокойно при априори известном размере пакета, находится в любом месте.
SLIP это чисто потоковый протокол не требующий ни передачи размеров, ни каких либо дополнительных соглашений типа пауз/таймаутов... И передача может быть прервана в любой момент и БЫСТРО банальной посылкой конца и/или начала следующего фрейма.

[svs39]

А подумать? Два уникальных байта подряд это и есть разделитель фреймов - конец предыдущено-начало следующего. Если вводить еще и размер, то это уже другая опера - и уникальный байт может спокойно при априори известном размере пакета, находится в любом месте.
SLIP это чисто потоковый протокол не требующий ни передачи размеров, ни каких либо дополнительных соглашений типа пауз/таймаутов... И передача может быть прервана в любой момент и БЫСТРО банальной посылкой конца и/или начала следующего фрейма.

теперь дошло! Спасибо!