Используется бридж USB to UART СР2101 silabs.
Запускаю передачу файла через гипиертерминал. Файл состоит из последовательности ASCII цифорок.
На меге творится что-то странное. На 9600 иногда принимается нормально, иногда через байт то есть например передаю несколько раз 2. на приёме вижу 0х32 0хb2 0x32 0xb2 ... и т.д. со всеми цифрами.
Ситауация исправилась, когда на гипертерминале ставлю два стоп бита.
На скорости 38400 два стоп бита уже не спасают.

Мега работаёт на внутреннем RC генераторе на 4 Мгц. При старте программы генератор калибруется по внешнему часовому кварцу, который для асинхронного таймера.

бодрейт считается так.


Вообще что это такое может быть?

З.Ы.

Гоняю данные другой терминальной программой всё ок и на приём и на передачу.

[удалил НЕНУЖНОЕ цитирование]


Может быть установка параметра Com порта: "Управление потоком" в GT в в состояние "Нет"
поможет ?

Может дело не в меге, раз с другой терминалкой работает все? можно попробовать для теста затактировать мегу от кварца, например 7,3728 МГц, ну или с кратным ему, т.е. с таким при котором ошибка скорости заведомо небольшая, а может вы как то не правильно генератор калибруете, попробуйте его не программно откалибровать а воспользоваться калибровочной константой.

Ну затактировать от кварца к сожалению не могу. Изделия уже были разработаны до моего появления в компании.

Управление потоком тоже отключить не могу, так используется в данном Application.

Все мои тестовые аппликейшены по несколько часов работали на приём/передачу с компом без ошибок.

Калибровка производится правильно. Хотя... Вот код на поругание общественностью

А на ноги припаять кварц нельзя чтоли? Я ж говорю, для теста.

А в чем тогда вообще проблема? В том что не работает с конкретным гипертерминалом? На другом компе можно еще попробовать, может это глюк конкретного компа.

Сейчас и попросил тестеров это сделать. Другим терминалом попробовать, попробовать запустить не через USB бридж а напрямую на уарт... Жду пока от них результатов.

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

Попробуйте напрямую выдать сигнал на ножку OC2A (или OC2B) в режиме output compare match и померить частоту сигнала с помощью частотомера. Отсюда легко будет вычислить скорость приёма по рс232.

Кроме отклонения RC от номинального значения есть ещё и отклонение частоты UART от номинала за счёт "неUART-ности" частоты в 4МГц.
Я на меге64 внутренний RC 8MHz калибровал по часовому кварцу на 7,373MHz (по апнотам по калибровке можно калибровать в пределах +-10% от базовой частоты) и на 115200 работало без проблем.
Но я калибровал не при старте, а постоянно - SQW от DS1338 было заведено на прерывание и замерялось внутренним таймером расстояние между перепадами (0,5с), подкалибровывался OSCCAL.
Даже "на столе" RC немного плывёт, особенно после старта, поэтому однократная калибровка сразу после включения может быть недостаточной для работы. А уж при изменении температуры...
Но при подкалибровке каждые 0,5секунды работало в том числе при нагреве феном и при охлаждении FREEZ-ом вплоть до образования инея на плате.

Попробуйте "сменить" ПО на РС. AVR, наверняка, не при чем, потому что...:

Примерно год назад столкнулся с аналогичной проблемой. Даже тему по этому поводу открывал. Причем я был в полной уверенности, что неправильно работает контроллер. Вроде бы, нашел причину (скорость снизил), сказал "спасибо", а на следующий день проблема вернулась...
.....
Причина, на мой взгляд, не в контроллере и его инициализации, а в работе, настройках и инициализации последовательного порта, или VCP в Вашем случае, на PC.
Я писал свою программу на Borland'e, при этом для RS232 использовал класс ПП (Последовательного Порта) от "comspy" (freeofcharge).
Точно так же "болел" старший бит. Причем болезнь была приходящей (плавающей).
Не помогало ни чего... Ни изменение скорости обмена, ни замена контроллера, ни смена компьютера, ни экранировка каждого провода в соединительном кабеле (до "маразма" доходил в попытках понять причину болезни )
Вылечил, заменив класс ПП от comspy на аналогичный от г-на Горского.
Все написанные позже проги с использованием класса от Горского работают с ПП (во всех его видах) на "Ура".
....

В "описании" происходящего процесса целиком и полностью согласен с =GM=:

А вот чего я понять не смог, так это того в чем все-таки разница в инициализации ПП на РС. Оба указанных класса инициализируют ПП "классически" и фактически одинаково.
....
И еще по этому поводу...
http://electronix.ru/forum/index.php?act=S...f=48&t=7846

