Можно ли использвать UART в mega8 без кварцевой стабилизации (внутренний генератор). До каких скоростей? А то уже второй день пробую, и все время какие-то ошибки в передаче.

Больше информации!

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

До 19200 при связи с компом как правило работает (8N1). Если повезло со стабильностью, то и побольше скорость можно пробовать, но 19200 - практически всегда (в серийное устройство, конечно не стоит закладывать, там только кварц, ИМХО, меньше гемороя).

Интерфейс LIN - предусмотрена процедура подстройки тактовой при работе от RC - генератора.

Связь с компьютером. Внутренний генератор настроен на 4МГц. Пробую скорость 9600. Калибровать не пробовал. Надо? Вообщем посылаю контроллеру разные символы, а приходит 0xF8 либо 0x00. В чем дело, не могу понять.

Думаю, что такого делать не стОит. Ведь UART - асинхронный. Ему очень важна стабильность частоты - насколько я помню, допускается ошибка в 2.5 процента или чуть выше. Даже если вы как положено зашлете в OSCCAL настроечный байт, стабильности частоты это не обеспечит. Будет скакать и от температурных изменений, и от питающего напряжения...

Короче, если не нужен геморрой - ставьте кварц.

Собирал партию устройств не Меге48 с внутренним генератором на 8МГц, скорость 38400.При связи(С ПК)
никаих проблем не обнаружилось(В партии 100шт)

Позволю себе несогласиться с мнением большинства, что кварц на UART обязателен. Всё зависит от внутреннего генератора. Какие у него характеристики по точности частоты? Вы можете их тут привести?
Я практического опыта с UART не имел, поэтому у меня бытовые или теоретические рассуждения. Спорить не буду. Для UART нужна стабильность краткосрочная, т.е. чтобы во время передачи одной посылки (байта) между старт-стопными символами фронт уплывал не более, чем на половину такта (точно не помню, но какая-то такая величина, первые доли такта). Время передачи байта ничтожно мало по сравнению с временем, за которое даже примитивный цифровой генератор на RC-элементах уплывёт (например, по температуре), да ещё и на полтакта. У кварца же точность очертенная, она такая не нужна. 100 ppm скажем - это же 0,01%, если правильно сосчитал. Притом 100 ппм - это долговременная стабильность, за весь срок службы аппаратуры. А кратковременная - куда выше.
Вот такие у меня рассуждения.

К стати, почитайте тут соседнюю тему http://electronix.ru/forum/index.php?showtopic=16273&st=0
Судя по алгоритмам выделения бит, там вообще нестабильность может достигать плюс-минус поллаптя, т.к. алгоритмы дубовые, и всё вытянут.

Требуемая точность частоты тактирования UART зависит в основном от алгоритма детектирования битовой последовательности и длины непрерывного пакета данных. Например, для самого простого случая - передача 1 символа (8N1, одна выборка на бит в центре битового интервала) разность частот приемника и передатчика может достигать 5.5% (0.5BitTime/9).

У меня между компом и МК от внутреннего генератора 8 МГц на 38400 стабильно работает...

Если посмотреть графики зависимостей частоты внутреннего генератора от температуры и напряжения питания, то на краях диапазонов погрешность частоты уже выходит за пределы, необходимые для надёжной работы UART.
Испытания показали полное соответствие теоретическим предпосылкам, т. е. на краях температурного диапазона (ниже -20 С и выше +55 С) коннект был нестабильным, часто возникали ошибки.

Mega162 + внутренний генератор 4MHz + soft UART нормально общается с компом на скорости 115200. При калибровке слал в мегу по одному байту, увеличивая OSCCAL на 1, она возвращала его на терминалку, затем находил участок где прием нормальный а его середина и есть требуемое значение для OSCCAL. Самое странное, что настраивал на 5V, но работает и на 3V

DesNer
Исходная ошибка калибровки mega8 по даташиту при температуре 25 С и питании 3 В <1%.
Определите/задайте диапазон температур и напряжений, в котором предполагается эксплуатировать устройство. По даташиту найдите соответствующее возможное изменение (ошибку) Fosc.
Рассчитайте ошибку по BAUD для желаемой скорости передачи от округления UBRRn (например, для Fosc = 4 МГц и BAUD = 19200 в Normal Speed Mode получится всего 0.17%).
Найдите корень от суммы квадратов этих трех ошибок, и если получится меньше 2%, то можно надеяться, что при правильной софтовой реализации 97% устройств будут работать в заданном диапазоне тепмератур и напряжений без дополнительной калибровки OSCCAL.

Можно получить устойчивую работу на скорости 115200 если, как советует Reflector, откалибровать внутренний RC на частоту близкую к кратной 115200 например на 7.3Mhz.

