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

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

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

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

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


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


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

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

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

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

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

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

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



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


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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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


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

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

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

Например

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

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

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

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

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

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


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

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

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