[dpatrakov 0]

Прям беда эти 250нс! :smile3009:

И что за задача такая, интересно, требующая прерывания в 1МГц??

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

 

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

 

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

 

И каким образом кстати произведены все эти замеры с точностью до десятков нс? Вы умудрились воткнуть щуп осциллографа прямо в AHB? :blink:

Поделитесь вашим бесценным опытом! B)

 

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

 

[DogPawlowa 0]

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

Периферия медленная, мост вставляет циклы ожидания. Все должно быть описано в AMBA.

Сам сейчас шлюз клепаю - ну просто живой пример, хотя совершенно в другой области.

 

>> меряю все цифровым осциллографом, ножкой для этого и дергаю

Вы не имеете возможности оценить задержки моста, поэтому стоит почитать документацию

http://infocenter.arm.com/help/index.jsp?t...ch04s01s04.html

 

[dpatrakov 0]

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

Периферия медленная, мост вставляет циклы ожидания. Все должно быть описано в AMBA.

Сам сейчас шлюз клепаю - ну просто живой пример, хотя совершенно в другой области.

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

APB peripherals are connected to the CPU via two APB busses using separate slave

ports from the multilayer AHB matrix. This allows for better performance by reducing

collisions between the CPU and the DMA controller. The APB bus bridges are configured

to buffer writes so that the CPU or DMA controller can write to APB devices without

always waiting for APB write completion.

 

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

Изменено 28 января, 2017 пользователем dpatrakov

[jcxz 185]

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

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

[DogPawlowa 0]

without always waiting

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

"всегда без ожидания", "без ожидания всегда"

 

А если чтение-модификация-запись, то шине и периферии оклематься надо.

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

[dpatrakov 0]

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

"всегда без ожидания", "без ожидания всегда"

 

А если чтение-модификация-запись, то шине и периферии оклематься надо.

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

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

 

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

Изменено 28 января, 2017 пользователем dpatrakov

[jcxz 185]

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

На этом МК я получал частоты прерывания от таймера (с полезной работой внутри в десяток команд) до 500-600 КГц.

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

 

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

[dpatrakov 0]

На этом МК я получал частоты прерывания от таймера (с полезной работой внутри в десяток команд) до 500-600 КГц.

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

 

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

 

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

 

На этом МК я получал частоты прерывания от таймера (с полезной работой внутри в десяток команд) до 500-600 КГц.

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

Изменено 28 января, 2017 пользователем dpatrakov

[jcxz 185]

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

Опять про нс....

Похоже Вы не поняли - я уже выше написал в чём у Вас проблема.

Никто не меряет сигналы в десятки нс, измерителем с разрешением в десяток МГц. На какой частоте Вы думаете у Вас GPIO работает? B)

Измерять время выполнения команд надо таймером, а не GPIO.

Ну а если так хочется GPIO, то измерять только группу команд от 1000 и больше чтобы получить полезный результат.

[dpatrakov 0]

Опять про нс....

Похоже Вы не поняли - я уже выше написал в чём у Вас проблема.

Никто не меряет сигналы в десятки нс, измерителем с разрешением в десяток МГц. На какой частоте Вы думаете у Вас GPIO работает? B)

Измерять время выполнения команд надо таймером, а не GPIO.

Ну а если так хочется GPIO, то измерять только группу команд от 1000 и больше чтобы получить полезный результат.

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

 

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

 

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

 

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

О этот пост я пропустил.

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

 

вот ты jcxz дофига умный

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

;;;1257       while (1)
000128  e011              B        |L1.334|
                  |L1.298|
;;;1258       {
;;;1259           f=1-f;
00012a  f1c40401          RSB      r4,r4,#1
;;;1260           if (f) LPC_GPIO0->FIOCLR = 1;
00012e  b11c              CBZ      r4,|L1.312|
000130  2001              MOVS     r0,#1
000132  4919              LDR      r1,|L1.408|
000134  61c8              STR      r0,[r1,#0x1c]
000136  e002              B        |L1.318|
                  |L1.312|
;;;1261           else LPC_GPIO0->FIOSET = 1;
000138  2001              MOVS     r0,#1
00013a  4917              LDR      r1,|L1.408|
00013c  6188              STR      r0,[r1,#0x18]
                  |L1.318|
;;;1262           LPC_TIM0->MR0 += 1000;
00013e  f04f2040          MOV      r0,#0x40004000
000142  6980              LDR      r0,[r0,#0x18]
000144  f500707a          ADD      r0,r0,#0x3e8
000148  f04f2140          MOV      r1,#0x40004000
00014c  6188              STR      r0,[r1,#0x18]
                  |L1.334|
00014e  e7ec              B        |L1.298|
;;;1263       }

[DogPawlowa 0]

мальчик ты чего раздухарился так?

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

 

[dpatrakov 0]

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

[jcxz 185]

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

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

В игнор.

[KRS 0]

И как это оптимизировать? в цикле я проверяю за сколько времени выполняется код

в ассемблере это 5 команд

 

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

 

 

000130  f500707a          ADD      r0,r0,#0x3e8     -- 1 цикл
000138  6188              STR      r0,[r1,#0x18]       -- 2 цикла

 

 

[dpatrakov 0]

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

 

 

000130  f500707a          ADD      r0,r0,#0x3e8     -- 1 цикл
000138  6188              STR      r0,[r1,#0x18]       -- 2 цикла

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

 

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

Изменено 1 февраля, 2017 пользователем dpatrakov