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

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

PowerPack правильно настроил проц на максимальную производительность, а вы что то забыли у себя в Си.

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

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

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




Использую функцию 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МГц.

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

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

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

PowerPac настроил регистры MAMCR=1 и MAMTIM=5. Поэтому и медленнее. После этих манипуляций с регистрами поместил функцию в RAM с помощью директивы компилятору (или уж не знаю как назвать) __ramfunc. Результат не изменился.

Т.е. фактически частота опроса GPIO ограничена примерно 3-4МГц. Если у кого были лучшие результаты для данного типа контроллеров, расскажите как сделали.

Я, конечно, [пока] не спец по АРМовой периферии, но вот это

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

Ну а дальше - анролл циклов для оптимизации конвейера

анролл? это какая то оптимизация работы циклов?



Просто инвертирую то что есть. Я не знал, что чтение с GPIO занимает много времени, поэтому предпочел инвертировать прочитанное значение, а не создавать отдельную переменную.

Если создать переменную и её инвертировать, а потом записывать в порт, то в таком простеньком примере переменная окажется в регистре и чтения GPIO и даже рамы не будет. Скорость работы будет выше. Но не факт что всегда. Для установки и сброса битов есть отдельные регистры GPIO, для инверсии такого нет.

анролл... как-то так

Понял. Пример упрощенный, мягко говоря. Элементов должно быть 20*10^6. Т.е. примерно 20 МБ. Тупая забивка массива за 5 секунд на максимальной скорости (2MSPS). Как я понял пример выше - анролл получится великоват

а выход инверсионный я для оценки скорости записи и опроса GPIO использовал. Не знаю как еще в реальном времени это проверить. В конце цикла подавал сигнал об окончании в виде перехода из 1 в 0 и наоборот

Это как бы очевидно. А примеры намеренно делаются упрощёнными - на то они и примеры. И разворачивать цикл целиком никому в здравом уме не захочется. Так что не следует засорять тему.
Кстати, если озвучите марку чипа и суть задачи, то кто-нибудь, возможно, посоветует, какими средствами кроме GPIO эту задачу можно решить.

Отладочная плата OLIMEX LPC-2478STK.

Задача - оцифровка сигнала с помощью АЦП AD7622 в течение 5-10 секунд с последующей записью массива на SD-флеш. Скорость работы АЦП - 2MSPS. Разрядность 16 бит. Способы связи с АЦП - SPI, параллельная передача 16 бит, параллельная передача 8 бит за 2 такта (с помощью вывода BYTESWAP).

SPI работает медленно. SCLK до 9МГц. А надо 32 минимум. Есть SSP совместимый с SPI, но там тоже максимум 30МГц. И работать с прерываниями попробовал. Под RTOS работают очень медленно. Поэтому решил последовательными интерфейсами не пользоваться, а использовать опрос GPIO.

В общем-то все.