[Stas- 0]

Ну как же.. Партия сказала "Надо!", комсомол ответил "Есть!" :)

 

 

Не пачка единиц, а "молчание" на линии - даст 100% гарантию синхронизации на следующем стартовом бите.

Не даст. А вдруг приемник включится как раз после стартового бита? Система без предыстории.

Изменено 15 октября, 2012 пользователем Stas-

[toweroff 1]

Не даст. А вдруг приемник включится как раз после стартового бита? Система без предыстории.

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

Главное - реализовать правильно логику приема байта, в дальнейшем это будет полная аналогия аппаратному UART

[Stas- 0]

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

Главное - реализовать правильно логику приема байта, в дальнейшем это будет полная аналогия аппаратному UART

Бро, я ведь написал в начале, что точно так же поведет себя и аппаратный UART. Хотел узнать, как выкрутиться из ситуации, пока писал сам - понял. Дело вовсе не в логике принятия первого бита, а, собственно корреляции принятых байтов с неким заголовком.

 

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

 

Тему я поднял для того, чтобы убедиться, не туплю ли я в понимании работы самого UART. Вроде все очевидно, но мало ли.

[toweroff 1]

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

[Flexz 0]

Не даст. А вдруг приемник включится как раз после стартового бита? Система без предыстории.

Какая разница когда он включится? Все равно в итоге получится гарантированный фрейм эррор на первом idle интервале и засинхронизируется на следом идущем стартовом бите (а если ошибки нет - значит синхронизация сразу была успешной)

У вас что приемник в рандомные моменты времени включается/выключается, не дожидаясь получения достоверных данных?

[Stas- 0]

Да, моменты совершенно рандомные.

 

Ну, дальше наливаем :)

 

Тут дело в том, что пишем вдвоем. Я как он - не умею (питон). Но, я добился того, чтобы его прога работала стабильно, теперь сам делаю так, чтобы все работало долговременно стабильно. Да и мои это проблемы, вообще-то, аппаратные :)

А сам процесс - итеративный.

Изменено 15 октября, 2012 пользователем Stas-

[toweroff 1]

Жесть :)

вариянт!

делать прием 9 бит и каждый нулевой считать старт-битом. Итого - массив из 9 байт

и смотреть старт-фреймовый байт. Поймали - все, вошкание с остальными 8 "стартовыми" битами фтоппко, оставляем стартовым только этот

Да вот только геморроя здесь... Не проще ли питонщику отправлять пакеты с интервалом? или он умеет просто в буфер все валить и вообще об аппаратной части не думает?

[Stas- 0]

Жесть :)

вариянт!

делать прием 9 бит и каждый нулевой считать старт-битом. Итого - массив из 9 байт

и смотреть старт-фреймовый байт. Поймали - все, вошкание с остальными 8 "стартовыми" битами фтоппко, оставляем стартовым только этот

Да вот только геморроя здесь... Не проще ли питонщику отправлять пакеты с интервалом? или он умеет просто в буфер все валить и вообще об аппаратной части не думает?

Да нет никого геморроя. Питонщику скидываем побитно все что приходит, а он делает XOR с маской, суммирует ненулевые биты (он, вроде, умеет) :) делает заключение по числу ненулевых - и все.

[toweroff 1]

Да нет никого геморроя. Питонщику скидываем побитно все что приходит, а он делает XOR с маской, суммирует ненулевые биты (он, вроде, умеет) :) делает заключение по числу ненулевых - и все.

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

грустно

можно телефон сделать, кстати, пусть чипы вообще нифига не делают, все на себя возьмет ковырнаццать гигагерц проц, весь битовый поток - ему!

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

Пусть не дзю-до, но тоже хорошо :)

[_Pasha 0]

Тут можно возразить - а если пилит непрерывный поток, и облажаешься между посылками, что будешь делать?

Шутки шутками, а непрерывный поток надо где-то прерывать на более чем один фрейм.

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

Это Вы еще не рассматривали случаи с длиной посылки в 5 бит. Представляете, как на ровном месте получаем помехоустойчивое кодирование? :) Разбросали числа на равном кодовом расстоянии... штрашшное дело!

Изменено 15 октября, 2012 пользователем _Pasha

[Stas- 0]

Разбросали числа на равном кодовом расстоянии... штрашшное дело!

Если на равном - Хэмминга включим. Если не на равном - Соломона с Ридом.ъ

 

Пацанов с раена занаешь?

[V_G 7]

Тут можно возразить - а если пилит непрерывный поток, и облажаешься между посылками, что будешь делать?

 

Асинхронный интерфейс - не для непрерывного потока, в котором можно перепутать старт-бит с межбитовыми перепадами. Если речь идет о возможности вставки "Синхрослов", т.е. о переделке софта на передающей стороне, то лучше озаботиться паузами. Зачем там вообще гонят непрерывный поток, вы что, видео по RS-485 передаете?

Если речь об обычной системе сбора данных или передаче/отработке команд, необходимость в непрерывном потоке абсолютно надуманна.

 

ЗЫ. Кстати, непрерывным потоком по уарту можно и обычный компьютер подвесить. А уж "военный" Багет вешался на раз, если при загрузке ему кто-то в уарт что-то сыпал!

 

[=AK= 12]

Я делаю так. Поток разбит на фреймы, символ 0xF0 обнуляет текущий буфер приема и явлется началом фрейма. Последовательная передача двух 0xF0 подряд обеспечивает битовую синхронизацию (т.е прочистку UART) и прочистку буфера приема. После этого фрейм принимается без ошибок. Внутри фрейма символы 0xF0 заменяются Esc-последовательностью из двух байт (байт-стаффинг).

 

Асинхронный интерфейс - не для непрерывного потока, в котором можно перепутать старт-бит с межбитовыми перепадами. Если речь идет о возможности вставки "Синхрослов", т.е. о переделке софта на передающей стороне, то лучше озаботиться паузами. Зачем там вообще гонят непрерывный поток, вы что, видео по RS-485 передаете?

Если речь об обычной системе сбора данных или передаче/отработке команд, необходимость в непрерывном потоке абсолютно надуманна.

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

 

Протокол, который не способен работать в условиях непрерывного потока на входе UART - это радиолюбительское убожество.

[V_G 7]

Радиолюбительством является также пускать напрямую в ком-порт эфирный поток радиоканала.

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

Не будете же вы весь поток сообщений NMEA, вылезающий из GPS-приемника, отправлять в эфир, когда нужна лишь информация по координатам и только по мере их изменения?

[Гость @Ark]

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