demiurg_spb 0 28 декабря, 2010 Опубликовано 28 декабря, 2010 · Жалоба Я ж говорю - честно высмотрел на просторах интернета эту запись.Ааа, ну тогда прощайте, дорогой товарищ! Счастливой безумной отладки! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 10 января, 2011 Опубликовано 10 января, 2011 · Жалоба Дабы не плодить темы, задам здесь свой вопрос. Хочу на ATmega8 при кварце 4 Мгц, запустить USART на 115200. В регистр UBRRL записываю число 1, согласно таблице 61 на стр. 160 в даташите на мегу8. Там указана погрешность 8,5 % при этом. Подключившись TeraTern, на этой скорости, я не вижу отчетливо передачу- прет абракадабра. Как только скорость ставлю 9600, принимается текст без искажений. Из-за чего проблема? Что 8,5% искажения? Надо подбирать кварц для 0% искажений? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 10 января, 2011 Опубликовано 10 января, 2011 · Жалоба Из-за чего проблема? Что 8,5% искажения? "Ну а сам-то как думаешь ?" (с) Надо подбирать кварц для 0% искажений? По крайней мере 2% желательно, если уж нет возможности выбрать из стандартного ряда 3.6864-7.3728-... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 43 10 января, 2011 Опубликовано 10 января, 2011 · Жалоба Из-за чего проблема? Что 8,5% искажения? Надо подбирать кварц для 0% искажений? Чтобы было 0% искажений, то надо подбирать кварц с такой частотой, чтобы она НАЦЕЛО (т.е. без остатка) делилась на нужную вам частоту в бодах 115200. Если это условие будет соблюдено, то МК сможет выбрать целочисленный делитель (а дробного у него не может быть), чтобы из кварцованной частоты получить рабочую. А если нацело не разделится, то частное придется округлить до целого делителя, и тогда рабочая частота будет получаться не точно, а с искажением. Например, кварцевые частоты 3.6864 МГц и 7.3728 МГц отлично делятся без остатка не только на 115200, но и на все более низкие бодовые частоты: 3686400 / 115200 = 32 7372800 / 115200 = 64 А раз так, то частоту 115200 можно получить из частоты кварца после деления ее на 32 или 64. При этом результат 115200 получится точно. Но вот мы берем кварц на 4 МГц и обнаруживаем, что: 4000000 / 115200 = 34.72 тогда как делитель может быть только целочисленный. Придется тогда нам округлить 34.72 до ближайшего целого, т.е. до 35. Однако с таким делителем вместо нужной вам частоты 115200, получится частота: 4000000 / 35 = 114285 которая на те 8% меньше нормы. А если бы округлили в меньшую сторону - до 34, то тогда искажение стало бы еще больше, только в сторону увеличения: 4000000 / 34 = 117647 Т.е. куда не кинь, всюду клин. Я когда-то тоже не знала про эту кухню и сильно удивлялась, отчего кварцы делают на такие "кривые" частоты :). А как стала с USART работать, так сразу поняла причину. Впрочем, с ошибкой до 2% обычно всё устойчиво работает, хотя в даташите требуют не более пол процента. Ну а 8% - это, конечно, перебор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Marchello 0 11 января, 2011 Опубликовано 11 января, 2011 · Жалоба При скорости 114285 ошибка будет 0,8%, при 117647 - чуть больше 2%. В принципе ничего криминального. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 11 января, 2011 Опубликовано 11 января, 2011 · Жалоба При скорости 114285 ошибка будет 0,8%, при 117647 - чуть больше 2%. В принципе ничего криминального. Это ошибка битового интервала, но в UART синхронизация посимвольная. На символьном интервале ваши числа нужно умножать на длину символа. Типично длина симовла 10-11 бит (старт-бит, 8 бит данных, стоп-бит, иногда еще и бит parity). Вот и получается ошибка на символьном интервале -7,9% и 21% соответственно. Чисто теоретически на некоторых типах UART ошибка на символьном интервале может достигать 50%, но зависит это от конкретной реализации UART и реальной погрешности тактовых генераторов на обеих сторонах линии связи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 11 января, 2011 Опубликовано 11 января, 2011 · Жалоба Да, спасибо всем за подробные объяснения. Буду кварц ставить другой. Похоже, 8%- это действительно перебор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DpInRock 0 11 января, 2011 Опубликовано 11 января, 2011 · Жалоба Вообще кварц не ставьте и будет вам щастья. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xemul 0 11 января, 2011 Опубликовано 11 января, 2011 · Жалоба Но вот мы берем кварц на 4 МГц и обнаруживаем, что: 4000000 / 115200 = 34.72 тогда как делитель может быть только целочисленный и, в данном случае, кратный степени 2 Придется тогда нам округлить 34.72 до 32 Однако с таким делителем вместо нужной вам частоты 115200, получится частота: 4000000 / 32 = 125000 которая на те 8% больше нормы. ну и т.д. ... 2rezident: относительная ошибка останется одинаковой и на битовом, и на символьном интервале. 2Метценгерштейн: как вариант, убрать кварц и калибровать внутренний генератор по COM-порту. Где-то в аппнотах был пример по auto-baud. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Метценгерштейн 0 11 января, 2011 Опубликовано 11 января, 2011 · Жалоба Замена кварца на 3.6864 помогла. Похоже, 8% погрешность на самом деле много. Вопрос снят. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 января, 2011 Опубликовано 11 января, 2011 · Жалоба Это ошибка битового интервала, но в UART синхронизация посимвольная Дело не в символьной синхронизации, а в том, что синхронизируется UART по стартовому биту в начале приема символа. И к концу приема набегает погрешность. Если частота кварца сдвинута на 3%, то к 10-му биту момент выборки бита сдвинется на 30%. Еще нужно учесть, что обычно выборок бита берется несколько, сдвинутых по времени, и бит определяется мажоритарным способом. Поэтому при большей погрешности уже нельзя будет правильно определить последние биты в передаваемом слове. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 11 января, 2011 Опубликовано 11 января, 2011 · Жалоба 2rezident: относительная ошибка останется одинаковой и на битовом, и на символьном интервале.Отнюдь! Ошибки битового интервала на символьном интервале суммируются. Считаем время передачи символа из 10 бит 10/114285=87,5мкс 10/115200=86,8мкс (86,8мкс-87,5мкс)*115200*100%=-8% к концу 10-го битового интервала (стоп-бит). А следом за ним (без какой-либо паузы) может идти очередной старт-бит следующего символа. Дело не в символьной синхронизации, а в том, что синхронизируется UART по стартовому биту в начале приема символа.А это не то же самое? Однократная синхронизация на периоде времени приема всего символа это разве не (по)символьная синхронизация? :laughing: Еще нужно учесть, что обычно выборок бита берется несколько, сдвинутых по времени, и бит определяется мажоритарным способом.Не во всех типах UART используется именно такой способ. Поэтому я и сделал оговорку ранее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 12 января, 2011 Опубликовано 12 января, 2011 · Жалоба А это не то же самое? Однократная синхронизация на периоде времени приема всего символа это разве не (по)символьная синхронизация? :laughing: Я понимаю символьную синхронизацию как синхронизацию по передаваемому символу, например, 0x55. То есть, приняли символ "U" (0x55) - значит, это начало передаваемого сообщения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rezident 0 12 января, 2011 Опубликовано 12 января, 2011 · Жалоба Я понимаю символьную синхронизацию как синхронизацию по передаваемому символу, например, 0x55. То есть, приняли символ "U" (0x55) - значит, это начало передаваемого сообщения.Это уже относится к протоколу связи, который поверх физического интерфейса "гуляет". Выше же обсуждался физический последовательный асинхронный интерфейс на базе UART. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 12 января, 2011 Опубликовано 12 января, 2011 · Жалоба Это уже относится к протоколу связи, который поверх физического интерфейса "гуляет". Выше же обсуждался физический последовательный асинхронный интерфейс на базе UART. Вот именно :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться