Вопрос по UART по стабильности от внутреннего генера Опции

[awtoap]

Сейчас планируется заложить девайсы, соединенные одной шиной и работающие на открытом воздухе с температурой от -20...+50. Вот встал для меня вопросец - есть ли смысл закладывать кварц для стабильности UART на скорость 4800 (ну возможно 9600).

[Палыч]

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

[ReAl]

Сейчас планируется заложить девайсы, соединенные одной шиной и работающие на открытом воздухе с температурой от -20...+50. Вот встал для меня вопросец - есть ли смысл закладывать кварц для стабильности UART на скорость 4800 (ну возможно 9600).

Без подкалибровки внутреннего RC каким-либо способом - не стоит.
"каким-либо способом" - это, к примеру, по преамбуле (что-то LIN-подобное) или по часовому кварцу/внешним часам.

[awtoap]

Real: Итого кварц всеравно...))

я так и предпологал что без кварца лучше не рисковать...спасибо.

Вот еще вопросец: в каком корпусе лучше брать для последующего возможного обслуживания, если наши люди нос всунут или ещё что-то. Если в дипе, то можно просто проц прислать(как делают братья китайцы в большинстве случаев) а так придется весь блок....что лучше на ваш взгляд???

[Sanya_kv]

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

[defunct]

на 57кгц USART от внутреннего генератора на расстояние около 3-х метров работает без проблем, как в мороз так и в холод на Atmega2313.

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

[MrYuran]

Real: Итого кварц всеравно...))

Вот и не всё равно.
Бывает, что высокочастотные кварцы, особенно китайские, и не заводятся время от времени. Или не на той гармонике.
Часовые - они как-то понадёжнее.

[rx3apf]

Вот и не всё равно.
Бывает, что высокочастотные кварцы, особенно китайские, и не заводятся время от времени. Или не на той гармонике.

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

Часовые - они как-то понадёжнее.

А их те же китайцы делают. И низкочастотный генератор разгоняется дольше. И все равно по нему надо калибровать встроенный RC. Без необходимости такое делать не стоит, IMHO. AVR с часовым кварцем - это необходимость для микропотребляющих устройств с RTC, а если микропотребление некритично - то и нафига ? А в данном случае я бы вообще подумал на предмет RC-тактирования и замены аппаратного UART на какой-нибудь самосинхронизирующийся протокол.

[Guest_@Ark_*]

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

[rx3apf]

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

Но только не UART как такового - асинхронный протокол с синхронизацией по старт-биту по-любому критичен к стабильности генератора. Да и к точности тоже (я про точность начальной синхронизации). Манчестерское или бифазное кодирование гораздо менее чувствительно к этим факторам...

[Guest_@Ark_*]

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

[xemul]

Вообще-то, самый надежный и, одновременно, самый дешевый вариант - именно без кварца. Путем реализации функций UART программным способом.

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

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

Совершенно с Вами угу - работоспособность, н-р, LIN (уже поминали в топике) подтверждена миллиардами коробочек.

[awtoap]

Про LIN подробней если можно...

[xemul]

Про LIN подробней если можно...

http://www.google.com/search?q=%D0%BF%D1%8...-8&oe=utf-8

[Guest_@Ark_*]

<<А что мешает использовать железный УАРТ, но программно выполнять калибровку генератора?>>

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

[xemul]

Ничего не мешает, можно и так.
Есть только одна "засада" - для некоторых экземпляров МК может не хватить диапазона подстройки.
Не выбраковывать же их из-за этого... Программная калибровка предпочтительнее по этой причине.

Может не хватить дискретности перестройки генератора для относительно высоких скоростей обмена. Диапазона перестройки хватает с избытком.
Касательно скорости - сомневаюсь, что софтовый УАРТ позволит достичь в одинаковых условиях тех же скоростей, что и хардовый.

И еще по тому, что "попутно", как-бы само-собой, реализуется автоопределение скорости обмена.
IHMO, весьма полезно иметь некоторый выбор скоростей, а не одну.

И здесь Вас опередили - в LIN'е оно тоже предусмотрено.

[Guest_@Ark_*]

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

<< сомневаюсь, что софтовый УАРТ позволит достичь в одинаковых условиях тех же скоростей, что и хардовый>>
Практически не уступает. По крайней мере - для скоростей до 115200.

<<...в LIN'е оно тоже предусмотрено>>
Ну и что? Почему обязательно LIN? По моему, протокол выбирается по задаче.

[xemul]

