ATMega48 соединена с FT232BL через TDX/RDX. По нажатию кнопки передаётся два байта на FT232BL:




}

Однако результат следующий. Во-первых, за раз отправляется только один байт. Во-вторых, он всегда равен 127 (в 7-битном режиме) или 255 (в 8-битном режиме). В-третьих, даже этот неверный байт отсылается не стабильно: в 60-70% случаев байт не отправляется, хотя лампочка мигает (т.е. условие нажатия выполняется).

Кроме того, приём байта вообще не работает.

Подозреваю, что причина - в неправильной работе с UART.

Вы присваиваете значение делителя локальным переменным с именами UBRRH и UBRRL, а не регистрам.

Угу. Исправил. Теперь глючит немного по-другому.

Если отправить байты "10" и "15", то на ПК считывает три (!) байта: 152,152,248

Если отправить один байт "10", считываются два байта: 152,248.

Если отправить один байт "15", считываются два байта: 152,248.

Если изменить скорость UART на 19200 и отправить байт "15", то считывается два байта: 254,252.

Скорости UART, ессно уставнавливались на ATMEGA48 и FT245BL одинаковые (сначала 9600, потом 19200). Формат передачи - 8-битный (пробовал и 7-битный - результат тот же, только получаемые байты другие).

Тут или код врёт, или комментарий к нему Copy\paste - великий источник ошибок в программе.

Впрочем, все равно может не работать. Потому что еще надо фьюзы выбора источника тактирования и деления частоты проверить. И значение F_CPU.

Ага, около того. Неплохо было бы заголовок темы сменить, а?

Сообщение отредактировал SysRq - May 16 2009, 13:39

Начинать приходится с copy/paste. А потом разбираться с кодом.



Биты регистра установил на основе данной странички (http://mcu.narod.ru/HARDANDSOFT/AVR_UART.htm). Там, правда, написано о ATMEGA128, но наименования битов в iom48p.h должны быть такими же (?).

На ПК (драйвер микросхемы FT232BL) установлено:


Результат передачи данных всё тот же: вместо 1 байта передается 2 неправильных.

Тут, правда я не совесем понял. Начальный и стоп-биты входят во фрейм или нет? Т.е. если я установил фрейм в 8 бит и 1 стоп-бит, то получится 6 бит данных? Правильно?

Кроме того, я посмотрел файл iom48.h



Это нормально, что биты UCSZ00 и UCPHA0 занимают одно и то же место в регистре? И почему бит UCSZ02 находится в регистре UCSR0B, а остальны 2 бита (UCSZ00 и UCSZ01) в регистре UCSR0С? Тут (http://mcu.narod.ru/HARDANDSOFT/AVR_UART.htm) все они расположены во одном регистре.

А если установить UCSZ02 в единицу (чтобы передать 9-битный фрейм), то передача реально вообще не происходит.
Можно и сменить. Только я не модератор, как я его сменю?

Не фрейма, а данных размер это.

А это не фрейма, это данных размер...

Почему бы не взять официальный документ от Atmel на МК и не посмотреть (Яндекс\Google знает)? Для всех МК все по-разному.

PS: USART в асинхронном режиме на 19200 работать при 2МГц не будет. Слишком велика ошибка - 7%. Оставьте 9600.

Т.е. и там, и там надо поставить по 8 бит? Стартовые и стоп-биты считаются отдельно?

Насчёт скорости - поставил 9600. Потом поставил 7200. Потом поставил 300. Результат аналогичный. Причём обнаружена некоторая закономерность:



Слева указан байт (в виде десятичного числа), передаваемый через USART_vSendByte. Правее - два байта, получаемых на ПК. Ещё правее - двоичный вид первого полученного байта. Нетрудно заметить, что 7-й бит первого полученного числа равен 3-му биту изначального числа; 6-й и 5-й бит равен 2-му биту изначального числа; 4-й и 3-й - 1-му биту изначального числа; 2-й и 1-й - 0-му биту изначального числа; 0-й бит всегда равен нулю. При этом первый полученный байт чередуется через 16, т.е первый байт для "изначальных" чисел 0,16,32,48... - один и тот же.

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

Кроме того, для некоторых чисел выдается одна и та же пара бит (например, для "изначальных" чисел 112 и 160 выдаётся "0,254"). Т.е. получается, что получаемые данные не определяют однозначно отправленное число.

Очевидно, что скорость передатчика примерно вдвое ниже скорости приемника.


Да.

Пока сообщение набивал, да отвлекался, все уже до меня рассказали

Попытка "восстановить" исходные данные по "результату" достойна уважения
Выставляйте одинаковые параметры фрейма 8-N-1 (8 бит данных, четности нет, стоповый один), в МК 9600, а на компе пробуйте 4800 (судя по всему, МК на 1МГц работает).

PS: поинтересуйтесь в качестве чтива на ночь как работает асинхронный USART: состав фрейма, как детектируется начало посылки, как передаются данные и как они восстанавливаются на приёмной стороне, зачем нужен стоп-бит, как детектируются ошибка фрейма, ошибка четности. В инете описаний масса.

Сообщение отредактировал SysRq - May 16 2009, 19:51

Гыг! Именно это я и сделал. На МК поставил 9600, на ПК 19200. Кроме того, на МК поставил 8 бит данных, а на ПК - 7 бит. И заработало.

Только я не понял:
1) Почему заработало? Ещё можно предположить, что МК работает на 1 Мгц (щас полезу в документацию), то при чём тут количество бит данных? (если биты данных на МК и ПК сделать равными, то вместо 0 выдаётся 128, вместо 1 - 129 и т.п.)
2) Как передать 8-битную структуру? Сейчас, выходит, передаётся по 7 бит (?).
3) Как вы поняли, что скорость передатчика вдвое ниже скорости приёмника? Потому два бита подряд дублируются? Но почему передача начинается с 3-го бита, а не с 7-го?

