250 нс не беда, но когда выполняются 3 такие инструкции подряд, плюс время входа и выхода из прерывания это 1 мкс, это дофига.

1 МГц мне не нужен, я писал ранее, нужно 200 кГц, но это тоже не мало.

самая медленная операция в прерывании это посчитать теорему пифагора для 6мерного пространства тоесть корень из суммы 6квадратов



Вы что издеваетесь? в первом посте все написано, меряю все цифровым осциллографом, ножкой для этого и дергаю

Не могу похвастаться хорошим знанием ARM, но рассчитывать, что даже при коэффициенте деления = 1 мост между шинами работает без задержек, выглядит чрезмерно оптимистичным.
Периферия медленная, мост вставляет циклы ожидания. Все должно быть описано в AMBA.
Сам сейчас шлюз клепаю - ну просто живой пример, хотя совершенно в другой области.

>> меряю все цифровым осциллографом, ножкой для этого и дергаю
Вы не имеете возможности оценить задержки моста, поэтому стоит почитать документацию
http://infocenter.arm.com/help/index.jsp?t...ch04s01s04.html

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


ну пусть он их вставит, но не 25 тактов же

Сообщение отредактировал dpatrakov - Jan 28 2017, 21:22

Да это Вы похоже издеваетесь, мозг тут всем выносите, "десятки проектов" и т.п. И при этом меряете команды дёргая ножкой и ещё про какие-то нс пишете!

Загадочный английский язык, варианты перевода какие?
"всегда без ожидания", "без ожидания всегда"

А если чтение-модификация-запись, то шине и периферии оклематься надо.
Ну пишут же напрямую - скорость по APB снижена для экономии потребления.

дак снижена до 48МГц, но не до 4х же

пробовал и просто запись и просто чтение дает 250нс, чтение модификация запись соответственно 500

Сообщение отредактировал dpatrakov - Jan 28 2017, 21:36

На этом МК я получал частоты прерывания от таймера (с полезной работой внутри в десяток команд) до 500-600 КГц.
И получал работающий ISR на частоте 200КГц с выполнением нескольких десятков команд внутри ISR с записью всех регистров в память и копированием до 2-х десятков слов ОЗУ-ОЗУ.

Странно, что с вашим опытом в десятки проектов у Вас не получается гораздо более простая задача...

200 килогерц прерывание работает, и выполняет свою функцию, но 3 операции по обслуживанию прерывания, занимаю столько времени как весь код самого обработчика


ну естественно 1мкс вход выход и непонятные задержки, и десяток команд это 100-150 нс, еще и основному потоку остается время правда мало, вставь в такое прерывание вычисление корня и оно у тебя повиснет, а с десятком команд у меня до 800кГц получалось

Сообщение отредактировал dpatrakov - Jan 28 2017, 21:44

Опять про нс....
Похоже Вы не поняли - я уже выше написал в чём у Вас проблема.
Никто не меряет сигналы в десятки нс, измерителем с разрешением в десяток МГц. На какой частоте Вы думаете у Вас GPIO работает?
Измерять время выполнения команд надо таймером, а не GPIO.
Ну а если так хочется GPIO, то измерять только группу команд от 1000 и больше чтобы получить полезный результат.

Ну у меня с этого и началось. При возникновении прерывания, TC==MR0, тоесть после проверки флага и его сброса что занимает 12 тактов плюс 12 тактов на сохранение регистров при вызове обработчика TC должен опередить MR0 на 24 такта, а по факту опережает на 75

согласен что при входе в обработчик переписывается префетч, но в простом цикле тот же результат

Да еще изменение частоты тактирования таймера не влияет на результат

[indent][/indent]
О этот пост я пропустил.
мальчик ты чего раздухарился так? ты вообще понимаешь как найти время выполнения конкретной инструкции? похоже что нет

вот ты jcxz дофига умный
расчитай время выполнения следующего кода

Опять г...о по трубам.

Вот думал тут, на шине где висит таймер, есть другие устройства и время от времени занимают его что соответственно при обращении должно вызвать ожидание, но в этом случае период выполнения был бы плавающим, а он стоит как вкопанный, щас попозже на работу съезжу сфотографирую, и как вариант отключу всю периферию кроме на шине

Да, Вы правы - очередное хамло....
В игнор.

в данном случае должно быть две

плюс одна команда включить пин в начале кода, одна команда выключить в конце, одна перейти в начало петли

Проблема частично решена, частично благодаря рассуждениям jcxz правда диалог с ним не получился и зашел в тупик, прерывание запустил с частотой почти 1,5 МГц, но это сожрало 50% ресурса контроллера только на вход и выход но зато получил четкое время накладных расходов прерывания (вход, выход, обслуживание и походу перезеагрузка prefetch в 600-700 ns), также ранее не задумывавшись о передаче данных внутри контроллера так вопрос максимально быстрого отклика отсутствовал, выяснил следующее, буферизации на шинах APB0 и 1 похоже нету, хотя в мануале написано что есть, но может неправильно понял нерусский язык, хотя читаю вроде неплохо, в общем решил отказаться от использования более одного регистра сравнения, и запускать таймер только в режиме сравнения и сброса TC, ну по крайне мере в текущем проекте, хотя отказ от 3 регистров сравнения повлечет изменение алгоритма сильное. Второе выяснилось то что регистр GPIO->FIOPIN имеет буфер записи, с задержкой 2 такта, то есть если записать в него и следующей командой прочитать (на ассемблере) получим предыдущее состояние, добавление 2 nop между записью и чтением решает проблему, хотя такая ситуация редка и в большинстве случаев ее можно избежать. И еще нашел ускорение работы с массивом структур за счет выравнивания руками а не средствами компилятора код занимавший 15 операций (ASM), снизился до 11 за счет выравнивания к 4 не только размеров полей структуры , но и их количества

Сообщение отредактировал dpatrakov - Feb 1 2017, 15:21