Подскажите пожулуйста как настроить GPIO частоту равную мастер клоку 133Мгц, ARM только начал изучать.
Проинициализировал Процессор клок на 400Мгц Мастер клок на 133, далее в безконечном цикле дергаю ногой в своем примере из SRAM без убутов и бутстрапов получаю максимум 2,8 Мгц период т.е. включение выключение. Такой же код вписал в убут собрал запустил получил 11,111111 Мгц период т.е. 11,1111Мгц х 2 х 6 тактов = 133 Мгц.
Интересует есть ли какие либо еще регистры где прописывается частота тактирования GPIO?
В даташите на него ничего не нашел.


Как я понял дело в MMU и кеше
Включил MMU кеш как описано здесь http://electronix.ru/forum/index.php?showt...&hl=SAM9G45
получил 7.8431 МГц но этого тоже мало должно быть как в убуте 11.11111МГц
подскажите пример MMU и кеша на полную катушку так сказать

Если уж Вы начали изучать ARM9, то сразу отучайтесь от ногодрыганья и изучайте периферию ARM.

Еще в некоторых процах можно выбрать режим скорости работы ноги, в одних быстро - медленно, а в некоторых стмах (правда уже кортексах) аж 4 уровня скорости есть от 2.5 МГц, до максимума, и если нога настроена на медленную работу, то хоть клок проца на нее выводи быстрее не поедет...

посмотрите в около FAST GPIO и или GPIO SPEED. и так далее...

Но в целом да, АРМ - это использование периферии, GPIO - это не для него, вся моща уйдет в ножки... Частота GPIO обычно половина от системной, а на изменение состояния ноги обычно 2-4 команды, вот и считайте... неоткуда 100 МГц на 400 клоке взяться...

Я знаю что нужно изучать переферию в данный момент я пытаюсь сделать инициализацию для этого взял безконечный цикл с дерганьем ноги и еще туда добавляю 10 раз i++ смотрю на осциллографе на сколько у меня сдвигается фронт тем самым определяю сколько нс заняли 10 команд i++

Вобщем переферия это да но вопрос сейчас в другом как достигнуть такой же инициализации как и в u-boot'е а может и еще лучше

какие то интересные исследования можно же всегда поглядеть дизасемблерный код, да и узнать сколько инструкций на что идет. Ведь есть еще разные настройки оптимизации, разворачивание циклов, предсказание ветвлений... в чем смысл этих исследований?

На изменение состояния ноги судя по картинкам из даташита уходит 6 тактов Мастер клока MCK котрый настроен на 133МГц соответственно 133МГц / 6 = 22,2222...
чтобы получился период, а он состоит из включения и выключения, делим 22,22222222 на 2 получается 11,111111МГц который я и вижу когда запускаю этот цикл в u-boot'е
FAST GPIO и GPIO SPEED в даташите опять же не нашел

Вообще дергание ногой я использую для того чтобы замечать смещение фронта (увеличение скважности) импульса на осциллографе при добвлении в тот же код нескольких команд i++



Не могли бы вы поподробнее о настройках оптимизации?

Попробовал я вставить код MMU кеш из убута резальтат такой же 7.84Мгц вместо ожидаемых 11.111...

Сообщение отредактировал Sergey1212 - Apr 24 2013, 11:46

Максимальную скорость выполнения кода можно получить в Internal SRAM
процессора см. TCM Interface это без MMU.
Максимальная частота ногодрыганья из таблицы 46-17 атмеловского мануала на этот процессор.

OPTIMIZATION = -O3
Решили проблему))
вышел на 12.12 МГц видимо меньше 6 тактов занимает переключение состояния)
Вопрос можно ли еще больше поднять "скорость выполнения" на этом контроллере?


Похоже так и получается что TCM без MMU т.е. включаю icache_enable а при нем MMU не запускается
Максимальная частота ногодрыгания в той таблице это немного не то что нужно

Сообщение отредактировал Sergey1212 - Apr 24 2013, 12:11

Попробуйте использовать модуль PWM
могу конечно ошибаться но судя по даташиту MCK/2 можно получить.

Меня интересует не аппаратная а программная реализация ногодрыгания с точки зрения оптимизации выполняемой программы т.е. как раз кеши и ITCM DTCM MMU и незнаю что там еще может быть чтобы поднять скорость выполнения кода который будет управлять в данном контексте ногами
просто мне так удобнее смотря на осциллограф я чижу чтоо код стал выполняться быстрее или медленее вот и все
если бы я хотел на ноге получить нужную мне частоту я бы использовал PCK0 или PCK1

