Доброго времени суток!
У меня возникла проблема с UART. Не то что бы он не работал вообще, он работает, но в младших битах переданной/принятой информации хаотически выставляются единички.

Обмен информацией с ПК осуществляется по средствам USB, и я поначалу подумал, что что-то в преобразователе интерфейса (FT232BM) - замкнул RxD и TxD, все предаётся без потерь и ошибок.

Подумал, что могут быть проблемы по питанию и возможно нехватает "подтяжки", предпринял меры:
1. Добавил дроссель по питанию и еще конденсаторов;
2. Добавил в схему подтягивающие резисторы;
3. Добавил стабилизатор напряжения 3,3В;
4. Отключил переферию....
Ничего не помогло...

Потом подумал, что возможно причина в кварце, переключил на внутренний. Тот же эффект!

Затем для чистоты эксперимента поставил AT90S2313, всё заработало с первого раза.

Вот сижу и ломаю голову, что может быть не так?

P.S.: У меня две тини, из одной и той же партии, работают одинаково плохо. Так же, пробовал правильно ли работает приемник UART, та же проблема!

Только с FTшкой такое или через MAX232 тоже биты бьются?

Возможно, фузы не переключены на кварц, и МК работает от неточного внутреннего RC-генератора

2 defunct:
С МАХ232 не пробывал, просто у меня нет СОМ порта на ноутбуке.

2 =AVR=:
С фьюзами всё супер.

Тогда - настройки UART в студию ! Мысль о несогласовании частот (BTW, а на какой скорости работаешь и какая тактовая ?) мы отвергнем как несвоевременную Поскольку "бьются" младшие биты, которые как раз передаются первыми. Вообще какие-то чудеса, такого просто не может быть. Тем более что эффект наблюдается и при приеме, и при передаче. Раз есть при передаче - встаем скопом на TxD и внимательно смотрим, а что же у нас там такое ? Вообще-то у 90s2313 и tiny2313 есть существенные различия, но в данном случае я даже не представляю, как можно сделать ТАКОЕ... Я бы начал именно с передачи, зациклив чередование передачи какого-нибудь легко читаемого паттерна (5A, A5, 55, AA), разглядывая скопом и протоколируя на терминалке. И попробовав на разных скоростях.

Сообщение отредактировал rx3apf - Aug 3 2007, 15:09

http://atmel.com/dyn/resources/prod_documents/doc4299.pdf тут читали?

Проблема в том, что скопа у меня нет.


Насчет разницы МК я знаю и о том что настраиваются по разному тоже. Инициализация УАРТа:


Я подобным занимался, с единственным отличием, вначале делал эхо, т.е. просто терминалкой передавал символы и смотрел что мне приходит, затем сделал чуть иначе запустил таймер, и по прерыванию передавал байты от 0 до 255 в цикле. Приемник проверял таким образом: брал символы из эксперимента 1 (я имею ввиду те которые были возвращены искаженными) и по очереди подставлял в условие:


Я так понимаю, остается добавить в схему МАХ232 и проверить еще с ней.


Что я там могу для себя подчеркнуть? Это же описангие перехода от AT90S1200 к ATTiny2313.

Похоже у вас неверно вычисляется BAUD.
У вас используется фомула для получения частоты из значения UBRR-регисра F_CPU/(16 * (BR + 1)) ,
а нужно по обратной: #define BAUD (F_CPU/16/BR - 1)

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

A header file меняете для attiny2313 ?

может на 90ат2313 собрать схемку и по инпут капче измерить длительность импулься для передачи байта 0х00 без парити и выдавать значение в 8 битный порт а оттуда тестером или ледами увидеть длину сигнала?

Меняли тини2313 на другой?

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

Неправду говорите, молодой человек ;>

Fosc = 11.0592?

сравним 11059200 / 16 / 115201 = 6
и
11059200 / 16 / 115200 - 1 = 5

115200 * 5/6 = 96000baud

Ошибка эта очень сильно повлияет. Ведь разница частот получается ~20%! Это значит гарантированно каждый кадр будет битым, т.к. ошибка на кадр составит 20%*10бит = 200%

Я всё проверил после того как исправил ошибку.