Не верю! Читайте написанное ReAl.

Полемику по этому поводу считаю бессмысленной. Я, безусловно, могу ошибаться.
Во всяком случае, для поисков неисправности "в" контроллере сначала необходимо убедиться в правильной работе интерфейса. Именно о таких "граблях" я хочу предупредить.
Советуя обратить внимание на ПО РС, я исходил из:

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

P.S.
Вот comspy от г-на М.Белоусова.
А вот статья и собственно класс для работы с ПП от г-на Ю.Горского. Нажмите для просмотра прикрепленного файла

К стати баг проявляется только в гипертерминале, тестеры погоняли данные Zoc'ом и там всё ок.

Мне кажется, что здесь скорее зависит всё от дров которые на писишке применяются. Потому что мелкосхемы UART'ов имеют множество дополнительной функциональности. А юзеру писишки предоставляется некий стандартный интерфейс, который обеспечивается виндовыми дровами и который множество функций просто не задействует.
Сам с подобным сталкивался, когда писал софт на писишке для управления микросхемой расширения ISA шины в 4 UARTа. И когда решил применить свой код к UARTу, который стоял на материнке, то к удивлению аппаратные FIFO буферы, документированные для микросхемы, заработали и на материнке.

Я думаю, что проблема комплексная гипертерминал кривой и калибровку генератора криво провожу. Посмотрел дизасм кода калибровки в раличных режимах оптимизации. В -O0 она действительно 7 тактов, а при -Os я так и не смог в процедуре понять где она эта калибровка начинается, а где заканчивается, но есть большое подозрение, что она уже не 7 тактов.

Насколько я помню, были чипы 16450 без FIFO, 16550 с глючным FIFO и 16550A с поправленным. И не помню - можна ли было определить разницу между 16550 и 16550А программно.
В свойствах порта у винды можна было поставить/снять галку "использовать FIFO" и подвигать ползунки порога прерывания на приём и передачу - может, просто в Вашем случае драйвер сам не понял, стоит у него чип с нормальным FIFO или с глючным и галка по умолчанию была снята.
Я сам иногда снимал, когда приходилось работать с чужим оборудованием с встроенной программой, которая захлёбывалась, если от компа валил "зафифошенный" поток без пауз.

А зачем было вообще так делать? Сделайте так:
Прерывание по таймеру2, когда он отсчитал нужное число циклов (причём это можно делать не только при старте, см. мой предыдущий пост), в этом прерывании чтение нового состояния таймера1, определение дельты с предыдущим состоянием таймера1 и подкоррекция OSCCAL прямо в прерывании. Разброс времени входа в прерывание чепуха по сравнению с периодом прерываний, RC-генератор всё равно грубее шаг имеет. Я метки времени от внешних часов даже не на ICP заводил а на обычное прерывание, смысла нет выжимать лучше нескольких сот микросекунд на фоне 0,5секунды (это 0,1%, куда тому RC).
И никакой зависимости от оптимизатора (если работа программы зависит от установленного уровня оптимизации компилятора, то в 99.9% случаев это ляп или как минимум недоработка разработчика программы).

Полностью согласен.

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

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

Такой код надо проверят в первую очередь

Если "критическая секция" займёт аж милисекунду, то что-то очень неправильно в Датском королевстве. Но даже в этом случае ошибка будет на уровне 1мс/500мс = 0,2% - при шаге перестройке RC на единичку OSCCAL в несколько раз больше эта ошибка не повлияет на калибровку.

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

недавно сам столкнулся с подобной проблеммой.
Решение: вместо вычистения скорости по формуле в регистр UBRR записал пердопределенную константу из даташита.

Пример:
u16 bauddiv = 51;
outb(UBRRL, bauddiv);
#ifdef UBRRH
outb(UBRRH, bauddiv>>8);
#endif

А вот еще был случай...Короче опторазвязанный USART сбоил из-за оптрона - затягивал фронты.

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

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

Я в шоке , похоже это первый и последний раз когда я использую гипертерминал.

З.Ы.
Один плюс из всего этого... Калибровку сделал нормальную

У меня тоже были проблемы с передачей данных по UART, пока не сделал так:

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

Проблема в Hyperterminal, причём проявлется только на машинах DELL. Почему не знаю.

Только данная проблема проявляется не только на avr, точно так же не работают атмеловские армы через uart. И что меня окончательно убедило в том, что проблемы в писюке, так это то, что реализованный virtual com port на usb, получил такие же проблемы. Битые подобным образом байты наболюдал usb sniffer'ом SnoopyPro в bulk out канале.

На сим тему считаю завершённой.

Moderator:
Не сочтите за труд не заниматься тупым ненужным цитированием постов.