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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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