STM32F0 Время реакции и выполнения прерывания Опции

[Влад Р.]

Добрый день!

Имеется МК STM32F0. Работает на частоте 48 МГц. Фоновая программа представляет собой пустой бесконечный цикл. По фронту сигнала на выводе МК настроено внешнее прерывание. В обработчике прерывания только операции с портами ввода/вывода и логические операции. Все задействованные выводы сконфигурированы на работу на максимальной скорости.
Согласно статье "A Beginner’s Guide on Interrupt Latency - and Interrupt Latency of the ARM® Cortex®-M processors" время реакции на прерывание для ядра Cortex-M0 составляет 16 машинных циклов. Первой командой после входа в обработчик я считываю один из портов в/в, затем на одном из выводов другого порта устанавливаю высокий уровень. Время между фронтом внешнего сигнала, вызвавшим внешнее прерывание, и установкой высокого уровня на выводе, указанном выше, составляет 800 нс. Почему такое большое время и как можно его сократить?
В той же статье говорится о джиттере времени реакции, но неясно от каких факторов он может зависеть?
Время выполнения обработчика прерывания составило 1,5 мкс, что тоже неожиданно много. Также буду рад советам как уменьшить.

Используется Keil 5.17. Пробовал различные уровни оптимизации компилируемого кода, оптимизацию по времени/объему. Не давало положительных результатов. Размещение обработчика прерывания в ОЗУ позволило сократить время его выполнения на 0,2 мкс, но не повлияло на время реакции на прерывание.

[Влад Р.]

Абсолютно тупиковый путь, особенное, если планируется расширять проект (код)!
Я бы просто заново спроектировал проект.
Скорее всего нужно переходить на ртос, тогда число всяких обработчиков прерываний резко сократиться - ведь не на все события нужно реагировать с точность до мкс, опрашивать кнопки тоже нет смысла чаще, чем раз в 50мс. Т.е. для таких вещей хватает одного системного таймера оси (у меня такт в основном 1мс).
Короче, самописный асм на ARMе в своем коде - это крайне опасная и нежелательная вещь, ее нужно всячески избегать и исключать еще на этапе проектирования кода.

По-моему RTOS сейчас только замедлит код, а основное требование сейчас - это максимальное быстродействие и минимальное число "лишних" команд. Сейчас задействовано всего одно внешнее прерывание. Почему под ARMы нужно избегать самописного ассемблерного кода, вроде как ASM-код - это эталон быстродействия для любой платформы?

Это уже сделали? Где листинг?

Только в качестве обучающего занятия. Примеры можно найти в книжках Дж. Ю, на одну из которых я ссылался.

А для более широких задач почему не подойдет?
Заменил на fastы. stdint вместо них подставляет int. Вот листинг:

CODE

