Вопрос по формату кадра 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]

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

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

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

Да.

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

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

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

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

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

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