Исключительно повезло, что оно работает.

Больше ничего не подскажу принципиально

Ознакомился. Как оказалось, передача всё-таки работала неправильно. По-видимому, вместо последнего (старшего) бита читался стоповый бит, в результате вместо 0 появлялось значение 128. Я элегантно "исправил" это недоразумение, установив на ПК 7-битный формат данных.

Правда, дальше проявилась другая ошибка - иногда заменялся один из бит (т.е. полученное число оказывалось на 2^N больше/меньше, чем оригинальное). Пришлось умерить свои амбиции и установить битрейт в 4800. При этом 8-битный пакет данных стал читаться нормально (стоповый бит не проявлялся), ошибочный бит появляться перестал.

Всё хорошо. Только вот 4200 бит! И это в 21-м веке, когда космические коабли бороздят просторы Вселенной! Маловато.

Кроме того, МК работает на 1 Мгц (а я сначала думал - на 2), значит, на передачу бита уходит 238 "тиков". Если установить битрейт 9600, то будет 119 тиков. Неужели это так мало? Я ещё понимаю, что при 5-10-15 тиках могут (и должны) быть ошибки в отлове битов, но 119 тиков!!! Хотя, конечно, могут (а могут?!) быть погрешности в частоте кварца: вместо 1 МГц реально там 0,9 МГц, в итоге сигнал "растягивается", и появляются ошибки. Но я не знаю, 10%-я погрешность - это нормально для встроенного в МК (!) генератора фирмы Atmel?!

Мама дорогая.
В древности отроков, которые даташитов не читают - пороли на конюшне.
Уберите галочку у CLKDIV8, если понипрог используете.
И думайте, что МК работает на 8МГц. Типо, предположите...

Чтобы обеспечить стабильную работу UART, отклонение частоты не должно превышать 1.5%. Внутренний RC без калибровки тут не подходит.

Чисто случайно юзаю мегу48 на 9600 уже давно. Наблюдаю устройства в небольшой серии (сотни).
Как раз на внутреннем генераторе. На 9600 проблем нет.

Хотя с внутренним генератором стараюсь не делать ничего. Просто удобнее не думать о погрешностях. И черт с ней, с ценой.
Просто совсем малопотребляющие делать с внешним кварцем не сильно кошерно.