Вопросы и замечания по топику - FAQ по PROTEUS

[123ksn]

Может плохо искал, но не нашёл как сделать из PATTERN GENERATOR или Виртуального терминала генератор потока символов в формате протокола RS232 (USART) что бы подать его на USART-вход МК. Единственное, что я нашёл - это предлагают подключить протеус к COM порту ПК и из какой-нибудь терминалки передавать из COM порта поток символов. Можно конечно, но это как из пушки по воробьям. Кто-то спросит зачем? В проекте информация от USART обрабатывается в прерывании. В зависимости от поступившей информации очень сильно меняется алгоритм обработки. Поэтому хочется забить канал потоком информации (в том числе и ошибочной) и посмотреть успеет ли программа обработать такую ситуацию.

[Halex07]

Может плохо искал, но не нашёл как сделать из PATTERN GENERATOR или Виртуального терминала генератор потока символов в формате протокола RS232 (USART) что бы подать его на USART-вход МК.

Вот это действительно стрельба из пушки по воробъям, хотя с PATTERN GENERATOR и можно проделать такое, используя один разряд из восьми (последний на сегодня материал в FAQ). А искать надо было поближе:
Proteus 7 Professional\SAMPLES\Generator Scripts\Serial Data Generator.DSN

[bmwxmiha]

Начните с прочтения вот этого:http://microcap-model.narod.ru/modelling.htm
Всем начинающим рекомендую.

огромное спасибо! всё стало понятно!

[123ksn]

Большое спасибо за помощь с генератором RS232 (USART) в протеусе. Он мне здорово помог. Обнаружилось, что код перестаёт правильно работать из-за переполнения стека. Но встал другой вопрос: Как отследить момент переполнения стека? Как известно, в PIC16F87X такой возможности нет. Где-то читал, что MPLAB при переполнении стека выдаёт соответствующее ругательство, но настроить в stimulus генератор RS232 (USART) не умею, хоть и прочитал файл 11016. Вы помогли информацией по генератору RS232 (USART) в протеусе. Помогите, пожалуйста, ещё раз. Как отследить момент переполнения стека в протеусе? Да, протеус у меня 7.7 sp2 rus.

[Алекс Василич]

А вот у PIC-ов этой вот серии нет возможности управлять стеком и контроллировать его. Вся ответственность за переполнение стека лежит целиком на программисте.
В MPLAB-е есть окно Hardware stack с указателем стека. В протеусе тоже есть аналогичное окно. по нему и отслеживай заполнение.
Еще на этапе написания программы нужно следить за тем, чтобы количество переходов в прерывания или по команде call было равно количеству возвратов (return, retlw, retfie). Ну и разумеется, не превышало глубину стека.
В более современных и сложных сериях PIC-ов есть возможность управлять стеком, отслеживать и программно реагировать на его переполнение.
В MPLAB-е, если использовать его собственный симулятор, в случае переволнения стека будет выдано сообщение Stack over flow error occurred from instruction a 0х... с указанием адреса. Сообщение выводится в окне Output.
В протеусе в строке состояния есть simulation log. При ошибке там будет появляться желтый треугольник. Можно просмотреть лог и увидеть, в какой строке произошло переполнение стека.
Можно так же в Configure Diagnostics для PIC установить в параметре Instructio nExecution галочку Suspend simulation whenewer an event is logged - и тогда симуляция приостановится при переполнении стека.

При написании кода нужно категорически избегать конструкций типа таких (красным выделена ошибка):

odin:
	call dva
	nop
...
dva:
	nop
	goto odin

или

	goto odin
	nop
...
odin:
	nop
	return
	nop
	goto odin

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

Interrupt:
	nop
	goto odin
	nop
	retfie
...
odin:
	nop
	goto Work
...
Work:
	nop
	goto Work

или же попадание в подпрограмму прерываний иначе, чем непосредственно по прерыванию:

Interrupt:
	nop
	goto odin
	nop
dva:
	retfie
...
odin:
	nop
	goto dva
...
Work:
	nop
	goto odin

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

[123ksn]

В протеусе в строке состояния есть simulation log. При ошибке там будет появляться желтый треугольник. Можно просмотреть лог и увидеть, в какой строке произошло переполнение стека.

Василич, спасибо Вам за такой большой подробный совет. Для меня было полезно следующая информация:

В протеусе в строке состояния есть simulation log. При ошибке там будет появляться желтый треугольник. Можно просмотреть лог и увидеть, в какой строке произошло переполнение стека.

У меня желтого треугольника нет. И в окне лога тоже ругательства нет.Значит это не переполнение стека, хотя все 8 строк в нем заняты и при дальнейшей трассировке(кажется это слово уместно), изменяются только первая и вторая строка.

Можно так же в Configure Diagnostics для PIC установить в параметре Instructio nExecution галочку Suspend simulation whenewer an event is logged - и тогда симуляция приостановится при переполнении стека.

И этого я не знал. Новичёк, однако.
Большое спасибо. Буду думать дальше.

[Алекс Василич]

Значит это не переполнение стека, хотя все 8 строк в нем заняты и при дальнейшей трассировке(кажется это слово уместно), изменяются только первая и вторая строка.

