Микроконтроллеры

Ну типа так Про MIPS - надо чтобы было не MIPS, а тактовая частота процессора. А то у некоторых на 1 мегагерц тактовой 8 мипсов, а у других - 1/12. А ведь в системе главное это частота клока, выше которой не прыгнешь, а не то, как ее потом ядро использует и сколько тактов на одну инструкцию (гы, или инструкций на один такт) требует. Посему в пункте про МК я бы все таки перешел от условно-попугайной единицы "MIPS" к конкретному значению тактовой частоты ядра процессора. Для камней с PLL - значение частоты на выходе PLL, для камней без PLL - частота кварцевого генератора (или внешнего такта). И чтобы не возникало недоразумений - никаких делений этих частот, даже если одна команда выполняется хоть 4, хоть 12 тактов. Указывается именно реальная частота. Далее. Число тактов. Не системной шины!!! Например в моем случае системная шина живет на отдельном генераторе на совершенно отвлеченной от ядра частоте (ядро на 150 мгц, а сист. шина в режиме SDRAM на стольнике). Поэтому указывать надо число тактов ядра процессора. То есть той частоты, что указана была при описании самого МК. Опять же - не инструкций, не машинных циклов, а периодов указанной в описании МК частоты. Реалтайм. Кроме пин+осцилл еще два варианта измерений. Профайлером через jtag при помощи встроенной системы профайлинга. Если есть. Запуском аппаратного таймера в начале теста и считыванием значения в конце. МК без таймера нынче редкость большая. Эти два метода точнее осциллографа. И надо внести ясность в code size и data size: Code size: Это размер ВСЕГО кода с учетом либов и остального хлама? Или размер кода, сгенеренного из функций, входящих в тест? То же самое и с данными. Считать или не считать приехавшее из ран-тайма? Мое мнение - не считать. Например для разных процессоров надо произвести разную инициализацию, порой довольно толстую. И к собственно размеру кода/данных теста это не относится. Тут возможны разночтения. Я лично указывал размер ф-ции "main" моего теста (благо остальные inline).