Какие могут быть проблемы при вкл/откл UART в ATmega128?

Don_Ambrosio · 28.02.2008, 22:41

Когда я включаю/выключаю передатчик UART в ATmega128 установкой/сбросом бита TXEN то, что происходит на пине TXD? Я имею ввиду никаких выбросов/импульсов в момент подключения/отключения пина TX к UART-у не будет? Вроде бы не должно (если пин ранее был уже настроен на выход). Но что-то меня сомнения берут: как-то "гуляя" по инету наткнулся на инфу, что нЕкий чел поимел проблемы. А именно, толи при включении, толи при выключении UART на линии появлялся короткий провал логического уровня, который другие UART-ы принимали за СТАРТ-бит, который в этом случае оказывался ложным

Никто не сталкивался с такой проблемой? Или её просто не существует?

pambaru · 29.02.2008, 07:54

Только вот вчера делал прошивку - использовал включение и выключение UART в ATMEGA1280 (TXEN) - все работает нормально, никаких выбросов не заметил (предварительно, конечно, писал в соответствующий порт единичку).

zelen536 · 29.02.2008, 14:41

Так же ни разу не наблюдал проблем с включение/выключением UART-а, но выбросы если и бывают, то они легко фильтруются приемником на уровне либо применения бита четности либо проверки приема байта (программно). Если выбросы волнуют в многопроцессорных цепях при применении драйверов RS-232-485, то необходимо их выбирать (большинство их имеет) с защитой от встречных включений. В общем, не волнуйся и проверяй на своем опыте.

Don_Ambrosio · 29.02.2008, 15:33

Сообщение от zelen536

Если выбросы волнуют в многопроцессорных цепях при применении драйверов RS-232-485, то

"Формально все правильно, и на столе в лаборатории будет работать. Однако в реальной жизни будут проблемы.

Дело в том, что приемники RS485 очень чувствительные. Когда все устройства работают на прием, то малейшая помеха в линии связи будет ими воспринята и выдана на входы UART-ов как полезный сигнал. UART "увидит" ложный старт-бит и начнет прием, и т.п. Алгоритм работы должен это учитывать, иначе обмен будет дико глючить, и даже подтягивающие резисторы в линии и "fail-safe" приемопередатчики не помогут.

В протокол обмена надо ввести следующие дополнения:
1) Перед началом передачи пакета надо включить трансивер на передачу, но в течении нескольких байт-интервалов не передавать ничего. Включенный выход передатчика пересилит почти любую наведенную помеху, поэтому в течении такого "пассивного" интервала на входах приемников помех не будет. Этот "пассивный" интервал нужен чтобы все приемники очистили свои буфера по тайм-ауту.
2) При передаче пауза между соседними байтами в пакете не должна превышать некоторого малого значения, например, половины байт-интервала. Приемники же должны принимать данные с проверкой прихода каждого нового байта на допустимый тайм-аут. Если в течении, скажем, двух байт-интервалов следующий байт не пришел, значит, это была помеха, приемник должен отвергнуть текущий пакет, очистить буфер и быть готовым к приему нового пакета." (с) http://www.microchip.su/showthread.php?t=1390

Ещё тут http://66.102.9.104/search?q=cache:p...lnk&cd=1&gl=ru

И здесь http://66.102.9.104/search?q=cache:d...lnk&cd=2&gl=ru

"..и сразу же ножка RXD станет просто входом (подтяжка уберется)"(с) http://www.123avr.com/02.htm

Вот Вам и возможность для ложного СТАРТ-бита

zelen536 · 29.02.2008, 16:17

Согласен с Don_Ambrosio, в его посте указания на программную фильтрацию этих выбросов, в своем посте я обратил внимание на апаратный нюанс - "встречное" включение драйверов, возникающее при обсуждаемых выбросах. Метоты стандартные, достаточно почитать соответствующие темы, потом попрактиковаться ("набить свои шишки"), но все это применимо для ЛЮБОГО проца и AVR абсолютно не имеет никаких отрицательных особенностей в этом плане - на это хотел обратить внимание автора ветки.

qwaszx2313 · 01.03.2008, 14:38

Сообщение от Don_Ambrosio

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

На опыте внедрения распределенных систем у меня появиласть тведрая уверенность - у приборов предназначенных для работы в распределенной сети ни в коем случае не должно быть времязависимого протокола. В случае использования различных радио-удлинителей, модемов(как GSM так и обычных), другой "умной" каналобразующей аппаратуры, такие приборы заставить работать без сбоев связи почти невозможно.
Используйте нормальный протокол с начальным ограничителем, конечным ограничителем, CRC пакета и байт стаффингом и никаких проблем, ни со стыковкой с каналообразующей аппаратурой, ни с помехами в линии связи.
Хотя, если прибор будет передавать данные ТОЛЬКО на короткие расстояния (межпроцессорная связь внутри прибора, связь между блоками какого-либо агрегата) то почему бы и нет?

Don_Ambrosio · 01.03.2008, 15:06

Сообщение от qwaszx2313

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

Т.е. как? У Вас нет никаких тайм-аутов в протоколе? А как же тогда Вы организовываете мудьтмастерную сеть?
http://pro-radio.ru/controllers/5564/

qwaszx2313 · 01.03.2008, 15:47

Пум-пум-пум. Начнем с того что, если в сети предусматривается несколько мастеров - то использование сторонней каналообразующей аппаратуры, которая, ни сном, ни духом, не знает о "нашем гипотетическом мультимастерном протоколе" вообще не допустимо. В таком случае опять же напрашиваются стандартные решения для выбора данного протокола (для расширения выбора стороннего оборудования). Для небольших сетей - CAN (не только формирователи, но и сам логический протокол), для более распределенных объемных TCP/IP и иже с ним. Но в этих случаях ни о каких UART`ах и речи не идет. Да и на стоимость прибора это повлияет не в лучшую сторону.

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

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

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

Don_Ambrosio · 01.03.2008, 22:09

Сообщение от qwaszx2313

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

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

qwaszx2313 · 05.03.2008, 12:20

Если в вашем приложении нет необходимости в образовании канала данных ну к примеру по ЛЭП 110кВ или организации связи на дистанции порядка десятков километров, то конечно сторонняя аппаратура вам ни к чему, если обычные телефонные модемы, которые искажают межбайтные интервалы, вам не пригодятся - то конечно нет смысла придерживаться стандатртов и думать о сопряжении вашего устройства с другими. Договориться самому с собой намного проще, чем с кем бы то ни было другим, принять свои собственные ограничения тоже намного проще, чем ограничения накладываемые другими. Говорить про ВСЕ сторонние разработки "глючное", некрасиво. Если у всех все глючит, а только я один в белом, то может стоит задуматься, может быть дело-то не в других?

И все таки, говоря абстрактно о некоем АБСТРАКТНОМ применении некоего АБСТРАКТНОГО протокола все-таки некорректно. Если есть необходимость в стороннем оборудовании - то просто необходимо придерживаться стандартов, или хотя-бы некоторых ограничений накладываемых этой сторонней аппаратурой. Если нет - то в который раз говорю:"своя рука владыка".