Ааа, дак все верно, в стеке изначально может содержаться случайная информация.
А определяющим элементом является указатель вершины стека TOS, то есть того места, куда будет помещен адрес возврата. Если он доходит до самого нижнего уровня, то следующий переход по call или прерыванию переместит указатель стека в самую верхнюю позицию и потом именно туда запишется адрес возврата, заменяя старое значение. Это и будет переполнение стека (У PIC16F87X восьмиуровневый стек, то есть, максимум восемь вложенных вызовов).
При возврате (return, retlw, retfie) указатель стека будет перемещаться в обратном направлении. Но, если происходило переполнение на один уровень больше максимума, то в первой ячейке стека записан другой, замененный адрес возврата. Значит, программа не сможет вернуться в то место, откуда началась вся очередь вложенных вызовов и будет работать неправильно.

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

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

Work:	nop
	call raz
	nop
	goto Work
;-------------------
raz:	call dva
	return
;-------------------
dva:	call tri
	return
;-------------------
tri:	call chetyre
	return
;-------------------
chetyre:
	call pyat
	return
;-------------------
pyat:	call shest
	return
;-------------------
shest:	call sem
	return
;-------------------
sem:	call vosem
	return
;-------------------
vosem:	call devyat
	return
;-------------------
devyat:	nop
	return

[123ksn]

в стеке изначально может содержаться случайная информация.

Даже подумать о таком не мог! Т.е. программу можно начинать с return и она может и заработать. Понятно, что компилятор не пропустит, но никто не мешает ручками HEX файл "поправить". Был уверен, что происходит стартовая очистка всех регистров. Спасибо.

[Алекс Василич]

Как раз-таки компилятор и пропустит. Он не пропускает синтаксические ошибки, а вот структурные - пропустит без проблем.
Если начать с return, то программа работать будет, но непредсказуемо. Поскольку адрес из стека может быть совершенно неизвестным, то и переход произойдет в совершенно неизвестное место памяти программ, и кто его знает, что там окажется по этому адресу... Если переход будет выполнен в место, где уже нет программного кода, то счетчик команд досчитает до переполнения, сбросится и начнет заново. А в начале - return и опять вылет за пределы полезного кода.
О том, какие регистры очищаются при сбросе по включению питания, можно узнать из даташита контроллера. Скажу, что да-а-алеко не все.

[nanogul]

Если с компиляторами с языков высокого уровня,
где обычно присутствуют стандартные библиотеки для HD44780, такое случается очень редко, то
использование в собственных разработках чужих ассемблерных программ инициализации ЖКИ, а
уж тем более готовых HEX прошивок может надолго загнать вас в тупиковое положение. Причем,
это совсем не значит, что прошивки не рабочие. Реальные дисплеи на основе данных контроллеров
допускают некоторую вольность в обращении к ним. В результате программа, которая многократно
повторялась в железе, работает в симуляторе криво, а иногда и вообще не работает. Но, сами
понимаете, что написать такую математическую модель, которая будет автоматически
предусматривать, что некто Вася или Петя решил подсократить выдержку при инициализации со
стандартных для HD44780 более чем 40ms до 12ms, потому что у него под рукой был русский
МЭЛТ-овский дисплей практически невозможно, а уж тем более если часть команд инициализации
вообще отсутсвует. К счастью, такие опусы легко распознаются в ISIS, даже при отсутствии
исходника программы.
И как у нас может вывестись вторая строка, если двухстрочный режим
даже не задан (lines=1). Самое интересное, что в железе это работает!!! Исправно выводится текст
во вторую строку. Вот такой «запас прочности» у контроллера HD44780. Только вот вопрос – стоит 77
ли всегда надеяться на этот запас по любимому русскому принципу – «авось пронесет»? Вот и
получается, что у автора работает, еще у 11 человек тоже, а тот пресловутый тринадцатый, у
которого дисплей из «темного китайского подвала» остается в дураках.
Ну и законный вопрос – а можно ли в Протеусе увидеть нижнюю строку этого девайса?
Конечно можно, но без кардинального вмешательства в программу – никак.

Раз в железе прошивка работает(у автора, и не только),то для того чтобы, "лишь бы" и в протеусе она должным образом заработала, надо только изменить одну команду movlw b'00000001' на movlw b'00101000' или на movlw 0x28 ; Установки 4 битн. интерфейс 2 строки 5х7 точек.
Вот фрагмент исходника:
......
movlw b'00000010' ;Инициализация ЖКИ
call LEDcom
movlw b'00101000' ;здесь было у автора - movlw b'00000001'
call LEDcom
call Pausem
movlw b'00001100'
call LEDcom
.......
Это вроде бы по проще будет, чем добавлять всю правильную инициализацию по даташиту....видать она и вправду не нужна, (даже если и есть свободное место для команд).
Следовательно, теперь получается, что раз уж и в железе и в протеусе(уже) заработало.... то "тот пресловутый тринадцатый человек, у которого дисплей из «темного китайского подвала»" - "в дураках остатся" уже не должен. Хотя вряд ли бы он и смог раньше остатся в дураках если всё таки в железе у многих (у 11) работает
В железе не проверялось, но думаю что по логике тоже должно работать, ведь изменилась просто одна из посылаемых команд в заведомо рабочей прошивке, которая и заставила отображать вторую строку, в "строгом" и "даташитном" LCDALPHA.DLL из протеуса.
А вобщем FAQ - отличный,и очень полезный! Спасибо!