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.

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

Так вроде ж есть специально для этого MCI ?
Чтобы ногами не дрыгать.
В режиме Card Bus - до 100 Мбит/с, плюс аппаратная реализация нижнего уровня.
Тем более что, по слухам, режим SPI уже и не все современные карты поддерживают

Ещё АЦП можно на внешнюю шину LPC2478 посадить, если есть возможность. Более быстрого способа прокачки данных не найдётся.

Наверно Вы меня не так поняли. Сначала оцифровка сигнала и запись массива полученных значений в SDRAM. А потом уже запись массива на карту. Там как раз MCI. Но это все уже на уровне RTOS. Я туда не лезу совсем. Все уже написано до меня. Скорость тактирования по шине MCI для SD карт в даташите на контроллер максимум 25МГц. С данным контроллером я просто не успею записывать на карту даже на максимальной скорости. Поэтому сначала в ОЗУ, а потом уже медленно и неторопливо на флеш.



Там "висят" 2 микросхемы SDRAM по 32МБ.

Это в режиме SPI, который уже устарел.
А в режиме, про который я писал - до 100.

А ногами махать - при всём горячем желании быстрее не получится.
Скорость SPI - это максимум, чего можно выжать.

Или я опять чего-то не понял?

Для какой цели нужно ногами махать?

Для SD карт есть режим 4 бита. Возможно 100Мб/с это 25х4=100. Не знаю. Но скорость тактирования в данном контроллере для SD карт написана 25МГц максимум.



Ногами дергать не надо. Это я измерял скорость опроса с порта и при каждом опросе "дергал ножку". Это для себя.

Да, именно так и есть.
Плюс, как жаловался однажды Paramedic, некоторые карты уже в упор не понимают SPI

[CENSORED]
Работает медленно про тому что Вы не читали докумкетацию на MCU, в частности настройки тактовой частоты ядра и переферии, а также режимов выборки и буффрезирования Flash паяти.

Максимальная производительность достигается на саксимальных тактовых частотах всех узлов при исполнении кода из SRAM.

А пока Вы не сможете создать проект под ваш MCU с нуля, включая компоновку секций при линковки, startup-код, инициализацию прериферии,
и не разберетесь с ассемблером и особенностиями кодогенерации компилятора, можете о скорсоти исполнения кода забыть.
[CENSORED]

Рекомендую почитать правила на предмет культуры общения.
Модератор.