Выборка бита в UART меги работает по мажоритарному принципу. Бит делится на 16 (8 в 2х) частей и считывание происходит в 8,9 и 10-х частях (4,5,6 в 2х). Следовательно в режиме 8N1 краешек 10-ого стоп бита не должен уехать на 6/16/10 (2/8/10 в 2х), то есть на 3.75% (2.5% в 2х). Это суммарная погрешность приемника и передатчика. Скорость же УАРТ 19200 или там 115200 значения не имеет. Если удастся выдержать нужную точность частоты, все будет нормально. Например, если сумеете заставить внутренний генератор работать с частотой 3.6864МГц +-3.75% будет работать и на 115200 и на 230400 (персоналка +-0%).
ИМХО, без кварца такие отклонения обеспечить сложно. С однократной калибровкой внутреннего RC разве что в термостат мегу засунуть и не вынимать.
У Атмела есть платка отладочная батерфляй, мега169 работает от внутреннего генератора и обеспечивает связь с персоналкой. Дык там стоит часовой кварц на таймере1 и RC подстраивают от него периодически.

[/quote]
Если посмотреть графики зависимостей частоты внутреннего генератора от температуры и напряжения питания, то на краях диапазонов погрешность частоты уже выходит за пределы, необходимые для надёжной работы UART.
Испытания показали полное соответствие теоретическим предпосылкам, т. е. на краях температурного диапазона (ниже -20 С и выше +55 С) коннект был нестабильным, часто возникали ошибки.
[/quote]

Полностью присоединяюсь.
Случайно фузы запрограмировал на внутренний генератор 8 МГц внешний кварц такой-же
все работало как часы пока не начал гонять устройство в термокамере. 2 дня как тупой ничего понять
немог температура опускается ниже -25 связь становится неустойчивой а потом и совсем
пропадает

Так что если устройство эксплуатируется в широком диапазоне температур кварц ставить надо

А что, если попытаться калибровать внутренний RC-генератор по приходящим посылкам? Для этого можно измерять интервал между началами стартового и стопового битов, заведя сигнал приёмника на доп. вход.
Изврат, конечно, но если очень нужно, может прокатить...

проще термодатчик поставить,снять зависимость внутреннего rc-генератора от температуры и менять
OSCCAL.

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

Это где это в Мегах термодатчик, в каком месте?

Мда, в Tiny25-Tiny85 есть. А вот в мегах вроде нет... А жаль... Хотя для софтового уарта тоже дело...

Неудобно по трём основным причинам:
1. Нужен термодатчик;
2. Нужен датчик напряжения питания (RC-генератор "плывёт" также и с напряжением питания);
3. Необходимо снимать зависимость частоты RC-генератора каждого прибора от обоих вышеуказанных параметров. Типовая зависимость не прокатит - гарантии в этом случае не обеспечивается.
Кроме того, нельзя сбрасывать со счетов долговременную стабильность (старение) генератора.
Коррекция же частоты по результатам измерения известных временнЫх интервалов мне кажется наиболее естественной.

Да, это нужно. Правда его точность может быть никакая .
С этим проблем нет - либо это напряжение "плывет" в пределах 10% (что меняет частоту на доли %) либо Мега меряет свое питание внутренним АЦП (через BANDGAP) даже без потери на это порта....

Насколько помню чатота RC во всем диапазоне температур и напряжений уплывает МАКСИМУМ на 5%(разность между крайними точками поверхности). Тобишь (т.к. и так "практически почти хватает") достаточно грубой коррекции частоты в нескольких точках T-U диапазона. Т.е. это не юстировка частоты - это коррекция при которой локальная ошибка в 0,5-1% (четверть ошибки по каждой из возмущающих параметров) более чем допустимы. Ну и можно допустить, что около коллиброванного значения наклоны кривых в разных чипах имеют достаточно высокую повторяемость.

Не уверен, что этот параметр может повлиять настолько, да и стареют RC одновременно...

Для этого они должны быть известны и они должны быть. Для LIN протовола это просто, а вот при общении с каким нибудь GSM модулем(мобилкой) весьма проблематично

При качественном проектировании это нельзя допустить.
Чтобы нормально спроектировать даже несложную систему, нужно быть уверенным в параметрах компонентов.
Прочитайте посты #1 и #5 данной темы. А в "мабилле" тоже кварц имеется...

А как быть если устройство должно работать в широких диапазонах примерно от -45 до +60 ? да ещё и уарты пашут на полную скорость?? Мы например сделали коробочку внутри расположили нагреватель(резистор) и термостат... А вот сборки бывают такие... например на 14.7456 МГц?

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

Уверен я бываю только после недели собственноручных испытаний .
Для Вас достаточно уверенности Atmel которая, заложив в доках точность коллибровки RC и его изменение от Vсс T и OSCCAL, ни в одном чипе не обмолвилась о нестабильности этого генератора из-за старения? Я думаю, что указанная нестабильность не выше нестабильности по причине Vсс и T....
В "мабилле" есть, но в "мабиллу" никто и не влазит. Речь о связи с нею....

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

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

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

Гарантированный за время одного символа только ОДИН переход. Расстояния между символами - не гарантированы...