Кто нибудь может в кратце разъяснить про ITCM DTCM MMU с чем их вообще едят
функция icache_enable взятая из u-boot'a работает и в SRAM и в DDRAM а вот dcache_enable а вместе с ним и MMU что в драме что в сраме приводят к зависанию

вообщем я думаю самый правильный путь это посмотреть дизасемблер вашего ногодрыганья после оптимизации, посмотреть что там за команды вызываются, и подумать есть ли среди них какие лишние. Если лишних нет - то это предел скорости.

Вам в общих чертах интересно вообще про кэши или именно про кэши этого проца?

Пока что интересуют именно к этому процу
Как я понимаю тот кусок кода кде уменя цикл и две функции включения и отключения ноги не должен поменяться если я буду компилить с icache'ем?
Если я включаю в коде icache то в дизасемблере смогу видеть что участок кода с циклом включеним выключеним ноги поменялся?
И еще вопрос как мне это дизасемблерром посмотреть?
JTAGA нет использую плату на которой он не выведен.
Компилятор arm-none-eabi-

Сообщение отредактировал Sergey1212 - Apr 24 2013, 13:54

ну я на иарах и кейлах обычно сижу, кеил сам показывает дизасемблер не скрывая ничего, в ИАРе он виден если загрузил по жетагу или в режиме симулятора. В вашей среде нет симулятора? обычно там всегда к обычному коду еще он же в ассемблере добавлен, потому что иначе упаришся в бинарнике искать какой код за какие строки отвечает...

В общей теории кешей кусок кода отвечающий за дерганья ногами меняться не должен, изменениям подвергнется лишь скорость выбора инструкций из памяти. Хотя в код могут быть добавлены некоторые инструкции которые управляют кешированием нужных участков кода. Современные компиляторы иногда делают такие хитрые вещи при оптимизации кода, что никогда не знаешь что ты там увидишь в итоге... Но учитывая малость участка кода, думаю он будет неизменен...

Вот кусок с дизассемблерра получил из eclipsa запустил приложение в qemu-system-arm
с выключенным icache:
i++;
003001d4: ldr r1, [sp, #4]
003001d8: add r1, r1, #1
003001dc: str r1, [sp, #4]
517 pio->PIO_CODR = mask;
003001e0: str r3, [r2, #-3531] ; 0xdcb
512 pio->PIO_SODR = mask;
003001e4: str r3, [r2, #-3535] ; 0xdcf

с включенным icache:
i++;
00300224: ldr r1, [sp, #4]
00300228: add r1, r1, #1
0030022c: str r1, [sp, #4]
517 pio->PIO_CODR = mask;
00300230: str r3, [r2, #-3531] ; 0xdcb
512 pio->PIO_SODR = mask;
00300234: str r3, [r2, #-3535] ; 0xdcf

этот же кусов в С:

i++;
003001d4: ldr r1, [sp, #4]
003001d8: add r1, r1, #1
003001dc: str r1, [sp, #4]
003001e0: str r3, [r2, #-3531] ; 0xdcb
512 pio->PIO_SODR = mask;
003001e4: str r3, [r2, #-3535] ; 0xdcf

Так что код в дизасемблере не меняется а вот в реале частота на ноге меняется

Поскажите как тут понять сколько тактов у меня занимает i++ который занимает три строки в асме?
003001d4: ldr r1, [sp, #4]
003001d8: add r1, r1, #1
003001dc: str r1, [sp, #4]


Тогда что там смотреть дизассемблером?

Сообщение отредактировал Sergey1212 - Apr 24 2013, 14:36

Смысл использовать MMU если у вас код и данные вертится в SRAM не вижу, там и так все работает на частоте ядра.
MMU как раз и для того чтобы кешировать данные из относительно медленной DDR памяти. Насчет кеша кода неотвечу.
В таблице 46-17 сказано что если у вас VDDPIO имеют питание 3,3В можно получить большую частоту на ноге. При этом указывается значение емкости на ножке для которой вы эту частоту вытянете.
Сколько на вашей плате VDDPIO порта в который вы пишете?


И пропишите для вашей переменой i квалификатор register будет быстрее.