Глючит uasart в mega16

[vynt]

http://yadi.sk/d/DkqD4sNL5liFV
скриншот симулятора, мега слушает сама себя, в терминале справа вверху то что мега передаёт, справа внизу буфер приёмника меги, видно что получает она то же что передаёт...

[tempora]

Сообщение от vynt

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

В AVR это крайне маловероятно - доступ разный, эт не STM.

Не такой уж он и разный. Сделать так, чтобы компилятор разместил переменные в I/O-адресах, действительно "трудновато", но стеком туда "наступить" или отрицательными индексами в массивах - вполне возможно, я думаю. Стек, разумеется, перед этим все переменные затрет.

[vynt]

Терминал для отладки, при рождении проект успешно работал с сотовым телефоном, теперь с модемом. Типа эволюционирует.

Осциллограф Вам в помощь! Это терминал (вернее RS232 компа) коверкает символы на RX. Программа принимает то что сама передаёт без искажений. Уберёте "подслушивающий" терминал с шины RX, МК будет принимать от модема так же всё без искажений. 99,9% гарантии, с одной оговоркой, что частота точно 8МГц.
Если терминал всё таки нужен, ставьте в разрыв "RX - терминал" диод, пойдёт любой т.к. скорость 9600 не такая уж и высокая. После отладки диод можно убирать. Диод в сторону терминала должен пропускать только +12(логический ноль). TX(модема) - TTL/RS232 - точка подключения терминала - RS232/TTL - RX(меги). У Вас такое соединение? комп к точке подключения цеплять так: точка подключения - диод -|›|- RS232 (терминал). TX терминала вообще не подключать, или так же через диод, но поставить наоборот.
Смысл этих манипуляций - устранить влияние подвешивающей единицы (-12В) с порта компьютера.
з.ы.
схема "Кабель контроля (мониторинга) RS-232"
http://www.gaw.ru/html.cgi/txt/inter...s232/start.htm
з.ы.ы.
для надёжности, я бы ещё один диод воткнул и так: ... точка подключения терминала -|›| - RS232/TTL - RX(меги)

[TechMike]

Осциллограф Вам в помощь! Это терминал (вернее RS232 компа) коверкает символы на RX. Программа принимает то что сама передаёт без искажений. Уберёте "подслушивающий" терминал с шины RX, МК будет принимать от модема так же всё без искажений. 99,9% гарантии, с одной оговоркой, что частота точно 8МГц.
Если терминал всё таки нужен, ставьте в разрыв "RX - терминал" диод, пойдёт любой т.к. скорость 9600 не такая уж и высокая. После отладки диод можно убирать. Диод в сторону терминала должен пропускать только +12(логический ноль). TX(модема) - TTL/RS232 - точка подключения терминала - RS232/TTL - RX(меги). У Вас такое соединение? комп к точке подключения цеплять так: точка подключения - диод -|›|- RS232 (терминал). TX терминала вообще не подключать, или так же через диод, но поставить наоборот.
Смысл этих манипуляций - устранить влияние подвешивающей единицы (-12В) с порта компьютера.
з.ы.
схема "Кабель контроля (мониторинга) RS-232"
http://www.gaw.ru/html.cgi/txt/inter...s232/start.htm
з.ы.ы.
для надёжности, я бы ещё один диод воткнул и так: ... точка подключения терминала -|›| - RS232/TTL - RX(меги)

Так у меня и было с прошлой схемой, через два диода подключена была max232 и это только для мониторинга. Сейчас попробую восстановить на макетке и выключить max232 на модеме.

[Someone]

флаг RXC конечно же

The Receive Complete (RXC) Flag indicates if there are unread data present in the receive buffer. This flag is one when unread data exist in the receive buffer, and zero when the receive buffer is empty (i.e., does not contain any unread data). If the receiver is disabled (RXEN = 0), the receive buffer will be flushed and consequently the RXC bit will become zero.

Повторюсь. Никакие циклы в обычных условиях не нужны. Достаточно отключить модуль. В авр почти всё чётко логично, и незачем плодить сущности.

[vynt]

The Receive Complete (RXC) Flag indicates if there are unread data present in the receive buffer. This flag is one when unread data exist in the receive buffer, and zero when the receive buffer is empty (i.e., does not contain any unread data). If the receiver is disabled (RXEN = 0), the receive buffer will be flushed and consequently the RXC bit will become zero.

Повторюсь. Никакие циклы в обычных условиях не нужны. Достаточно отключить модуль. В авр почти всё чётко логично, и незачем плодить сущности.

Хм...Вы что, диллер ATMEL?
Эх, взять хотя бы в пример обсуждаемую программу... В теле main присутствуют CLI и SEI, если между этими вызовами выполняться два условия: приём окончен и произойдёт сброс (сработает вачдог внутренний или внешний, или поступит внешний сброс, или глюканёт программа и перескочит на нулевой адрес) - прерывания UART не будут выполнятся до выключения питания или до чтения из UDR байта. Ситуацию не сложно генерировать: пускаем TX на RX, включаем UART (с настройками прерываний), заводим вачдог, передаём один байт (именно так, глобально прерывания не разрешаем, или разрешаем но байт не считываем), и всё... через время сработает вачдог, мега сброситься но UART больше ничего не сможет принять... Ну да ладно, нет так нет. Я подсветил грабли, а наступать на них или нет дело личное.

the receive buffer может быть и be flushed а вот consequently the RXC bit will become zero фигушки... В самом начале инициализации UARTа у меня, если заметили, присутствует присвоение UCSRB=0. Практика показала, что не достаточно этого чтобы после описанной проблемы вновь завезти UART на срабатывание по прерыванию.

[Someone]

Хм...Вы что, диллер ATMEL?

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

Ситуацию не сложно генерировать: пускаем TX на RX, включаем UART (с настройками прерываний), заводим вачдог, передаём один байт (именно так, глобально прерывания не разрешаем, или разрешаем но байт не считываем), и всё... через время сработает вачдог, мега сброситься но UART больше ничего не сможет принять

Ну так накидайте код, проверим, почему за более чем десятилетие существования архитектуры авр такой глюк с флагами не только не вошел в ерраты, но и как-то миновал сотни тысяч пользователей с десятками тысяч проектов (впрочем, за 10 лет и программистов, и проектов, может и поболя набраться)

[TechMike]

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