68: {
0x08000240 B430 PUSH {r4-r5}
69: uint_fast16_t db = GPIOC->IDR & 0x1FFF;
70: uint_fast8_t data/* = db & 0xFF*/;
71:
0x08000242 481D LDR r0,[pc,#116] ; @0x080002B8
0x08000244 8A00 LDRH r0,[r0,#0x10]
72: GPIOB->BSRR = GPIO_BSRR_BS_12;
73:
0x08000246 2201 MOVS r2,#0x01
0x08000248 04C1 LSLS r1,r0,#19
0x0800024A 0CC9 LSRS r1,r1,#19
0x0800024C 481B LDR r0,[pc,#108] ; @0x080002BC
0x0800024E 0312 LSLS r2,r2,#12
0x08000250 6182 STR r2,[r0,#0x18]
74: data = db & 0xFF;
75:
0x08000252 B2CB UXTB r3,r1
76: if (!(db & (0x01 << 12))) {
0x08000254 04CA LSLS r2,r1,#19
68: {
69: uint_fast16_t db = GPIOC->IDR & 0x1FFF;
70: uint_fast8_t data/* = db & 0xFF*/;
71:
72: GPIOB->BSRR = GPIO_BSRR_BS_12;
73:
74: data = db & 0xFF;
75:
76: if (!(db & (0x01 << 12))) {
0x08000256 D429 BMI 0x080002AC
77: switch (db & (0x03 << 9)) {
78: case 0x0000:
0x08000258 2203 MOVS r2,#0x03
0x0800025A 0252 LSLS r2,r2,#9
0x0800025C 4011 ANDS r1,r1,r2
79: GPIOA->ODR = (GPIOA->ODR & ~0xFF) | data;
0x0800025E 4A18 LDR r2,[pc,#96] ; @0x080002C0
0x08000260 D008 BEQ 0x08000274
0x08000262 39FF SUBS r1,r1,#0xFF
0x08000264 39FF SUBS r1,r1,#0xFF
0x08000266 1E89 SUBS r1,r1,#2
0x08000268 D00A BEQ 0x08000280
0x0800026A 39FF SUBS r1,r1,#0xFF
0x0800026C 39FF SUBS r1,r1,#0xFF
0x0800026E 2902 CMP r1,#0x02
0x08000270 D11C BNE 0x080002AC
0x08000272 E00C B 0x0800028E
0x08000274 8A90 LDRH r0,[r2,#0x14]
0x08000276 0A00 LSRS r0,r0,#8
0x08000278 0200 LSLS r0,r0,#8
0x0800027A 4318 ORRS r0,r0,r3
0x0800027C 8290 STRH r0,[r2,#0x14]
80: break;
81: case 0x0200:
0x0800027E E015 B 0x080002AC
82: GPIOB->ODR = (GPIOB->ODR & ~(0x03 << 5)) | (data & (0x03 << 5));
0x08000280 8A82 LDRH r2,[r0,#0x14]
0x08000282 2160 MOVS r1,#0x60
0x08000284 438A BICS r2,r2,r1
0x08000286 400B ANDS r3,r3,r1
0x08000288 431A ORRS r2,r2,r3
0x0800028A 8282 STRH r2,[r0,#0x14]
83: break;
84: case 0x0400:
0x0800028C E00E B 0x080002AC
85: GPIOA->ODR = (GPIOA->ODR & ~(0x0F << 8)) | ((uint16_t)HINIBBLE(data) << 8);
0x0800028E 8A91 LDRH r1,[r2,#0x14]
0x08000290 240F MOVS r4,#0x0F
0x08000292 0224 LSLS r4,r4,#8
0x08000294 031D LSLS r5,r3,#12
0x08000296 0C2D LSRS r5,r5,#16
0x08000298 43A1 BICS r1,r1,r4
0x0800029A 022D LSLS r5,r5,#8
0x0800029C 4329 ORRS r1,r1,r5
0x0800029E 8291 STRH r1,[r2,#0x14]
86: GPIOB->ODR = (GPIOB->ODR & ~(0x0F << 8)) | ((uint16_t)LONIBBLE(data) << 8);
87: break;
88: case 0x0600:
89: break;
90: }
91: }
0x080002A0 8A81 LDRH r1,[r0,#0x14]
0x080002A2 071A LSLS r2,r3,#28
0x080002A4 43A1 BICS r1,r1,r4
0x080002A6 0D12 LSRS r2,r2,#20
0x080002A8 4311 ORRS r1,r1,r2
0x080002AA 8281 STRH r1,[r0,#0x14]
92: EXTI->PR = EXTI_PR_PR8;
0x080002AC 20FF MOVS r0,#0xFF
0x080002AE 4905 LDR r1,[pc,#20] ; @0x080002C4
0x080002B0 3001 ADDS r0,r0,#0x01
0x080002B2 6148 STR r0,[r1,#0x14]
93: }
0x080002B4 BC30 POP {r4-r5}
0x080002B6 4770 BX lr
0x080002B8 0800 DCW 0x0800
0x080002BA 4800 DCW 0x4800
0x080002BC 0400 DCW 0x0400
0x080002BE 4800 DCW 0x4800
0x080002C0 0000 DCW 0x0000
0x080002C2 4800 DCW 0x4800
0x080002C4 0400 DCW 0x0400
0x080002C6 4001 DCW 0x4001

Vincent_Mahout_AssemblyLanguageProgramming_ARM_CortexM3.pdf

Похоже, то что нужно. Спасибо!

[Forger]

По-моему RTOS сейчас только замедлит код, а основное требование сейчас - это максимальное быстродействие и минимальное число "лишних" команд.

Лишних команд не бывает, а бывают деньги, заплаченные закачиком на разработку впустую
Заказчику как правило совершенно до лампочки как внутри реализована задача, главное цена - и время (время = деньги), разумеется, изделие должно соотв. ТЗ.
Я лично никогда не буду экономить на цене МК в изделии, которое стоит как минимум в сотню раз дороже, чем этот МК, и
поэтмоу заложу такой МК, которого хватит с запасом! В крайнем случае его можно заменить и перенести код на него со старого МК.
Кстати, если код был написан через одно место (ASM-вставки, отсутствует система именования, не испоьзуются SVN и т.п.), то это создаст огромную проблему.
Более того, крайне затруднительно использование такого кривого разового кода в других проектах, а это тоже адская потеря времени и денег.

Сейчас задействовано всего одно внешнее прерывание.

Сколько всего прерываний в коде?

Почему под ARMы нужно избегать самописного ассемблерного кода,

См. выше.
Не только под ARM, а везде подобный колхоз = зло. Пройдет полгода и попробуйте в нем разобраться или не дай бог кто-то другой будет за вами это делать...
Проклянут до 10го колена

вроде как ASM-код - это эталон быстродействия для любой платформы?

Это - величайший миф всех времен и народов!

Мы щас отклоняемся от темы в сторону классических и бессмысленных холиваров типа ASM vs C и т.п. Это бессмыслено.

Еще раз: для каждой коммерческой задачи существут бюджет!
Вполне возможно, что для примитивных, но очень крупносерийных изделиях есть смысл использовать ASM (в крайне редких случаях), но я не участвовал в таких проектах.