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

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

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

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

[Dog Pawlowa]

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

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

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

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

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

[Igor26]

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

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

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

У меня ...

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

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

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

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

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

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

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

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

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

[=GM=]

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

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

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

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

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

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

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

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

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

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

Например

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

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