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

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

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

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

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


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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

Да.

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

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

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

Я читал достаточно внимательно. Но подумайте, что будет, если байт начала пакета 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-й бит, а приёмник этого даже не заметит и его программу менять не надо. Экономия? Да.. Вместо переделки двух программ и/или железа - переделка программы одного девайса

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

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

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

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


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

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

Извеняюсь может не в тему. Вот здесь проект 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;
}

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

Именно так.

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


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

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

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

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

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

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

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

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

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

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



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

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

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