**орванное начало в RS232

[Deynekin]

Прелюдия. Обрывок газетного листа (ещё лучше: телеграфной ленты) читать более-менее всё-таки можно - потеряется только то слово, что пришлось на разрыв, т.к. есть выделенный символ - пробел,- который позволяет "восстановиться". То же в (традиционном) телевизоре: есть выделенные сигналы - конец строки и конец кадра,- которые ставят картинку на место, независимо от момента вхождения в связь. То же в морзянке: есть выделенные символы - паузы разной длины для "нарезания дроби" на отдельные символы и слова. (Общепринято: "тире" в три раза длинне "точки", внутри буквы точки/тире разделены интервалом длиной в точку; интервал между буквами - длиной в тире, между словами - в три тире). И т.д. - вплоть до пронумерованных страниц рассыпавшейся книги...

Иными словами, во всех подобных случаях есть дополнительные уникальные символы ответственные за интерпретацию потока, но которые, в то же время, информации, заключённой в потоке, как таковом, не несут - это, так сказать, "упаковочный материал", или лучше: они "над этим". (Зд. распахнутая дверь для спекуляций на тему о "Теореме Гёделя о неполноте".)

Но вот рассмотрим одну из допустимых реализаций формата данных в RS232: 8 bits, No parity, 1 Stop bit.

В этом случае на передачу одного 8-битного символа расходуются 10-битовый пакет: два дополнительных бита нужны для нарезания общего потока нулей/единиц на "правильные" байты. Делается это, конкретно, так: после каждого байта передаётся "Stop bit"=1, а признаком начала следующего байта служит т.н."Start bit": 0 с ему предшствующей 1.

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

Рассмотрим пример. Пусть передаётся последовательность:

...1010100100101010010010101001001010100100...

Она замечательна тем, что в ней каждый 0 с ему предшествующей 1 может быть принят за начальный Start bit пакета, т.к. каждый из них через восемь бит имеет 1 - вполне полноправный Stop bit. Поэтому, по-разному выделяя Start и Stop биты (напр., в зависимомти от того, когда подключились к потоку), её можно прочесть так:
...1010100100101010010010101001001010100100...
или так::
...1010100100101010010010101001001010100100...
или так:
...1010100100101010010010101001001010100100...
или так:
...1010100100101010010010101001001010100100...

Что даст для каждого из случаев, соответственно, следующие результаты:
...код35код35код35... = ...###...
...код73код73код73... = ...III...
...код81код81код81... = ...QQQ...
...код41код41код41... = ...)))...
-И всё это, повторим, в строгом соответствии с допустимым стандартом!

Вопрос: Как узнать, что передавалось "на самом деле": #, I, Q, )?

Дисклаймер. Сам я ответа на этот вопрос не знаю, а возможное грубое "решение" - прокладывать пакеты уникальными последовательностями из десяти 1 - отвергаю, как снижающее скорость передачи вдвое. Не предложит ли кто что-нибудь дельное?

[PavelM]

Если оторваться от чистой математики, в настоящем R232 стоп-бит "равнее" других, т.к. м. иметь длину в 1.5 и даже 2 периода, плюс к этому имеются управляющие сигналы.

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


А дополнительный вопрос можно?

- Принимаются ли в рассмотрение возможные помехи в канале?
- Важно ли ничего не потерять или приемлема некоторая вероятность?

[KP580BE51]

Вопрос: Как узнать, что передавалось "на самом деле": #, I, Q, )?

Никак.

[Deynekin]

Начиная с конца:

- Принимаются ли в рассмотрение возможные помехи в канале?
- Важно ли ничего не потерять или приемлема некоторая вероятность?

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

В настоящем R232 стоп-бит "равнее" других, т.к. м. иметь длину в 1.5 и даже 2 периода, плюс к этому имеются управляющие сигналы.

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

Резюме: Видимо, если оставаться строго в рамках поставленной задачи, придётся согласиться с приговором KP580BE51: "Никак!". - Ну что ж, отрицательный ответ - тоже ответ!
Или же, и в самом деле, использовать спецбайты, отыскивая приемлемый компромисс в том, как часто ими прокладывать основной текст.

[venco]

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

[KP580BE51]

Резюме: Видимо, если оставаться строго в рамках поставленной задачи, придётся согласиться с приговором KP580BE51: "Никак!". - Ну что ж, отрицательный ответ - тоже ответ!

Просто не для того протокол сделан. Синхронизация восстановится после паузы длиннее байта. А как восстановится, так и переспросить.

[Deynekin]

Просто не для того протокол сделан.

Не могли бы Вы подробнее пояснить, что значит "не для того сделан"?
Как выбрать (каким должен быть) протокол, который в данном случае был бы "для того"?

[KP580BE51]

Просто не для того протокол сделан.

Не могли бы Вы подробнее пояснить, что значит "не для того сделан"?
Как выбрать (каким должен быть) протокол, который в данном случае был бы "для того"?

Насколько я знаю, RS232 был сделан для телеграфии, и должен был он управлять полярными реле (отсюда и -15 +15) А в телеграфии часто присутствуют паузы.
Какой в данном случае нужен протокол, я не знаю, потому что не знаю что вам нужно. 8/10 кажись самосинхронизирующийся протокол. Если нужно восстановление ошибок, то Витерби кодирование вам поможет.

[Deynekin]

Насколько я знаю, RS232 был сделан для телеграфии [...] А в телеграфии часто присутствуют паузы.
Какой в данном случае нужен протокол, я не знаю, потому что не знаю что вам нужно.

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