<< сомневаюсь, что софтовый УАРТ позволит достичь в одинаковых условиях тех же скоростей, что и хардовый>>
Практически не уступает. По крайней мере - для скоростей до 115200.

Т.е., н-р, АВР@8 МГц INTRC сможет софтово уартить на 115200 и делать еще что-нибудь общественно-полезное? Снимаю шляпу.

<<...в LIN'е оно тоже предусмотрено>>
Ну и что? Почему обязательно LIN? По моему, протокол выбирается по задаче.

Безусловно. Но LIN - это простейшая надстройка над УАРТом, решающая обсуждаемые задачи стандартным образом.
(по секрету - он мне не нравится своей избыточной недостаточностью. но стандартен, зараза)

[Guest_@Ark_*]

<<Т.е., н-р, АВР@8 МГц INTRC сможет софтово уартить на 115200 и делать еще что-нибудь общественно-полезное? Снимаю шляпу.>>
Оденьте шляпу. Это на 9600 можно параллельно общественно-полезной деятельностью заниматься. На 115200 - с этим уже туго. Только последовательно...

[Rst7]

На 115200 - с этим уже туго. Только последовательно...

Да ладно, если пару регистров занять, то вполне можно на 115200 с загрузкой процессора порядка 25 процентов радоваться софтовому UART'у, т.е. 3/4 времени заниматься общественнополезными делами. Но делать такое имеет смысл только в том случае, если уж очень надо.

[galjoen]

Да ладно, если пару регистров занять, то вполне можно на 115200 с загрузкой процессора порядка 25 процентов радоваться софтовому UART'у, т.е. 3/4 времени заниматься общественнополезными делами. Но делать такое имеет смысл только в том случае, если уж очень надо.

А если в софтовом UART-е задействовать таймеры с входами захвата, то загрузка процессора уменьшится ещё как минимум в 2 раза. И прерывания можно будет запрещать на дольшее время. И вообще, приём можно будет сделать не по прерыванию.
Только нужно ли это? Чем LIN то плох?

[Guest_@Ark_*]

Ну причем тут LIN?!
В этой теме речь о том, как обеспечить надежную работу UART в указанных условиях.
А какую шину использовать для передачи и какой протокол выбрать - это уже совсем другая задача.
Связывать эти две проблемы в одну - совершенно не обязательно. На мой взгляд - лучше, как раз, НЕ связывать, и иметь определенную свободу дальнейшего выбора и протокола, и физической шины.

[arttab]

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

[Guest_@Ark_*]

to attab: Вы, видимо, не совсем поняли, что предлагается. Калибруется программная процедура - по приему известных значений байт. Поэтому, ни термометр, ни калибровочные значения для генератора - не требуются.
Диапазон такой "подстройки" по частоте составляет "разы" от предполагаемого номинального значения, как
вверх, так и вниз. По сему, такая калибровка - заодно выполняет функцию автоопределения скорости обмена.
На практике все это давно и многократно проверено...

[MrYuran]

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

Это так кажется, пока не столкнёшься.
Пусть даже один из сотни попадётся, всё равно очень неприятно. Пользователя ведь не волнует, что ему вот с кварцем не повезло.
Причём проблемы могут возникнуть через полгода-год успешной эксплуатации.
А некоторые семейства атмелов (например, 8253) имеют особую предрасположенность к таким дефектам.

[rx3apf]

Это так кажется, пока не столкнёшься.

Надо ли это понимать так, что дефектных часовых кварцев в природе не бывает ?

Чем LIN то плох?

А что в нем хорошего ? На малые расстояния, с малой скоростью - ну, может быть и ничего. А если большая емкость, переключение линии несимметричное и время перехода 1->0 и 0->1 существенно различаются ? И аппаратный UART задействовать тоже не особо просто, даже если опорный генератор процессора допускает "электронную" подстройку. А если не допускает, то типично дискретность перестройки через опорный делитель слишком грубая. А синхронные протоколы - просто и надежно.

[galjoen]

А что в нем хорошего ? На малые расстояния, с малой скоростью - ну, может быть и ничего. А если большая емкость, переключение линии несимметричное и время перехода 1->0 и 0->1 существенно различаются ? И аппаратный UART задействовать тоже не особо просто, даже если опорный генератор процессора допускает "электронную" подстройку. А если не допускает, то типично дискретность перестройки через опорный делитель слишком грубая. А синхронные протоколы - просто и надежно.