Как это ОДИН? Где и в какую сторону?

Как раз время то между старт/споп и есть искомая (измеряемая) величина. А наличие самих переходов гарантировано.

В некоторых PICах есть AUTO BAUD RATE DETECT. Передатчик отправляет байт 0x55, а приемник автоматом вычисляет baud rate регистр. Здесь почти то же самое, за исключением, что baud rate регистр это константа, а подбираем значение регистра калибровки int RC.

Стартовый в начале старт-бита. Переход 1->0. Стоповый бит - это только минимальное гарантированное расстояние между двумя соседними байтами...

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

Не зная в какой момент должно прити второе? Еще раз - речь не о LIN и ей подобных проторолов в которых есть символы синхронизации...

Стоповый переход конечно гарантирован, но не гарантировано, что внутри интервала старт-стоп будет именно 9 битовых периодов. Потому что может еще и бит четности передаваться или вообще 5-6-7 битовая посылка. Для Auto baud detect часто используют 0xFF. Это гарантированный битовый интервал при передаче старт-бита.

Проще калибровать по 0x00. В 9 раз точнее, при прочих равных условиях.

Стоп-стоп.
В теме не ставится задача AutoBaud Detection, хотя, если её делать, нужно поступать именно таким образом, как я и предложил (другой способ придумать трудно ).
Здесь же речь идёт о подстройке RC-генератора для обеспечения наилучших временнЫх характеристик работы УАРТа при известных параметрах канала связи.

Нет, не проще. Опять же не гарантируется наличие/отсутствие/вид бита четности. Всегда лучше по стартовому биту калибровать. Соответственно калибровочный символ с лог. 1 должен начинаться.

Я отвечал на Ваш пост #30.
И почему это не зная? Параметры канала связи известны, и я знаю, в каком интервале времени мне нужно ожидать переход. Частоту генератора можно уточнять, набрав необходимую статистику, даже на "коротких" переходах , какие бывают при передаче символов вроде 0x55.

Какой такой бит четности, откуда ему взяться если передатчик его не отсылает? Напомню основное условие автокалибровки - передатчик отсылает заранее определенный символ в заранее определенном формате, приемник вычисляет интервал бита исходя из этого.
Поэтому тезис, что при посылке 0x00 интервал будет проще и точнее измерен, чем при посылке 0xFF, имеет под собой все основания. Тут, если честно, и спорить то не о чем.

Там было на что отвечать? Может на #23?Параметры известны, не известен приходящий символ...

Ну да, и на него тоже.
А вот и подумайте, как с этим можно бороться. Способ есть, и не один. Если интересно, изложу позже.

Господа, как вы думаете почему Philips использует символ '?' (0x21) для вычисления бод-рейта? Ответ прост, достаточно посмотреть на диаграмму сигнала на линии TX для этого символа:


1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 0 0 0 0 1 1 1 1 1 1 1

Последний выделенный бит - стоп-бит. который впринципе не участвует в процедуре определения бод-рейта.

При 0x21 (b'00100001')
на ТХ будет
1 1 1 1 1 0 1 0 0 0 0 1 0 0 1 1 1 1 1 1
выделены старт и стоп

Вчера весь день испытывал UART AtMega168 при работе с внутренним RC. Надо было дать банальный ответ - делать термокомпенсацию или "и так сойдет".
Работала связка AtMega168 и SIM100S. Каждую секунду отправлялось тестовое сообщение.
Тестировал в диапазоне температур 20-80 гр С. Диапазон напряжений - 3,6-4,4В. Частота RC - 8МГц, скорость UART - 9600.

Выводы - за 6 часов работы пары при +80 НИ ОДНОЙ ошибки обнаружено небыло. Частота, а следовательно и скорость передачи МК ушли по сравнению с исходным чуть меньше чем на 2% (1,8%). Существенных изменений при изменении питания не обнаружено (менее 0,1%). Тобишь, до ошибочной величины ошибки в пол бита (5%) еще о-го-го скока ...
Вот теперь сижу и думаю - проветять при -40 или не стоит - вести азот целое дело . Тем более, что и +80 и -40 это уже за пределами рабочего диапазона SIM100S, что он и показал отказавшись связываться после +70 хоть UART продолжал работать...

ЗЫ. Правда была одна малость на которой я возможно схалтурил - Мега у меня работала с двумя стоп-битами, а SIM100S с одним. Может это и не сильно важно, но....

Ой! Дико извиняюсь. не учел что LSB first.

Спасибо за исправление.



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

В обратном же направлении (2 стоп бита у приемника, 1 у передатчика) вообще неизвестно как поведет себя приемник. Может часто ошибаться, пропуская старт бит.

Азот не надо, я обычно пользуюсь FREZE для небольших испытаний. В Москве беру его в чипе и дипе.

Тестировал как и написал в обе стороны.
У Меги UART веселый - ошибку он выдает только при ошибке в первом стоп-бите. Остальные указанные стоп-биты он использует только на передачу...