Proteus - глюки, проблемы с установкой

[avr123-nm-ru]

Еще в том же проекте - мы уже в прерывании, и несколько строк выполнено, а флаг этого прерывания в TIFR бит 7 все еще 1.

понажимал F11 ...

ВООБЩЕ угар ! этот флаг очистился после строки
TIFR |= 0x40;

т.е. после очистки бита 6 !

=========

Может биты 6 и 7 перепутаны в TIFR в PROTEUS ?

=========
Проверил АСМ от CVAVR - он такой

; 150 TIFR |= 0x80; // очистить флаг OCR2
IN R30,0x38
ORI R30,0x80
OUT 0x38,R30

; 188 TIFR |= 0x40; // очистить флаг переполнения таймер 2
RCALL SUBOPT_0x0

;OPTIMIZER ADDED SUBROUTINE, CALLED 5 TIMES, CODE SIZE REDUCTION:6 WORDS
SUBOPT_0x0:
IN R30,0x38
ORI R30,0x40
OUT 0x38,R30
RET

т.е. в АСМ-е все верно.

==========

Включил АСМ в PROTEUS - он выдает вызов
RCALL $0416

но найти его не удалось а при шагании F11 возникаеи серое окно без исходного кода

" Но соус лайн эт ПС адрес PC=0416 "

-- Прилагается рисунок: --

[avr123-nm-ru]

Следующий прикол ! Смотрите два флага стоят - 7 и 6 в TIFR ( хотя мы в прерывании которое должно было опустиь флаг бит 7 )

проект в архиве выше

картинка 1

-- Прилагается рисунок: --

[avr123-nm-ru]

А выполнение строки сброса флага бит 6 сбрасывает ОБА флага.

картинка 2.

-- Прилагается рисунок: --

[Halex07]

2avr123-nm-ru
Маленький нюанс: по ссылке лежит пример в котором этого не происходит. Для того чтобы получить ваши результаты необходимо сначала в CVAVR перекомпилировать проект.
Но похоже все та же старая песня с неправильным вычислением адреса относительного вызова подпрограммы RCALL, равно как и аналогичные переходы RJMP.
Эх, Nemo попросить бы глянуть нельзя ли прямо в откомпилированной библиотеке поправить.Тень нам вряд ли поможет - неэтично по отношению к своей фирме. А неплохо было бы патчик выпустить. Наверно и лицензионные пользователи пострадали.

[LEAS]

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

[avr123-nm-ru]

А я все же использую PROTEUS и он очень помогает - ГЛАВНОЕ глюки его легко обнаружимы !

[BSA-elec]

2avr123-nm-ru
Маленький нюанс: по ссылке лежит пример в котором этого не происходит. Для того чтобы получить ваши результаты необходимо сначала в CVAVR перекомпилировать проект.
Но похоже все та же старая песня с неправильным вычислением адреса относительного вызова подпрограммы RCALL, равно как и аналогичные переходы RJMP.
Эх, Nemo попросить бы глянуть нельзя ли прямо в откомпилированной библиотеке поправить.Тень нам вряд ли поможет - неэтично по отношению к своей фирме. А неплохо было бы патчик выпустить. Наверно и лицензионные пользователи пострадали.

Можно оформить баг-репорт с примером и скриншотами с точным указанием ошибок, а я в свою очередь как лицензионный пользователь отошлю его в Лабцентр. Хотя, что касается RCALL, то в версии 7.6 данная ошибка вроде бы уже исправлена. Если хотите, можете выложить здесь проект, вызывающий ошибку, а я его проверю.

[Halex07]

2BSA-elec А зачем отсылать, если она уже поправлена. Когда она была обнаружена, кстати не без нашего участия, Лабцентр был извещен. Просто поправлена она уже в версии 7.6, а "честные пираты" пока сидят на 7.5 и жутко мучаются от этого бага AVR2.DLL.

[BSA-elec]

2BSA-elec А зачем отсылать, если она уже поправлена. Когда она была обнаружена, кстати не без нашего участия, Лабцентр был извещен. Просто поправлена она уже в версии 7.6, а "честные пираты" пока сидят на 7.5 и жутко мучаются от этого бага AVR2.DLL.

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

[dimonbest]

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

В таком случае вот - глюк SPI.
https://kazus.ru/forum/topic_12550-0-asc-840.html
Тень на следующей странице сказал, что исправить будет не так то просто...