А рассматривать их пришлось, когда понадобилось (давненько это, правда, было!) переписать с QuickBasic'а на "С" программу связи с внешним прибором через COM:-порт. Дело в том, что в Бэйсике были готовые нужные "птичьи слова" вроде Открыть/Закрыть порт, Читать из/Писать в порт - произноси правильно эти заклинания, и дальнейшее уже будет делаться "само". А в "С" такогой лафы нет, и всё нужно организовывать самому, т.к. есть, образно говоря, всего лишь несколько проводов по заданными адресами, с которых можно читать биты, либо выставлять их по своему усмотрению - свобода полная, как в сумасшедшем доме.

Вот тогда-то вся эта описанная "проблема" мгновенно и всплыла. С тех пор так и остался висящим вопрос, какую часть работы по выполнению протокола делает "само hardware" - всякие там UART16550,- а какую нужно делать самому.

Честно говоря, я и сейчас (теперь уже из чистого любопытства) не прочь бы узнать ответ на этот вопрос, но боюсь, что уже как-то задавал его здесь. Так что, дальнейшее - на усмотрение знатоков...

[Crimson King]

Уважаемый Deynekin!
Простите за грубое русское слово, но на мой малопросвещённый взгляд, в вашем изначальном посте имеет место сваливание в кучу нескольких аспектов задачи разного уровня. В первую очередь, рассмотрение частного случая ситуации на уровне порта, а это ещё не есть протокол. Разумеется, в предложенном вами примере (попытка начала прослушивания RS232-линии в произвольный промежуток времени без элементарного контроля по чётности во время передачи специально подобранной последовательности символов) нельзя определить что же конкретно передавалось. Тем не менее, учитывая аппаратные особенности передачи данных между ДВУМЯ! устройствами по RS232-линии, я не в состоянии представить себе возникновение подобной ситуации в реальной жизни (разве если кто-то использует созданный вами продукт, совершенно не понимая, что он делает). Что же касается протокола передачи данных, то это следующий уровень. Боюсь, что подробное изложение даже таких скудных знаний, как мои, выйдет за рамки разумных размеров поста на форуме, но если вас это ещё интересует, вы можете задать мне вопросы через личку, я постараюсь ответить на них в пределах того, что знаю.
Что же касается отсутствия в C такой "лафы", как в QuickBasic (открыть порт, закрыть порт, читать порт, писать в порт, и т. д.), то это тоже не совсем так (использование функций open, close, printf, scanf по отношению к устройству COM). Просто за бортом остаются вопросы настроек порта и управление им, ну и, опять же, протокол. В общем, если есть вопросы - пишите в личку.
С уважением, Crimson King.

[Deynekin]

Уважаемый Deynekin!
...
Боюсь, что подробное изложение ... выйдет за рамки разумных размеров поста на форуме, но если вас это ещё интересует, вы можете задать мне вопросы через личку, я постараюсь ответить на них....

Уважаемый Crimson King, спасибо за ответ и за готовность помочь, я, пожалуй, охотно воспользуюсь Вашим благорасположением. Вот только нужно выяснить, как эта "личка" работает (никогда не пробовал): похоже, нужно кликнуть на имя адресата - выскочит его "профайл" (или как оно там называется), и там будет что-то вроде "послать сообщение" и т.д.; но пока неясно, где искать ответные сообщения...

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

[Crimson King]

Внизу, под моим сообщением, две кнопочки: ПРОФИЛЬ и ЛС. ЛС - послать личное сообщение. Смело жмите и посылайте. Crimson King.

[Deynekin]

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

Внизу, под моим сообщением, две кнопочки: ПРОФИЛЬ и ЛС. ЛС - послать личное сообщение. Смело жмите и посылайте. Crimson King.

-Век живу, век учусь... Получилось, как у Маяковского: Верчусь - аж дыру провертел в сапоге я - не могу найти никакого Апогея! - см. пристёгнутую копию экрана.

Потом только вспомнил, что этот сайт не всё показывает, пока не "войдёшь"-назовёшься. Так, например, я заметил, что, если его открыть "не входя", то многие (-все?) картинки в постах не показываются: текст есть, а картинок нету - странноватый эффект для пассивного режима чтения; ну, да ладно, после того, как знаешь, это уже помеха небольшая.

Так и нынче, "две кнопочки: ПРОФИЛЬ и ЛС" появились только после того, как я догадался "войти".

Ну, а по теме - это уже завтра "нажму смело", как - спасибо - научили; сегодня уже слишком поздно.

[vzhik]

Тем не менее, учитывая аппаратные особенности передачи данных между ДВУМЯ! устройствами по RS232-линии, я не в состоянии представить себе возникновение подобной ситуации в реальной жизни

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

Полез разбираться, нашел баг в силиконе. Оказалось следующее: старт бит задает начало, потом посередине каждого бита берем его значение. За исключением стоп-бита. Стоп-бит они почему-то решили проверять в самом конце бита. В результате один байт налезает на другой и начинается криптография. Начал трясти индусов, они мне обьяснили, мол, да, есть у нас какая-то фигня в споледовательном порту, мы ее еще на FPGA заметили ( ). Ну так вместо того чтобы пофиксить, они во всех утилитках нафигачили задержек и все пучком. А то, что медленно работает - а не фиг торопиться.

[Иоп]

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

It's the Indian way. Йога и все такое

[vm__]

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

It's the Indian way. Йога и все такое

В Минолтовском фотоаппарате каком-то (Z-something) проблемка была - в видеоклипах мерзко слышался звук механизма автофокусировки (механика, скрип). Народ жаловался. В следующей модели (Z-something+1) - видео клипы тоже можно снимать, но без звука. Проблема решена!

[KP580BE51]

Народ жаловался. В следующей модели (Z-something+1) - видео клипы тоже можно снимать, но без звука. Проблема решена!

Я бы сказал как решили несколько похожих проблем, но меня на форуме забанят.