Почему с PowerPac код работает быстрее, чем просто на Cи? Опции

[kolobochishe]

int main(void)
{

unsigned int temp, MyAdr, MyPins, ii;
unsigned int MyArray[5];

ii = 0;
FIO4DIR3_bit.P4_0 = 1; // Вывод на выход

while(1)
{
MyArray[ii] = FIO1PIN;
FIO4PIN3_bit.P4_0= ~FIO4PIN3_bit.P4_0; //Дергаем ножкой
}

}

Почему с PowerPac скорость выше в 2 раза? Вроде просто Си программа все же ближе к ассемблеру, чем ОС плюс задача?

И сразу еще один вопрос. Частота "подергивания ножкой" с PowerPac 1,2Мгц, а просто Си - 0,5Мгц. Неужели быстрее нельзя? Что за операции такие производит контроллер, когда читает порт и записывает в ОЗУ? Это же 50 тактов минимум. И как в ИАРе вообще можно посмотреть время выполнения?

Забыл уточнить. OLIMEX-LPC2478

[kolobochishe]

ок. даже если так. Хотя взял просто пример LCD Demo и заменил main. Почему такие большие задержки? Почему такой длинный цикл? Если кому не лень, проверьте у себя в PowerPac. Тот же код. Просто опрос регистра состояния порта и запись значения в массив, и с последущим "подергиванием ножки". У кого сколько времени займет. Пример простой, может кому любопытно.
Занимаюсь программированием совсем недавно. Не ожидал, что с процессором 72МГц будет проблема с опросом порта с частотой 2МГц с последующим сохранением в SDRAM (там на плате 2 микросхемы по 32МБ). Не на асме же писать в наш то век тем более хочется многозадачности

[scifi]

Не ожидал, что с процессором 72МГц будет проблема с опросом порта с частотой 2МГц с последующим сохранением в SDRAM (там на плате 2 микросхемы по 32МБ). Не на асме же писать в наш то век

В большинстве МК обращение к GPIO занимает несколько тактов процессора. Причём сколько именно - как правило нигде не написано. И ассемблером это не исправить.
Для более быстрого ввода-вывода используют иные периферийные устройства, а не GPIO.

[kolobochishe]

Для более быстрого ввода-вывода используют иные периферийные устройства, а не GPIO.

это какие, например?

Рискну предположить, что PowerPack в процессе старта настраивает PLL, а ваша программа работает напрямую от кварца или внутреннего RC.

Использую функцию InitClock() определенную в sys.h. Устанавливает в 72МГц тактовую частоту ядра.
При отладке SYS_GetFsclk(); возвращает 72 000 000. Т.е. работает на 72МГц

PCLKSEL1_bit.PCLK_GPIO = 1; - частота работы порта вывода также 72МГц (делитель 1). До этого было 00 - что означало 72МГц/4

И все равно результат не дотягивает совсем до ожидаемого. Что еще можно сделать?

Добавил цикл задержки. Инкремент до 70 в цикле for. Результат оказался гораздо больше. Хотя должно быть 1-2мкс. Все же не проходит ощущение, что работает контроллер совсем не на 72МГц.

[MrYuran]

Добавил цикл задержки. Инкремент до 70 в цикле for. Результат оказался гораздо больше. Хотя должно быть 1-2мкс. Все же не проходит ощущение, что работает контроллер совсем не на 72МГц.

На самом деле есть ещё задержки чтения флеши (если программа работает не из RAM)
Плюс, каждый переход сбрасывает конвейер, что тоже сильно влияет (команды выполняются не за 1 такт).
Ну а что происходит в действительности - очень просто посмотреть в листинге, и к гадалке ходить не надо.

[kolobochishe]

На самом деле есть ещё задержки чтения флеши (если программа работает не из RAM)

Вы оказались ближе всех к истине. У ARM7 наиболее узкое место в скорости работы программы - чтение из флеш. В контроллере есть возможность включить модуль ускорения работы памяти. Это модуль управляется регистрами MAMCR и MAMTIM.

Пока не нашел какие значения использует для этих регистров PowerPac RTOS от IAR, но задав в программе нужные значения MAMCR=2; MAMTIM=3; получил ускорение работы цикла опроса и записи в массив аж до 2МГц (все равно плоховато, но лучше еще не получалось ). С операционкой было 1,2МГц. Естественно, в компиляторе тоже включил оптимизацию по скорости. Для отладки это плохо (переменные куда-то теряются и при отладке их значения нельзя посмотреть), но зато шустро.