roboforum.ru

А почему бы не сделать чтобы после выполнения программы на скажем PORTA.1 выдавался высокий уровень и отсимулировать это в VBlab и по шкале времени посмотреть когда появится высокий уровень на ножке?

Master писал(а):А почему бы не сделать чтобы после выполнения программы на скажем PORTA.1 выдавался высокий уровень и отсимулировать это в VBlab и по шкале времени посмотреть когда появится высокий уровень на ножке?

Это и предложено тут выше и в задаче 3 курса  - измерение временных интервалов.

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

matracc писал(а):если алгоритм сложный все таки проще всего держать в голове
количество тактов на каждую ветку/процедуру, а не симулировать

Ну у вас и ГОЛОВА ! Не голова а дом советов.  Я такое врядли запомню.

Хех ребята, софт конечно хорошо, эмуляторы тоже, но ничто не заменит реальных измерений осциллографом =)
Вот например у меня есть несколько моментов которые работают в протеусе и не работаю в реале и наоборот.

Виталий писал(а):ничто не заменит реальных измерений осциллографом =)

Конечною Но осцилы разные бывают - я уже выше написал.

Виталий писал(а):у меня есть несколько моментов которые работают в протеусе и не работаю в реале и наоборот.

И в студии не работают ? и в VMLAB ?

А "наоборот" зачем мерить если в железе не работает ВААААЩЕ ?!

спасибо за голову, очень польщен)))
держать в голове отчасти означает и записывать в комментариях к коду))
Я все же считаю, и навряд ли меня кто переубедит, что рассчитывать время выполнения надо на стадии проектирования, а не написать, а потом в лабораторных условиях мерить то, что написали. Все таки, если алгоритм сложный и некоторые ветки требуют специальных условий, а вы об этом не задумались, когда писали программу - навряд ли вы все эти условия переберете с щупом в руках. Не даром всякие методологии программирования настаивают на том, чтобы тесты программ писались до разработки их алгоритма.
Кстати, кто-нибудь знает профайлер к avr?? Я порылся в своей памяти и не нашел.

Пришла в голову забавная идея. Забиваем в файл все процесорные команды и сколько тактов выполняются. Потом пишется простенький скрипт (например на perl) который натравливается на оттранслированый Си код (до asm) - и он сам в автомате считает, что-где и сколько выполняется. На днях попробую написать!

Ждемс !

а для разных МК время на команду одинаковое??

А что с циклами делать, и ветвлениями?

циклы считать...
а ветвления...хз

но можно выводить время каждой процедуры, цикла или ветвления отдельно
и уже самому на бумажке суммировать в зависимости от режима работы

всё лучше чем на глаз прикидывать

steel_monkey писал(а):А что с циклами делать, и ветвлениями?

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

теперь вопрос: стоит ли это трудов? хотя попробовать стоит

Можно и осциллографом там где точность не нужна )))
А вот мой вариант измерения скорости циклов:
Компилируем в кодевижене. При компиляции образуется файл ассемблера asm.
И открывает его в проекте АВРстудии. Запускаем дебагер и смотрим )))
В асм файле потеряться нельзя там все отмечано и помечано ))) даже самого асемблера можно не знать. А в дебагере авр студии тав вообще все и регистры и частота кварца и скорость выполнения одной каманды в микросекундах , циклы то же можно измерять , в общем все что угодно для души )))) Сам недавно этим занимался перекидывал асм файл из кодевижена в дебагер авр студии ))))