Proteus общие вопросы

[Simbr]

Теперь все работает. Хорошо-бы в FAQ добавить раздел по скриптам.

да это точно

[pifa]

Вот собрал по рекомендациям Halex07 скриптовый генератор. Но вместо обычного цикла сделал байтовую передачу при каждом нажатии START.
Прием по прерываниям работает нормально. А вот с передачей в Virtual Terminal есть глюки. Я уже задавал подобный вопрос, но на него никто не ответил. Проблема вот в чем.
После приема блока из 8-ми байт включается светодиод и происходит передача блока данных из 13-ти байт, где первый байт - адрес=1. В терминале выдается в первой посылке адрес=0, а в последующих =0xB3 вместо адреса=1. Кроме того, между посылками еще один лишний байт 0xB3.
Раньше проверял в железе, работало нормально. Сейчас платы нет, проверить в железе не могу.
В чем же проблема? Это глюк терминала или я что-то не так делаю?

PROTEUS 7.5 SP3
IAR 4.30A

[pifa]

Вот еще скриншоты при передаче одного пакета и двух.

[Halex07]

To pifa
Оч похоже, что у Вас с времянками что-то не то. Обратите внимание на выпадающий горчичник о попытке записи в UDR. Он вылетает после команды обведенной рамкой.

[pifa]

To Halex007

To Pifa
Оч похоже, что у Вас с времянками что-то не то. Обратите внимание на выпадающий горчичник о попытке записи в UDR. Он вылетает после команды обведенной рамкой.

Да, этот горчичник я как-то пропустил. Дело в том, что у меня постоянно висит горчичник о невозможности моделирования в реальном времени (комп слабенький). И наличие еще одного я не увидел. Но это не меняет ситуации. И так по порядку.

1.Горчичник указывает на то, что происходит запись в UDR, когда не закончена еще передача. Но о какой передаче идет речь, если был принят пакет данных и происходит запись ПЕРВОГО байта для передачи.
Возможно Proteus что-то анализирует и хочет, чтоб все было по науке. Я добавил перед записью в UDR дополнительную проверку на опустошение буфера. Вот горчичник и исчез.

2. А ошибки то остались. Алгоритм у меня такой:
Я посылаю пакет 01 03 00 01 00 04 15 С9
В ответ должно прийти 01 03 08 00 55 00 77 00 99 00 AA 85 B3

3. В Proteus'e получаем:
Перед правильным ответ получаем лишний байт 0x00 (см. 1_1.gif)
После приема всего пакета уже при передаче первого байта из второй посылки получаем еще один лишний байт 0xB3 (см. 1_2.gif)

4. При приеме второго пакета снова вначале имеем лишний байт 0xB3 (см. 1_3.gif).

Такое впечатление, что происходит ложное срабатывание на выдачу байта из UDR того, что в нем находится в данное время:
вначале - 0x0
потом - 0xB3 последний принятый байт.

Платы с Atmega8535 у меня сейчас нет, попробовал проверить на Atmega128. В Proteus'e ошибки те же. А вот в железе все работает исправно, чего и следовало ожидать. ( см. terminal_1.gif и terminal_2.gif)
Я для проверки в терминале использовал файл для передачи (test.txt).

Так в чем же проблема? То ли глюк Proteus'a, то ли я не разобрался с какими-то нюансами работы UART. А то у меня уже была проблема с LCD, когда в железе все исправно работало, а в Proteus'e были горчичники. Оказалось, я немного отошел от datasheet. Когда сделал все по документации, гочичники пропали. Хотя в железе работало и с разными дисплеями и с разными производителями. Видимо, LCD аппроксимируют некоторые параметры, а в Proteus'e "шаг влево, шаг вправо - расстрел".

Я уже раз поднимал это вопрос, но никто не ответил.
https://kazus.ru/forums/showpost.php...postcount=1348

Такое впечатление, что у всех терминал работает нормально, только у меня глюки.
Может сейчас разберемся, что по чем. А то получается как у К.Пруткова:
"Если увидишь на клетке слона надпись буйвол, не верь глазам своим"

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

[kusia_gh]

Парни как насчёт USB ? после 7.4.3.6792 больше 10...20 сек. и прибивает HOST.
У кого-нить дольше симулирует?

[Halex07]

to Freerider and pifa
Баг, Баг, Баг!!!
В обоих случаях баги Протеуса. Поскольку для этого существует отдельная ветка подробный "разбор полетов" будет выложен там.
Отдельно для pifa. Ваше горе поправимо - забейте в обработке прерываний dry_avr.c по приему последнюю строку:
UCSRA &=~ (1 ‹‹ RXC);
Абсолютно бесполезный контент - бит RXC регистра UCSRA доступен только для чтения. Похоже вы пошли на поводу у создателей Протеуса, те тоже промахнулись битом, а вот эта ваша строчка и помогла выявить баг. Она сбрасывает бит UDRE, который по идее тоже должен быть Read Only. Отсюда и лишний байт лезет. Зато соседний бит TXC, который должон быть R/W в Протеусе ни хрена не пишется из проги.

[Freerider]

а где это ветка что то я не нашел киньте адресок пожалуйста, и еще поправима ли та проблема что я писал.

[Halex07]

а где это ветка что то я не нашел киньте адресок пожалуйста, и еще поправима ли та проблема что я писал.

Ветка - Глюки Протеуса, просто мне было некогда слепить наглядные примеры с глюками. Туда Тень чаще заглядывает, а это проблемы по его части. Проблема будет поправима вероятно в следующих версиях, поскольку потребует изменения математики обработки ADC именно в дифф. режиме, причем не одной модели, а всей линейки Мег.
Кстати проблема pifa в 7.7 уже поправлена RXD из программы не стирается, но бит TXC так и остался недоступным для записи программно, т.е. поправили, но наполовину.

[pifa]

Да, действительно сброс RXC лишний. Сейчас просмотрел datasheet. И вот что интересно. У меня этой операции раньше не было, но программа com-порта не работала нормально. И где-то мне попалась информация о том, что при выходе из программы прерываний необходимо сбросить RXC. Я добавил этот пункт. Он все равно ничего не поменял. Позже доработал программу для com-порта, а эта операция так и осталась.
Вот сейчас попробовал программу на 7.7. Действительно, даже при моем сбросе RXC все работает. Еще раз спасибо Halex07.