Stas- 0 15 октября, 2012 Опубликовано 15 октября, 2012 (изменено) · Жалоба Ну как же.. Партия сказала "Надо!", комсомол ответил "Есть!" :) Не пачка единиц, а "молчание" на линии - даст 100% гарантию синхронизации на следующем стартовом бите. Не даст. А вдруг приемник включится как раз после стартового бита? Система без предыстории. Изменено 15 октября, 2012 пользователем Stas- Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба Не даст. А вдруг приемник включится как раз после стартового бита? Система без предыстории. так и аппаратный будет вести себя аналогично. Думайте, как синхронизироваться по старт-биту Главное - реализовать правильно логику приема байта, в дальнейшем это будет полная аналогия аппаратному UART Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Stas- 0 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба так и аппаратный будет вести себя аналогично. Думайте, как синхронизироваться по старт-биту Главное - реализовать правильно логику приема байта, в дальнейшем это будет полная аналогия аппаратному UART Бро, я ведь написал в начале, что точно так же поведет себя и аппаратный UART. Хотел узнать, как выкрутиться из ситуации, пока писал сам - понял. Дело вовсе не в логике принятия первого бита, а, собственно корреляции принятых байтов с неким заголовком. Тут можно возразить - а если пилит непрерывный поток, и облажаешься между посылками, что будешь делать? Так все просто. Задуваем некий "макро загоровок" среди теперь уже байтовых посылок и коррелируем с ним. И так, пока не надоест. Тему я поднял для того, чтобы убедиться, не туплю ли я в понимании работы самого UART. Вроде все очевидно, но мало ли. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба Обычно обмен идет не постоянно, а с неким интервалом. Отправил пакет - ждешь ответа в течение некого времени. Ответили/не ответили дело десятое, главное - дать время синхронизироваться приемнику по этой паузе Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flexz 0 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба Не даст. А вдруг приемник включится как раз после стартового бита? Система без предыстории. Какая разница когда он включится? Все равно в итоге получится гарантированный фрейм эррор на первом idle интервале и засинхронизируется на следом идущем стартовом бите (а если ошибки нет - значит синхронизация сразу была успешной) У вас что приемник в рандомные моменты времени включается/выключается, не дожидаясь получения достоверных данных? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Stas- 0 15 октября, 2012 Опубликовано 15 октября, 2012 (изменено) · Жалоба Да, моменты совершенно рандомные. Ну, дальше наливаем :) Тут дело в том, что пишем вдвоем. Я как он - не умею (питон). Но, я добился того, чтобы его прога работала стабильно, теперь сам делаю так, чтобы все работало долговременно стабильно. Да и мои это проблемы, вообще-то, аппаратные :) А сам процесс - итеративный. Изменено 15 октября, 2012 пользователем Stas- Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба Жесть :) вариянт! делать прием 9 бит и каждый нулевой считать старт-битом. Итого - массив из 9 байт и смотреть старт-фреймовый байт. Поймали - все, вошкание с остальными 8 "стартовыми" битами фтоппко, оставляем стартовым только этот Да вот только геморроя здесь... Не проще ли питонщику отправлять пакеты с интервалом? или он умеет просто в буфер все валить и вообще об аппаратной части не думает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Stas- 0 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба Жесть :) вариянт! делать прием 9 бит и каждый нулевой считать старт-битом. Итого - массив из 9 байт и смотреть старт-фреймовый байт. Поймали - все, вошкание с остальными 8 "стартовыми" битами фтоппко, оставляем стартовым только этот Да вот только геморроя здесь... Не проще ли питонщику отправлять пакеты с интервалом? или он умеет просто в буфер все валить и вообще об аппаратной части не думает? Да нет никого геморроя. Питонщику скидываем побитно все что приходит, а он делает XOR с маской, суммирует ненулевые биты (он, вроде, умеет) :) делает заключение по числу ненулевых - и все. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
toweroff 1 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба Да нет никого геморроя. Питонщику скидываем побитно все что приходит, а он делает XOR с маской, суммирует ненулевые биты (он, вроде, умеет) :) делает заключение по числу ненулевых - и все. а потом все сидят и думают, чо это у нас все так глючит и вообще через пятый точк работает... грустно можно телефон сделать, кстати, пусть чипы вообще нифига не делают, все на себя возьмет ковырнаццать гигагерц проц, весь битовый поток - ему! да и чумадан-аккумулятор, чтобы все пользователи тела были спортсменами-штангистами Пусть не дзю-до, но тоже хорошо :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 15 октября, 2012 Опубликовано 15 октября, 2012 (изменено) · Жалоба Тут можно возразить - а если пилит непрерывный поток, и облажаешься между посылками, что будешь делать? Шутки шутками, а непрерывный поток надо где-то прерывать на более чем один фрейм. А синхронизацию с откидыванием пакета учинять дороговато для этого случая. Вы там это... заканчивайте со сферическими конями. Это Вы еще не рассматривали случаи с длиной посылки в 5 бит. Представляете, как на ровном месте получаем помехоустойчивое кодирование? :) Разбросали числа на равном кодовом расстоянии... штрашшное дело! Изменено 15 октября, 2012 пользователем _Pasha Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Stas- 0 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба Разбросали числа на равном кодовом расстоянии... штрашшное дело! Если на равном - Хэмминга включим. Если не на равном - Соломона с Ридом.ъ Пацанов с раена занаешь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
V_G 11 15 октября, 2012 Опубликовано 15 октября, 2012 · Жалоба Тут можно возразить - а если пилит непрерывный поток, и облажаешься между посылками, что будешь делать? Асинхронный интерфейс - не для непрерывного потока, в котором можно перепутать старт-бит с межбитовыми перепадами. Если речь идет о возможности вставки "Синхрослов", т.е. о переделке софта на передающей стороне, то лучше озаботиться паузами. Зачем там вообще гонят непрерывный поток, вы что, видео по RS-485 передаете? Если речь об обычной системе сбора данных или передаче/отработке команд, необходимость в непрерывном потоке абсолютно надуманна. ЗЫ. Кстати, непрерывным потоком по уарту можно и обычный компьютер подвесить. А уж "военный" Багет вешался на раз, если при загрузке ему кто-то в уарт что-то сыпал! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 16 октября, 2012 Опубликовано 16 октября, 2012 · Жалоба Я делаю так. Поток разбит на фреймы, символ 0xF0 обнуляет текущий буфер приема и явлется началом фрейма. Последовательная передача двух 0xF0 подряд обеспечивает битовую синхронизацию (т.е прочистку UART) и прочистку буфера приема. После этого фрейм принимается без ошибок. Внутри фрейма символы 0xF0 заменяются Esc-последовательностью из двух байт (байт-стаффинг). Асинхронный интерфейс - не для непрерывного потока, в котором можно перепутать старт-бит с межбитовыми перепадами. Если речь идет о возможности вставки "Синхрослов", т.е. о переделке софта на передающей стороне, то лучше озаботиться паузами. Зачем там вообще гонят непрерывный поток, вы что, видео по RS-485 передаете? Если речь об обычной системе сбора данных или передаче/отработке команд, необходимость в непрерывном потоке абсолютно надуманна. Непрерывный поток всегда идет, например, по радиоканалу - когда передатчик не работает, то приемник все равно ловит эфир. Для RS485 непрерывный поток появляется, когда кабель проложен в месте, где много помех. Протокол, который не способен работать в условиях непрерывного потока на входе UART - это радиолюбительское убожество. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
V_G 11 16 октября, 2012 Опубликовано 16 октября, 2012 · Жалоба Радиолюбительством является также пускать напрямую в ком-порт эфирный поток радиоканала. А в остальном - да, протокол должен учитывать наличие помех, разрывы связи и пр. и пр. Но и сам софт, использующий любой крутой протокол, должен по возможности меньше загружать каналы связи, избегая избыточных непрерывных потоков. Не будете же вы весь поток сообщений NMEA, вылезающий из GPS-приемника, отправлять в эфир, когда нужна лишь информация по координатам и только по мере их изменения? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 16 октября, 2012 Опубликовано 16 октября, 2012 · Жалоба Также радиолюбительством является неустановка "растяжек" на линии RS485, обеспечивающих защитное смещение при свободном канале. Только так можно получить "непрерывный поток" мусора, "когда кабель проложен в месте, где много помех". Другими способами достичь такого "выдающегося результата" не получается. Даже, к примеру, в непосредственной близости от сварочной дуги... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться