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

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

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

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

[=GM=]

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

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

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

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

[Dog Pawlowa]

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

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

[zltigo]

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

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

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

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

[Dog Pawlowa]

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

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

[zltigo]

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

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

[Dog Pawlowa]

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

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

[zltigo]

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

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

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

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

[=GM=]

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

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

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

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

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

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

[zltigo]

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

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

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

Да.

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

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

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

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

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

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

[=GM=]

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

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

[zltigo]

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

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

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

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