Я имел ввиду использование автоподстройки частоты как в протоколе LIN в комплекте с СОФТОВЫМ UART. В таком случае разница переднего и заднего фронтов и соотв-но время перехода 1->0 и 0->1 запросто компенсируются програмными настройками по результатам приёма известного байта. А ещё лучше сделать софтовый CAN. Для скорости 5000 бод это вполне реально. В таком случае можно использовать драйвера линии LIN. Т.е. 3-х жильный провод - земля, линия связи и питание 12 вольт. А синхронные протоколы потребуют и проводов и драйверов линии поболее. А цена драйвера линии (хоть RS485, хоть CAN, хоть LIN) на уровне младших AVR (ATmega48 например).

[Guest_@Ark_*]

Цитата(galjoen): "... синхронные протоколы потребуют и проводов и драйверов линии поболее..."

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

[galjoen]

Цитата(galjoen): "... синхронные протоколы потребуют и проводов и драйверов линии поболее..."

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

Синхронные, это которые с внешней синхронизацией. А самосинхронхронизирующиеся - это другое. Все современные протоколы самосинхронизирующиеся. Поэтому у них и имеется битстаффинг - для синхронизации. USB, CAN и т.д. Да и LIN тоже, с некоторой натяжкой, можно отнести к самосинхронизирующимся. Он на базе UART. Поэтому его и рекомендуют.

[Guest_@Ark_*]

<<Все современные протоколы самосинхронизирующиеся. Поэтому у них и имеется битстаффинг - для синхронизации. USB, CAN и т.д. Да и LIN тоже>>

И снова не верно. НЕ все.

И стандарный UART - НЕ самосинхронизирующийся! Не зная опорной частоты невозможно достоверно принять информацию. А для самосинхронизирующегося "манчестера" - можно!

Извините, ув. galjoen , но Вы хотя бы уясните для себя разницу между физическим уровнем и протоколом...

[awtoap]

Во дискуссия развернулась... Мне собственно нужно обеспечить связь между четырьмя блоками в режиме мастер-подчиненные расположенных в общей сложности на линии в 30 метров (на машине). Раз зашла речь о протоколах что сами порекомендуете.. ЛИН и "манчестер" уже есть, кто еще что предложит? С уартом не работал для связи посредством вообще каких-нибудь протоколов. Пока что решил заложить во все блоки кварц и протокол типа преамбула, команда, данные, крк. Если подчиненный принял то ответ аналогичный.

Киньте исходники по манчестеру...

[Guest_@Ark_*]

Да Вы не обращайте внимания! Это у нас внутренние разборки...
Если квалифицированых программеров у Вас под рукой нет - ставьте надежные кварцы в свои устройства, и используйте стандартный UART - и будет Вам счастье. Ну не в космос же Вам лететь! По поводу шины - я лично рекоменудую RS-485/RS-422, как наиболее помехозащищенную. Хотя это дело вкуса... Решайте сами...

[galjoen]

Да Вы не обращайте внимания! Это у нас внутренние разборки...
Если квалифицированых программеров у Вас под рукой нет - ставьте надежные кварцы в свои устройства, и используйте стандартный UART - и будет Вам счастье. Ну не в космос же Вам лететь! По поводу шины - я лично рекоменудую RS-485/RS-422, как наиболее помехозащищенную. Хотя это дело вкуса... Решайте сами...

Да, это самое стандартное решение (+ протокол Modbus). А уж никак не манчестер...

А если тиражи предполагаются небольшие, то можете использовать I2C (TWI), но с драйверами физического уровня от CAN. Там по 2 таких драйвера на девайс придётся поставить. Преимущество в том, что и кварц не нужен и программа простая, а при малых тиражах затраты на лишние драйверы несущественны.
Я так понимаю, что rx3apf что-то вроде этого имел ввиду.

Нет. Насчёт драйверов от CAN ерунду написал. Хотя наверное можно что-то такое сделать, но с доп. элементами. Как-то нужно узнавать в каком состоянии (входом или выходом является) сейчас вывод TWI...

[Nuts_]

В свое время получил такой 'эфект на Atmega8
сделаи контрукцию с RCгенератором
залили готовую полату эпоксидкой - частота уплыла сильно UART не работал
но смена коэфициентов решила проблему

В той же контрукции нам надо было обеспечить нескоростную свзяь на длинном коаксильном кабеле
сделали что то типа 1-Wire
все работало в широком температурном диапазоне - передатчик на 0 градусов
применик - в комнатных условиях

НО с тех пор ставим внешнеие температуронезависимые источники частоты - у нас шутчное производтво.