Контроллер ADuC7024.
Делал сначала софт в IAR 4.41. Мне нужна была дубовая функция задержки с параметром в миллисекундах. Чтобы "настроить" её, я запустил программу в симуляторе, через профайлер посмотрел сколько выполняется функция задержки и исходя из этого скорректировал вычисление нужного счётчика в функции.
Но в реальности мне показалось, что задержки выполняются дольше рассчитанного времени. На глаз показалось, что на треть. Получилось, что симулятор IAR врёт в более быструю сторону.

Потом решил код частично отладить в Keil mdk 3.10, т.к. там удобнее (чем в IAR) в симуляторе смотреть такты и время выполнения отдельных строчек кода. Начал как раз с функции задержки, т.к. она простая. И тут выяснилось, что та же функция выполняется (по симулятору) вдвое дольше. Количество тактов и время выполнения в симуляторе соответствуют друг другу (проверил на всякий). Решил посмотреть на реальном выполнении. В результате задержка, которая в симуляторе была 20с (по тактам и счётчику времени), реально выполнялась где-то за 14.3с. Получается, что симулятор насчитывает больше тактов, чем проходит в реальности. Подобрал расчёт счётчика в функции задержки по реальному выполнению. Теперь задержка в 10с в симуляторе проходит за 14.3с. Получилось, что пришлось уменьшить значение счётчика примерно на столько, на сколько мне казалось медленнее работает задержка в реальном выполнении в IAR.

Короче, в итоге, реальная задержка выполняется одинаково, что после Keil, что после IAR.
А вот симуляторы врут, причём в разные стороны и довольно прилично.

В чём тут трабл? Или изначально ориентироваться на временные отсчёты в симуляторах не стоило?

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

"По-уму" точные задержки обычно формируются на основе аппаратного таймера.

Да мне не задержки точные нужны, это не проблема.
Мне "инструмент" точный нужен, т.е. чтобы симулятор считал такты правильно, а не от балды. Чтобы то что в симуляторе происходит, совпадало бы с действительностью. Иначе нах нужен такой симулятор?

Тогда наверное стоит почитать что-нибудь про саму архитектуру ядра ARM и про конкретный МК с этим ядром.

Блин, такие советы я и сам могу давать кому угодно по любому поводу. Но воздерживаюсь.
Какое отношение имеют мои знания или незнания архитектуры к некорректной работе симулятора? Не я же писал этот симулятор.
Или вы даёте совет разработчикам симулятора? Тогда вроде не по адресу.

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

Кароче это фуфло я узнал ещё давно. Как мне показалось,параметры: частоты проца,ARM или THUMB функции выполняются, всё это весьма посредственно,либо вообще не учитывается. Про SPI и SSP я вообще не говорю,симулятор про них и не знает. Посмотреть следование импульсов нельзя. Делать надо через программный SPI.Нормально работают таймеры,ШИМ и прерывания. В общем лучше иметь платку и осцильник.

Сделать такой симулятор, который будет со 100% точностью отрабатывать периферию, системную шину, и достаточно сложный процессор не так и просто, да и вам такой не нужен. Отрабатывать он будет от силы 10K-100Kcycles/s на очень навороченной машине и стоить немеряно денег.
Проще и дешевле воспользоваться аппаратными средствами поддержки разработок.

Ну, я ж говорю не про работу симулятора в реальном времени. Пусть медленно работает, но правильно.
Уж этому АРМу столько времени, что можно было бы за это время что-то приличное сделать. Тем более, что эти продукты (Keil и IAR) стоят немеряно денег!
Если бы у меня так работало то что я делаю, меня бы уже давно с работы выперли...

Такое сопоставление сообщений весьма улыбнуло

Небольшая выдержка о достаточно навороченном(скажем средне навороченном) симуляторе с поддержкой ARM7T:"Pricing for Miss Univers time-based licenses (TBLs) starts at $25,000 per year."
Посмотрите на продукты типа CVE, решения от Coware, и у ARM, наверняка, есть решение по верификации железо-софт. Только вот прайсы на них соответствующие классу(сложности) решаемых задач.


Симулятор не симулирует?
То, что идет в Keil, по моему скромному мнению, всего-навсего ISA(instruction set accurate) - уровень достаточный для отладки БОЛЬШИНСТВА программ.

Вам rezident уже намекал, что время исполнения инструкции у ARM в отличие от AVR, PIC и т.д. зависит не только от тактовой частоты, а и от реализации различных ускорителей чтения из флеш, делителей шин, области памяти (RAM/ROM/EXT RAM/EXT ROM/периферия) и кучи связанных с этим настроек, которые у каждого процессора свои. В ARM9 и выше еще прибавьте кеш-память и всякие навороты вроде предсказателя переходов. Учесть все эти зависимости при симуляции - малореально, по сложности сопоставимо с созданием самого кристалла. А еще производители пекут новые кристаллы чем дальше тем быстрее. Так что вместо огрызаний лучше последуйте упомянутому совету. Симулятор честно показывает количество циклов ядра согласно спецификации ARM на ядро (кстати, растактовки команд у ARM7TDMI и ARM7TDMI-S отличаются), и не его вина, что циклы ядра и такты генератора у процессоров на основе ARM - это совсем не одно и то же.

Уж насколько AVR простой как трехлинейная винтовка, а и то в AVRStudio не вся периферия симулируется. К чему бы это?

Хочу оценить время выполнения участка программы (от одной точки останова до другой)... Как это сделать в IAR EW ARM ?

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

Этот способ не принадлежит среде разработки и требует дополнительного оборудования - осциллографа. Это как крайний вариант который можно сделать всегда, но не всегда это удобно.
В моём вопросе речь про штатные средства среды IAR для вычисления процессорных тактов. Например, в CodeComposer для TMS320 такой счетчик есть и учитывает он все произошедшие прерывания. Видел также такой счечик в IAR AVR... А вот для ARM не могу найти

Потому, что у ARM имеется конвейер и учет тактов весьма трудная задача.

у TI С28x тоже имеется конвеер, но TI решила задачу весьма красиво. Видимо нужна соответствующая аппаратная реализация функции в JTAG.

А Вам обязательно "штатные средства среды IAR" использовать? Возьмите любой free-running таймер и наслаждайтесь. Например, для IAR 5.xx для LPC17xx можно сделать так:



Измерение времени выполнения функции выглядеть будет так:


Ну, можно еще подкорректировать на время исполнения самого кода hal_profiler_counter().
Тактовая частота таймера профайлера выбирается по желанию - взависимости от требуемой точности и диапазона измеряемых интервалов.
BTW, на большинстве распространенных ARM-процессоров типа LPC/SAM время исполнения кода с точностью до такта измерять часто бессмысленно - скорость исполнения определяется многими факторами - выравнивание кода во флеш, загрузкой шин операциями DMA, прерываниями.

Такой подход к реализации функций задержки имеет множество недостатков: зависимость величины задержки от уровня оптимизации, версии компилятора, настроек ускорителей памяти (если они есть), неточная симуляция. Чтобы не закладывать себе мину на будущее, лучше немного напрячься и сделать задержку с использованием аппаратного таймера.