Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: STM32F0 Время реакции и выполнения прерывания
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2
Влад Р.
Добрый день!

Имеется МК 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 мкс, но не повлияло на время реакции на прерывание.
scifi
Обращение к портам ввода-вывода тоже время должно занимать, правда, неясно, какова задержка. Кроме того, если используете всякие кубы, халы и прочие библиотеки в обработчике прерывания, будут ещё тормоза от избыточного кода.
Кстати, в Кейле вроде бы есть симулятор, который считает такты (более-менее точно, я надеюсь). Посимулируйте и посмотрите, на что такты расходуются.
jcxz
Цитата(Влад Р. @ Jun 21 2016, 18:40) *
Время между фронтом внешнего сигнала, вызвавшим внешнее прерывание, и установкой высокого уровня на выводе, указанном выше, составляет 800 нс. Почему такое большое время и как можно его сократить?
В той же статье говорится о джиттере времени реакции, но неясно от каких факторов он может зависеть?
Время выполнения обработчика прерывания составило 1,5 мкс, что тоже неожиданно много. Также буду рад советам как уменьшить.

Покажите ассемблерный листинг ISR.
Время реакции состоит из:
ожидание завершения очередной команды + сохранение контекста и вход в ISR (видимо эти 16 тактов) + предвыборка кода начала обработчика (уменьшить можно разместив ISR в ОЗУ, посмотрев на матрицу шин; или включив кеш если есть) + PUSH при входе в ISR (листинг?) + задержки доступа к шине, на которой сидит GPIO + ...
SasaVitebsk
В статье указано, что 16 машинных циклов пройдёт от прерывания, до выполнения 1 команды прерывания. То есть до входа в прерывание. Сама п/п прерывания, должна сначала сохранить текущий контекст в стеке (текущие регистры) ну и возможно что-то проинициализировать (смотря как вы программу написали), после чего она приступит к выполнению программы пользователя. Учитывая, что 16 тактов это уже 333 нс, то 800 в целом неплохо. Не совсем понятно откуда у вас существенный выигрыш при размещении прерывания в ОЗУ. По моему у вас должно бы 0 циклов ожидания, при такой тактовой.
Ну и 1.5 мкс на выполнение тоже неплохо... )) всё относительно. Еще недавно это было совершенно недостижимо. )))
А в целом если у вас критическое исполнение, причём масштабы на микросекунды, то необходимо использовать аппаратные ресурсы.
Джитер образуется, за счёт того, что некоторые комманды выполняются > одного такта, а также за счёт работы конвеера, на сколько я понимаю.
dimka76
Цитата(SasaVitebsk @ Jun 21 2016, 16:17) *
Джитер образуется, за счёт того, что некоторые комманды выполняются > одного такта, а также за счёт работы конвеера, на сколько я понимаю.


На джитер еще будет момент прихода внешнего события, поскольку он не синхронизирован с тактовой МК.
jcxz
Цитата(SasaVitebsk @ Jun 21 2016, 19:17) *
существенный выигрыш при размещении прерывания в ОЗУ. По моему у вас должно бы 0 циклов ожидания, при такой тактовой.

Обычно флеш в МК типа Cortex-M работает на частотах около 20МГц, так что 0-wait-states уже не получается.
Плюс ещё - какая ширина шины предвыборки в этом МК? Можно кстати выровнять начало ISR на границу 128бит - может помочь предвыборке.
AlexRayne
Цитата(SasaVitebsk @ Jun 21 2016, 16:17) *
В статье указано, что 16 машинных циклов пройдёт от прерывания, до выполнения 1 команды прерывания. То есть до входа в прерывание. Сама п/п прерывания, должна сначала сохранить текущий контекст в стеке (текущие регистры) ну и возможно что-то проинициализировать (смотря как вы программу написали), после чего она приступит к выполнению программы пользователя. Учитывая, что 16 тактов это уже 333 нс, то 800 в целом неплохо. Не совсем понятно откуда у вас существенный выигрыш при размещении прерывания в ОЗУ. По моему у вас должно бы 0 циклов ожидания, при такой тактовой.
Ну и 1.5 мкс на выполнение тоже неплохо... )) всё относительно. Еще недавно это было совершенно недостижимо. )))
А в целом если у вас критическое исполнение, причём масштабы на микросекунды, то необходимо использовать аппаратные ресурсы.
Джитер образуется, за счёт того, что некоторые комманды выполняются > одного такта, а также за счёт работы конвеера, на сколько я понимаю.

+1
время реакции по моему разумению означает время перехода на вектор прерывания. если вы установку порта сделаете прямо на месте вектора - то скорее всего получите ожидаемые такты +-лапоть.
jcxz
Цитата(AlexRayne @ Jun 21 2016, 19:51) *
время реакции по моему разумению означает время перехода на вектор прерывания. если вы установку порта сделаете прямо на месте вектора - то скорее всего получите ожидаемые такты +-лапоть.

Объясните как это сделать, когда в Cortex-M по вектору прерывания находится не код, а адрес точки входа в ISR???

ЗЫ: Кстати вот не учли - время выборки вектора из таблицы векторов прерываний. Которая у автора наверное тоже во флешь находится. Можно её тож в ОЗУ перетащить.
AlexRayne
Цитата(jcxz @ Jun 21 2016, 16:57) *
Объясните как это сделать, когда в Cortex-M по вектору прерывания находится не код, а адрес точки входа в ISR???

ЗЫ: Кстати вот не учли - время выборки вектора из таблицы векторов прерываний. Которая у автора наверное тоже во флешь находится. Можно её тож в ОЗУ перетащить.

чтобы это сделать надо пилить стартап, и ассемблерный код наверняка. этот вопрос к специалистам по арм, я в нем с векторами не заморачивался. если вам настолько критична реакция на прерывание, то действительно стоит подумать над аппаратной реализацией того что вам надо. посмотрите на вашу периферию - может таймеры, или мультиплексор внутреней шины могут сделать то что вам надо сами?
jcxz
Цитата(AlexRayne @ Jun 21 2016, 21:01) *
чтобы это сделать надо пилить стартап, и ассемблерный код наверняка. этот вопрос к специалистам по арм, я в нем с векторами не заморачивался.

Хоть совсем его распилите - код там расположить не сможете. sm.gif Курите доку на ядро.

Цитата(AlexRayne @ Jun 21 2016, 21:01) *
если вам настолько критична реакция на прерывание, то действительно стоит подумать над аппаратной реализацией того что вам надо. посмотрите на вашу периферию - может таймеры, или мультиплексор внутреней шины могут сделать то что вам надо сами?

Мне не критична, у меня всё нормально. Вопрос задавал не я.

2ТС: Вынесите таблицу векторов прерываний в ОЗУ, напишите ISR на асм и вынесите его в ОЗУ, выровняйте его начало. По периферии ничего не подскажу.
RadiatoR
Цитата(jcxz @ Jun 21 2016, 16:57) *
ЗЫ: Кстати вот не учли - время выборки вектора из таблицы векторов прерываний. Которая у автора наверное тоже во флешь находится. М


А разве там не сквозная адресация идет на прерывание и cpu не обрабатывает взятие адреса функции прерывания? Разве по событию не рубится конвейер и не загружается этот адрес в pc?

А по теме - если у ТС такое требовательное к времени приложение (которое посилам мк), то может этот кусочек на асме написать? Уж тем более если присутствуют всякие HAL...
Влад Р.
Цитата(scifi @ Jun 21 2016, 16:05) *
Кроме того, если используете всякие кубы, халы и прочие библиотеки в обработчике прерывания, будут ещё тормоза от избыточного кода.

Библиотеки, кроме ASM-файла инициализации и CMSIS не использую. Код самописный.

Цитата(jcxz @ Jun 21 2016, 16:14) *
Покажите ассемблерный листинг ISR.
Время реакции состоит из:
ожидание завершения очередной команды + сохранение контекста и вход в ISR (видимо эти 16 тактов) + предвыборка кода начала обработчика (уменьшить можно разместив ISR в ОЗУ, посмотрев на матрицу шин; или включив кеш если есть) + PUSH при входе в ISR (листинг?)

Что подразумевается под сохранением контекста? Я думал, это и есть стэкирование РОН (PUSH) и, что оно включено в те самые 16 тактов.
На сколько я знаю, кэша в этих МК нет. Может ли влиять Prefetch Buffer (сейчас включен)?
Вот листинг на Си:
CODE
void EXTI4_15_IRQHandler(void)
{
uint16_t db = GPIOC->IDR & 0x1FFF;
uint8_t data = db;

if (!(db & (0x01 << 12))) {
switch (db & (0x03 << 9)) {
case 0x0000:
GPIOA->ODR = (GPIOA->ODR & ~0xFF) | data;
break;
case 0x0200:
GPIOB->ODR = (GPIOB->ODR & ~(0x03 << 5)) | (data & (0x03 << 5));
break;
case 0x0400:
GPIOA->ODR = (GPIOA->ODR & ~(0x0F << 8)) | ((uint16_t)HINIBBLE(data) << 8);
GPIOB->ODR = (GPIOB->ODR & ~(0x0F << 8)) | ((uint16_t)LONIBBLE(data) << 8);
break;
case 0x0600:
if (db & (0x01 << 4))
GPIOA->MODER &= ~(GPIO_MODER_MODER0 | GPIO_MODER_MODER1 | GPIO_MODER_MODER2 | GPIO_MODER_MODER3 |
GPIO_MODER_MODER4 | GPIO_MODER_MODER5 | GPIO_MODER_MODER6 | GPIO_MODER_MODER7);
else
GPIOA->MODER |= GPIO_MODER_MODER0_0 | GPIO_MODER_MODER1_0 | GPIO_MODER_MODER2_0 | GPIO_MODER_MODER3_0 |
GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0 | GPIO_MODER_MODER6_0 | GPIO_MODER_MODER7_0;
if (db & (0x01 << 3))
GPIOA->MODER &= ~(GPIO_MODER_MODER8 | GPIO_MODER_MODER9 | GPIO_MODER_MODER10 | GPIO_MODER_MODER11);
else
GPIOA->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 | GPIO_MODER_MODER10_0 | GPIO_MODER_MODER11_0;
if (db & (0x01 << 1))
GPIOB->MODER &= ~(GPIO_MODER_MODER5 | GPIO_MODER_MODER6);
else
GPIOB->MODER |= GPIO_MODER_MODER5_0 | GPIO_MODER_MODER6_0;
if (db & 0x01)
GPIOB->MODER &= ~(GPIO_MODER_MODER8 | GPIO_MODER_MODER9 | GPIO_MODER_MODER10 | GPIO_MODER_MODER11);
else
GPIOB->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 | GPIO_MODER_MODER10_0 | GPIO_MODER_MODER11;
break;
}
}
EXTI->PR = EXTI_PR_PR8;
}


Вот дизассемблер:
CODE
61: {
0x08000240 B430 PUSH {r4-r5}
62: uint16_t db = GPIOC->IDR & 0x1FFF;
0x08000242 4831 LDR r0,[pc,#196] ; @0x08000308
0x08000244 8A00 LDRH r0,[r0,#0x10]
0x08000246 04C0 LSLS r0,r0,#19
0x08000248 0CC0 LSRS r0,r0,#19
63: uint8_t data = db;
64:
0x0800024A B2C1 UXTB r1,r0
65: if (!(db & (0x01 << 12))) {
0x0800024C 04C2 LSLS r2,r0,#19
61: {
62: uint16_t db = GPIOC->IDR & 0x1FFF;
63: uint8_t data = db;
64:
65: if (!(db & (0x01 << 12))) {
0x0800024E D455 BMI 0x080002FC
66: switch (db & (0x03 << 9)) {
67: case 0x0000:
0x08000250 2203 MOVS r2,#0x03
0x08000252 0252 LSLS r2,r2,#9
68: GPIOA->ODR = (GPIOA->ODR & ~0xFF) | data;
69: break;
70: case 0x0200:
0x08000254 4B2D LDR r3,[pc,#180] ; @0x0800030C
0x08000256 4002 ANDS r2,r2,r0
0x08000258 D00D BEQ 0x08000276
71: GPIOB->ODR = (GPIOB->ODR & ~(0x03 << 5)) | (data & (0x03 << 5));
0x0800025A 3AFF SUBS r2,r2,#0xFF
0x0800025C 4C2C LDR r4,[pc,#176] ; @0x08000310
0x0800025E 3AFF SUBS r2,r2,#0xFF
0x08000260 1E92 SUBS r2,r2,#2
0x08000262 D00E BEQ 0x08000282
0x08000264 3AFF SUBS r2,r2,#0xFF
0x08000266 3AFF SUBS r2,r2,#0xFF
0x08000268 1E92 SUBS r2,r2,#2
0x0800026A D011 BEQ 0x08000290
0x0800026C 3AFF SUBS r2,r2,#0xFF
0x0800026E 3AFF SUBS r2,r2,#0xFF
0x08000270 2A02 CMP r2,#0x02
0x08000272 D143 BNE 0x080002FC
0x08000274 E01B B 0x080002AE
0x08000276 8A98 LDRH r0,[r3,#0x14]
0x08000278 0A00 LSRS r0,r0,#8
0x0800027A 0200 LSLS r0,r0,#8
0x0800027C 4308 ORRS r0,r0,r1
0x0800027E 8298 STRH r0,[r3,#0x14]
69: break;
70: case 0x0200:
71: GPIOB->ODR = (GPIOB->ODR & ~(0x03 << 5)) | (data & (0x03 << 5));
0x08000280 E03C B 0x080002FC
0x08000282 8AA0 LDRH r0,[r4,#0x14]
0x08000284 2260 MOVS r2,#0x60
0x08000286 4390 BICS r0,r0,r2
0x08000288 4011 ANDS r1,r1,r2
0x0800028A 4308 ORRS r0,r0,r1
0x0800028C 82A0 STRH r0,[r4,#0x14]
72: break;
73: case 0x0400:
0x0800028E E035 B 0x080002FC
74: GPIOA->ODR = (GPIOA->ODR & ~(0x0F << 8)) | ((uint16_t)HINIBBLE(data) << 8);
0x08000290 8A9A LDRH r2,[r3,#0x14]
0x08000292 200F MOVS r0,#0x0F
0x08000294 0200 LSLS r0,r0,#8
0x08000296 090D LSRS r5,r1,#4
0x08000298 4382 BICS r2,r2,r0
0x0800029A 022D LSLS r5,r5,#8
0x0800029C 432A ORRS r2,r2,r5
0x0800029E 829A STRH r2,[r3,#0x14]
75: GPIOB->ODR = (GPIOB->ODR & ~(0x0F << 8)) | ((uint16_t)LONIBBLE(data) << 8);
0x080002A0 8AA2 LDRH r2,[r4,#0x14]
0x080002A2 4382 BICS r2,r2,r0
0x080002A4 0708 LSLS r0,r1,#28
0x080002A6 0D00 LSRS r0,r0,#20
0x080002A8 4302 ORRS r2,r2,r0
0x080002AA 82A2 STRH r2,[r4,#0x14]
76: break;
77: case 0x0600:
0x080002AC E026 B 0x080002FC
78: if (db & (0x01 << 4))
79: GPIOA->MODER &= ~(GPIO_MODER_MODER0 | GPIO_MODER_MODER1 | GPIO_MODER_MODER2 | GPIO_MODER_MODER3 |
80: GPIO_MODER_MODER4 | GPIO_MODER_MODER5 | GPIO_MODER_MODER6 | GPIO_MODER_MODER7);
81: else
0x080002AE 06C1 LSLS r1,r0,#27
82: GPIOA->MODER |= GPIO_MODER_MODER0_0 | GPIO_MODER_MODER1_0 | GPIO_MODER_MODER2_0 | GPIO_MODER_MODER3_0 |
83: GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0 | GPIO_MODER_MODER6_0 | GPIO_MODER_MODER7_0;
0x080002B0 6819 LDR r1,[r3,#0x00]
0x080002B2 D502 BPL 0x080002BA
79: GPIOA->MODER &= ~(GPIO_MODER_MODER0 | GPIO_MODER_MODER1 | GPIO_MODER_MODER2 | GPIO_MODER_MODER3 |
80: GPIO_MODER_MODER4 | GPIO_MODER_MODER5 | GPIO_MODER_MODER6 | GPIO_MODER_MODER7);
81: else
82: GPIOA->MODER |= GPIO_MODER_MODER0_0 | GPIO_MODER_MODER1_0 | GPIO_MODER_MODER2_0 | GPIO_MODER_MODER3_0 |
83: GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0 | GPIO_MODER_MODER6_0 | GPIO_MODER_MODER7_0;
0x080002B4 0C09 LSRS r1,r1,#16
0x080002B6 0409 LSLS r1,r1,#16
0x080002B8 E001 B 0x080002BE
0x080002BA 4A16 LDR r2,[pc,#88] ; @0x08000314
0x080002BC 4311 ORRS r1,r1,r2
0x080002BE 6019 STR r1,[r3,#0x00]
84: if (db & (0x01 << 3))
0x080002C0 0702 LSLS r2,r0,#28
85: GPIOA->MODER &= ~(GPIO_MODER_MODER8 | GPIO_MODER_MODER9 | GPIO_MODER_MODER10 | GPIO_MODER_MODER11);
86: else
0x080002C2 4915 LDR r1,[pc,#84] ; @0x08000318
87: GPIOA->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 | GPIO_MODER_MODER10_0 | GPIO_MODER_MODER11_0;
0x080002C4 681A LDR r2,[r3,#0x00]
0x080002C6 D501 BPL 0x080002CC
0x080002C8 438A BICS r2,r2,r1
0x080002CA E002 B 0x080002D2
0x080002CC 2555 MOVS r5,#0x55
0x080002CE 042D LSLS r5,r5,#16
0x080002D0 432A ORRS r2,r2,r5
0x080002D2 601A STR r2,[r3,#0x00]
88: if (db & (0x01 << 1))
89: GPIOB->MODER &= ~(GPIO_MODER_MODER5 | GPIO_MODER_MODER6);
90: else
0x080002D4 0782 LSLS r2,r0,#30
91: GPIOB->MODER |= GPIO_MODER_MODER5_0 | GPIO_MODER_MODER6_0;
0x080002D6 6822 LDR r2,[r4,#0x00]
0x080002D8 D503 BPL 0x080002E2
89: GPIOB->MODER &= ~(GPIO_MODER_MODER5 | GPIO_MODER_MODER6);
90: else
91: GPIOB->MODER |= GPIO_MODER_MODER5_0 | GPIO_MODER_MODER6_0;
0x080002DA 230F MOVS r3,#0x0F
0x080002DC 029B LSLS r3,r3,#10
0x080002DE 439A BICS r2,r2,r3
0x080002E0 E002 B 0x080002E8
0x080002E2 2305 MOVS r3,#0x05
0x080002E4 029B LSLS r3,r3,#10
0x080002E6 431A ORRS r2,r2,r3
0x080002E8 6022 STR r2,[r4,#0x00]
92: if (db & 0x01)
93: GPIOB->MODER &= ~(GPIO_MODER_MODER8 | GPIO_MODER_MODER9 | GPIO_MODER_MODER10 | GPIO_MODER_MODER11);
94: else
0x080002EA 07C0 LSLS r0,r0,#31
95: GPIOB->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 | GPIO_MODER_MODER10_0 | GPIO_MODER_MODER11;
96: break;
97: }
98: }
0x080002EC 6820 LDR r0,[r4,#0x00]
0x080002EE D001 BEQ 0x080002F4
93: GPIOB->MODER &= ~(GPIO_MODER_MODER8 | GPIO_MODER_MODER9 | GPIO_MODER_MODER10 | GPIO_MODER_MODER11);
94: else
95: GPIOB->MODER |= GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0 | GPIO_MODER_MODER10_0 | GPIO_MODER_MODER11;
96: break;
97: }
98: }
0x080002F0 4388 BICS r0,r0,r1
0x080002F2 E002 B 0x080002FA
0x080002F4 21D5 MOVS r1,#0xD5
0x080002F6 0409 LSLS r1,r1,#16
0x080002F8 4308 ORRS r0,r0,r1
0x080002FA 6020 STR r0,[r4,#0x00]
99: EXTI->PR = EXTI_PR_PR8;
0x080002FC 20FF MOVS r0,#0xFF
0x080002FE 4907 LDR r1,[pc,#28] ; @0x0800031C
0x08000300 3001 ADDS r0,r0,#0x01
0x08000302 6148 STR r0,[r1,#0x14]
100: }
0x08000304 BC30 POP {r4-r5}
0x08000306 4770 BX lr
0x08000308 0800 DCW 0x0800
0x0800030A 4800 DCW 0x4800
0x0800030C 0000 DCW 0x0000
0x0800030E 4800 DCW 0x4800
0x08000310 0400 DCW 0x0400
0x08000312 4800 DCW 0x4800
0x08000314 5555 DCW 0x5555
0x08000316 0000 DCW 0x0000
0x08000318 0000 DCW 0x0000
0x0800031A 00FF DCW 0x00FF
0x0800031C 0400 DCW 0x0400
0x0800031E 4001 DCW 0x4001


Цитата(jcxz @ Jun 21 2016, 16:57) *
Которая у автора наверное тоже во флешь находится. Можно её тож в ОЗУ перетащить.

Подтверждаю, сейчас вектора размещаются дефолтно, т.е. во флэше.
jcxz
Цитата(Влад Р. @ Jun 22 2016, 01:39) *
Что подразумевается под сохранением контекста? Я думал, это и есть стэкирование РОН (PUSH) и, что оно включено в те самые 16 тактов.
На сколько я знаю, кэша в этих МК нет. Может ли влиять Prefetch Buffer (сейчас включен)?

Именно оно и подразумевается.
Буфер предвыборки должен выбрать из памяти начало ISR перед их выполнением.

Ну а чего-ж Вы хотите??? У Вас от входа в ISR до установки пина такая куча команд выполняется:
CODE
0x08000240 B430 PUSH {r4-r5}
62: uint16_t db = GPIOC->IDR & 0x1FFF;
0x08000242 4831 LDR r0,[pc,#196] ; @0x08000308
0x08000244 8A00 LDRH r0,[r0,#0x10]
0x08000246 04C0 LSLS r0,r0,#19
0x08000248 0CC0 LSRS r0,r0,#19
63: uint8_t data = db;
64:
0x0800024A B2C1 UXTB r1,r0
65: if (!(db & (0x01 << 12))) {
0x0800024C 04C2 LSLS r2,r0,#19
61: {
62: uint16_t db = GPIOC->IDR & 0x1FFF;
63: uint8_t data = db;
64:
65: if (!(db & (0x01 << 12))) {
0x0800024E D455 BMI 0x080002FC
66: switch (db & (0x03 << 9)) {
67: case 0x0000:
0x08000250 2203 MOVS r2,#0x03
0x08000252 0252 LSLS r2,r2,#9
68: GPIOA->ODR = (GPIOA->ODR & ~0xFF) | data;
69: break;
70: case 0x0200:
0x08000254 4B2D LDR r3,[pc,#180] ; @0x0800030C
0x08000256 4002 ANDS r2,r2,r0
0x08000258 D00D BEQ 0x08000276
71: GPIOB->ODR = (GPIOB->ODR & ~(0x03 << 5)) | (data & (0x03 << 5));
0x0800025A 3AFF SUBS r2,r2,#0xFF
0x0800025C 4C2C LDR r4,[pc,#176] ; @0x08000310
0x0800025E 3AFF SUBS r2,r2,#0xFF
0x08000260 1E92 SUBS r2,r2,#2
0x08000262 D00E BEQ 0x08000282
0x08000264 3AFF SUBS r2,r2,#0xFF
0x08000266 3AFF SUBS r2,r2,#0xFF
0x08000268 1E92 SUBS r2,r2,#2
0x0800026A D011 BEQ 0x08000290
0x0800026C 3AFF SUBS r2,r2,#0xFF
0x0800026E 3AFF SUBS r2,r2,#0xFF
0x08000270 2A02 CMP r2,#0x02
0x08000272 D143 BNE 0x080002FC
0x08000274 E01B B 0x080002AE
...
0x080002AE 06C1 LSLS r1,r0,#27
82: GPIOA->MODER |= GPIO_MODER_MODER0_0 | GPIO_MODER_MODER1_0 | GPIO_MODER_MODER2_0 | GPIO_MODER_MODER3_0 |
83: GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0 | GPIO_MODER_MODER6_0 | GPIO_MODER_MODER7_0;
0x080002B0 6819 LDR r1,[r3,#0x00]
0x080002B2 D502 BPL 0x080002BA
79: GPIOA->MODER &= ~(GPIO_MODER_MODER0 | GPIO_MODER_MODER1 | GPIO_MODER_MODER2 | GPIO_MODER_MODER3 |
80: GPIO_MODER_MODER4 | GPIO_MODER_MODER5 | GPIO_MODER_MODER6 | GPIO_MODER_MODER7);
81: else
82: GPIOA->MODER |= GPIO_MODER_MODER0_0 | GPIO_MODER_MODER1_0 | GPIO_MODER_MODER2_0 | GPIO_MODER_MODER3_0 |
83: GPIO_MODER_MODER4_0 | GPIO_MODER_MODER5_0 | GPIO_MODER_MODER6_0 | GPIO_MODER_MODER7_0;
0x080002B4 0C09 LSRS r1,r1,#16
0x080002B6 0409 LSLS r1,r1,#16
0x080002B8 E001 B 0x080002BE
0x080002BA 4A16 LDR r2,[pc,#88] ; @0x08000314
0x080002BC 4311 ORRS r1,r1,r2
0x080002BE 6019 STR r1,[r3,#0x00]


Хотя-бы под отладчиком прошлись бы по командам и посмотрели сколько команд.
Если нужно такое время реакции - пишите на асм. Ну или аппаратно.
ViKo
Измените переменные на 32-битовые. Везде, где можно.
SasaVitebsk
Цитата(jcxz @ Jun 21 2016, 16:44) *
Обычно флеш в МК типа Cortex-M работает на частотах около 20МГц, так что 0-wait-states уже не получается.
Плюс ещё - какая ширина шины предвыборки в этом МК? Можно кстати выровнять начало ISR на границу 128бит - может помочь предвыборке.

Да посмотрел, там 0 ws до 24МГц и 1ws выше. Ширина шины флэш 32 бита всего, правда есть prefetch bufer небольшой... В целом достаточно убого, по ускорению выборки.
Влад Р.
Цитата(jcxz @ Jun 22 2016, 08:16) *
Ну а чего-ж Вы хотите??? У Вас от входа в ISR до установки пина такая куча команд выполняется:


Прошу прощения. Установка пина выполнялась исключительно для того, чтобы понять сколько времени занимает вход в прерывание и первое считывание порта. В выложенном листинге ее нет. Было примерно так:
Код
void EXTI4_15_IRQHandler(void)
{
  uint16_t db = GPIOC->IDR & 0x1FFF;
  uint8_t data;
  
  GPIOB->BSRR = GPIO_BSRR_BS_12;
  
  data = db;
  ...
}
jcxz
Цитата(SasaVitebsk @ Jun 22 2016, 11:49) *
Да посмотрел, там 0 ws до 24МГц и 1ws выше. Ширина шины флэш 32 бита всего, правда есть prefetch bufer небольшой... В целом достаточно убого, по ускорению выборки.

Ну вот, а это означает, что хоть и установлена 48МГц, но код, состоящий из последовательности 4-байтовых команд, будет выполняться со скоростью 24MIPS. Так что перенос в ОЗУ должен помочь.
Если будет поток из одних 4-байтовых команд, то prefetch buffer никак не поможет. Хотя у ТС в данном случае команды в основном 2-байтные.

Цитата(Влад Р. @ Jun 22 2016, 12:13) *
Прошу прощения. Установка пина выполнялась исключительно для того, чтобы понять сколько времени занимает вход в прерывание и первое считывание порта. В выложенном листинге ее нет. Было примерно uint16_t db = GPIOC->IDR & 0x1FFF;
uint8_t data;
GPIOB->BSRR = GPIO_BSRR_BS_12;
data = db;

А теперь посмотрите листинг - сколько там команд, просуммируйте со временем стекинга и прочими временами. Как раз и получите, что имеете.
Как уже Вам советовали - не стоит использовать 8-и и 16-битные переменные где ни попадя на 32-битном CPU. Это приводит к лишним командам в коде.
ViKo
Цитата(jcxz @ Jun 22 2016, 09:28) *
Хотя у ТС в данном случае команды в основном 2-байтные.

Ага. Все! biggrin.gif И неспроста.
Влад Р.
Цитата(jcxz @ Jun 22 2016, 09:28) *
А теперь посмотрите листинг - сколько там команд, просуммируйте со временем стекинга и прочими временами. Как раз и получите, что имеете.
Как уже Вам советовали - не стоит использовать 8-и и 16-битные переменные где ни попадя на 32-битном CPU. Это приводит к лишним командам в коде.


Можно ли как-то отключить стекинг РОН или это делается аппаратно? К примеру, не использовать РОН в обработчике прерывания.
Не понятно, включено ли время стекинга (PUSH) во время Interrupt Latency (16 циклов)?
Переменные заменил на intы, обработчик положил в ОЗУ.
jcxz
Цитата(Влад Р. @ Jun 22 2016, 12:42) *
Можно ли как-то отключить стекинг РОН или это делается аппаратно?

нельзя.

Цитата(Влад Р. @ Jun 22 2016, 12:42) *
К примеру, не использовать РОН в обработчике прерывания.

Можно избавиться от PUSH, написав ISR на асме.
ViKo
Цитата(Влад Р. @ Jun 22 2016, 09:42) *
Не понятно, включено ли время стекинга (PUSH) во время Interrupt Latency (16 циклов)?

Включено. Иначе, что бы там делалось целых 16 тактов?
Читайте Джозефа Ю.
Цитата
When an exception is accepted on the Cortex-M0 processor, some of the registers in the
register banks (R0 to R3, R12, R14), the return address (PC), and the Program Status Register
(xPSR) are pushed to the current active stack memory automatically.

Если ограничить количество переменных, можно уложиться в те регистры, что сохраняются аппаратно.
Компилятор сам лишних регистров не сохраняет. Я так думаю.
Влад Р.
Цитата(ViKo @ Jun 22 2016, 09:55) *
Включено. Иначе, что бы там делалось целых 16 тактов?

Если ограничить количество переменных, можно уложиться в те регистры, что сохраняются аппаратно.
Компилятор сам лишних регистров не сохраняет. Я так думаю.


Это бы много объяснило. Часть регистров помещается в стек аппаратно и отключить это невозможно. Время за которое это происходит составляет минимальное время реакции на прерывание (Interrupt Latency - 16 cycles).
PUSH в начале обработчика помещает дополнительно еще парочку РОН и от этого можно уйти, написав обработчик на асме.

Цитата(ViKo @ Jun 22 2016, 09:39) *
Ага. Все! biggrin.gif И неспроста.

Поясните, пожалуйста.
HHIMERA
Цитата(Влад Р. @ Jun 22 2016, 10:16) *
Это бы

А в чём сыр-бор??? Чего добиться то хотите???
Obam
Цитата(Влад Р. @ Jun 22 2016, 11:16) *
PUSH в начале обработчика помещает дополнительно еще парочку РОН и от этого можно уйти, написав обработчик на асме.


Можно, если использовать только R0 - R3, R12, а в случае дополнительной нужды в регистрах (не забываем - RISC - все действия только с регистрами, кроме загрузки-выгрузки)
без PUSH/POP не обойтись.
И кстати, bitbanding по регистрам периферии может помочь уменьшить число команд.
jcxz
Цитата(Obam @ Jun 22 2016, 13:57) *
И кстати, bitbanding по регистрам периферии может помочь уменьшить число команд.

Или наоборот - увеличить wink.gif
scifi
Цитата(Obam @ Jun 22 2016, 10:57) *
И кстати, bitbanding по регистрам периферии может помочь уменьшить число команд.

Мысль, конечно, интересная, но у STM32F0 этой фичи нет.
Obam
Цитата(scifi @ Jun 22 2016, 12:07) *
Мысль, конечно, интересная, но у STM32F0 этой фичи нет.


Cortex-M0, тогда да, пардону просим. Всё время упускаю, что есть ARMv6

Цитата(jcxz @ Jun 22 2016, 12:04) *
Или наоборот - увеличить wink.gif


Личный опыт показывает, что число команд R-M-W уменьшается wink.gif
ViKo
Цитата(Влад Р. @ Jun 22 2016, 10:16) *
Поясните, пожалуйста.

Я так понимаю, ARM стремилась в Cortex-M0 использовать преимущественно 16-битовые команды, ради экономии памяти.

Цитата(Влад Р. @ Jun 22 2016, 10:16) *
PUSH в начале обработчика помещает дополнительно еще парочку РОН и от этого можно уйти, написав обработчик на асме.

Попробуйте сделать что-то совсем простое, инвертировать бит, например. И без asm ненужные регистры в стек запихиваться не будут.
scifi
Цитата(Obam @ Jun 22 2016, 11:13) *
Cortex-M0, тогда да, пардону просим. Всё время упускаю, что есть ARMv6

Вы будете смеяться, но Cortex-M0 и ARMv6 тут совершенно ни чём.
Bit-banding - это опция на процессорах M0, M3 и M4. Так уж получилось, что она чаще встречается у M3 и M4, чем у M0. См. тут.
jcxz
Цитата(Obam @ Jun 22 2016, 14:24) *
Личный опыт показывает, что число команд R-M-W уменьшается wink.gif

Если код типа:
u32 i = GPIOC->IDR & 0x1FFF;
*BITBAND_IO(&GPIOC->ODR, bitX) = 1;
то может увеличиться, так как народ часто использует команды RMW там где они реально не нужны (а периферия GPIO во многих МК как правило имеет регистры позволяющие установку/сброс отдельных битов просто командами записи, а не чтения-модификации-записи). А обращение к региону bitband требует дополнительной загрузки указателя на него.
К тому же например IAR почему-то плохо компилит код с обращением к битбанд-области - получается куча лишних команд даже при полной оптимизации. sad.gif((

Цитата(ViKo @ Jun 22 2016, 14:51) *
Я так понимаю, ARM стремилась в Cortex-M0 использовать преимущественно 16-битовые команды, ради экономии памяти.

Не правильно пояснили sm.gif
Потому, что в коде из листинга используются регистры R0-R7 и только простые режимы адресации (без автоинкрементов, длинных смещений и т.п.) и формы команд влияющие на флаги (MOVS, LSLS, ...) и т.п.
Поэтому все команды короткие.
Сергей Борщ
Может крамолу скажу, но если основной цикл пустой, то зачем использовать прерывание? В основном цикле все и делать, а события ждать по WFI/WFE. Сэкономится время на переход по вектору и на сохранение контекста, а также подготовительные операции компилятор может вставить перед WFI/WFE...
ViKo
Цитата(jcxz @ Jun 22 2016, 12:03) *
Не правильно пояснили sm.gif
Потому, что в коде из листинга используются регистры R0-R7 и только простые режимы адресации (без автоинкрементов, длинных смещений и т.п.) и формы команд влияющие на флаги (MOVS, LSLS, ...) и т.п.
Поэтому все команды короткие.

Открываем книгу The Definitive Guide to ARM® Cortex®-M0 and Cortex-M0+ Processors, Second Edition
на стр 10, смотрим рис. 1.4 с командами, и восхищаемся, что 32-битовых команд у Cortex-M0/M0+/M1 всего 6. rolleyes.gif Причем, без разницы, старшие или младшие регистры используются.

(номер поправил)

Цитата
If we look at the instruction set in a bit more details (Figure 1.4), we can see that the
Cortex-M0, Cortex-M0ю, and Cortex-M1 processors only support a small instruction set
(56 instructions). Most of these instructions are 16 bit, thus provide a very good code
density - which means it need a smaller program memory require for the same task
compared to many architecture.
Влад Р.
Цитата(Сергей Борщ @ Jun 22 2016, 12:21) *
Может крамолу скажу, но если основной цикл пустой, то зачем использовать прерывание? В основном цикле все и делать, а события ждать по WFI/WFE. Сэкономится время на переход по вектору и на сохранение контекста, а также подготовительные операции компилятор может вставить перед WFI/WFE...



Сейчас необходимо добиться минимального времени срабатывания. В дальнейшем программа будет разрастаться и будут добавлены другие прерывания, а в основном цикле будут добавлены другие действия.
scifi
Цитата(ViKo @ Jun 22 2016, 12:41) *
Открываем книгу The Definitive Guide to ARM® Cortex®-M0 and Cortex-M0+ Processors, Second Edition

На каком языке написано? На олбанском китайско-английском? Ржака biggrin.gif
ViKo
Цитата(scifi @ Jun 22 2016, 12:51) *
На каком языке написано? На олбанском китайско-английском? Ржака biggrin.gif

Википедия лучше? Нажмите для просмотра прикрепленного файла
Obam
Цитата(scifi @ Jun 22 2016, 12:51) *
Вы будете смеяться, но Cortex-M0 и ARMv6 тут совершенно ни чём.
Bit-banding - это опция на процессорах M0, M3 и M4. Так уж получилось, что она чаще встречается у M3 и M4, чем у M0. См. тут.


Смеяться я не стану, но в ARM DDI 0484B (TechRefManual на v6) на Bit-banding даже намёка нет.
scifi
Цитата(Obam @ Jun 22 2016, 15:12) *
Смеяться я не стану, но в ARM DDI 0484B (TechRefManual на v6) на Bit-banding даже намёка нет.

Ну, значит мне показалось: AHB bit-band wrapper for Cortex-M0 processor.
Obam
Цитата(scifi @ Jun 22 2016, 16:54) *
Ну, значит мне показалось: AHB bit-band wrapper for Cortex-M0 processor.


Смайлики не надо забывать: вы использовали Technical Reference Manual (TRM) for the Cortex-M System Design Kit, я для Cortex-M0+.
scifi
Цитата(Obam @ Jun 22 2016, 17:37) *
Смайлики не надо забывать: вы использовали Technical Reference Manual (TRM) for the Cortex-M System Design Kit, я для Cortex-M0+.

Слив защщитан biggrin.gif
GetSmart
Цитата(scifi @ Jun 22 2016, 12:51) *
Bit-banding - это опция на процессорах M0, M3 и M4. Так уж получилось, что она чаще встречается у M3 и M4, чем у M0.

Можете огласить список СМ0 с этой опцией?
scifi
Цитата(GetSmart @ Jun 22 2016, 21:03) *
Можете огласить список СМ0 с этой опцией?

Увы, не могу. Лицензиаты арма передо мной не отчитываются crying.gif
GetSmart
Те же лицензиаты издавали рекламные обзоры, из которых следовало, что Bit-banding в СМ0 нет и не ожидается (без намёков). Точнее, подчеркивали что эта фича характерна для СМ3 и выше. И, как уже сказано, её не было в описании ARMv6-М от самого АРМа. В Architecture Reference Manual на какое-то ядро обазано быть данное описание.

Цитата(scifi @ Jun 22 2016, 22:08) *
Увы, не могу. Лицензиаты арма передо мной не отчитываются crying.gif

Когда сможете, тогда будет корректно и "чаще встречаются" и слив.
scifi
Цитата(GetSmart @ Jun 22 2016, 21:19) *
Когда сможете, тогда будет корректно и "чаще встречаются" и слив.

Ой, да ради бога: How to Use Bit-band and BME on the KE04 and KE06 Subfamilies.
GetSmart
Цитата(scifi @ Jun 22 2016, 23:28) *
Ой, да ради бога:

Пока всё ещё утверждение ложно/некорректно.
Там речь о Фрискейловом СМ0+. BME реализовано на уровне ядра. Но первое же преджложение "Т.к. bit-banding есть опция СМ0+" на каких документах от АРМ основано - не ясно.

Разработчик описал в документах ядра ARMv6-M что там есть обязательное, что опциональное. Ни там, ни там не было Bit-banding. Всегда отсутствующие фичи можно не указывать вообще. Либо апдейтить документацию. В TRM CM0+ (на сайте арма) тоже нет ни слова о Bit-banding. Если в документации ARMv6-M или TRM CM0+ появится Bit-banding, то утверждения станут корректны для CM0+. С оговоркой, что опцию добавили с какой-то даты. Наличие опции в ките ничего не значит, т.к. кит напоминает сборку запчастей для разных кортексов.
Влад Р.
Появилась новая проблема - написание обработчика прерывания на асме.
Мои знания в асме близки к нулю, тем более под ARMы.
Кто-то может поделиться полезными ссылками, вроде каких-нибудь уроков, курсов в сети. Возможно есть проекты в свободном доступе, где прерывания тоже реализовывались на асме и работали с сишным кодом. Тоже будет полезно.
Forger
Цитата(Влад Р. @ Jun 23 2016, 08:52) *
Появилась новая проблема - написание обработчика прерывания на асме.
Абсолютно тупиковый путь, особенное, если планируется расширять проект (код)!
Я бы просто заново спроектировал проект.
Скорее всего нужно переходить на ртос, тогда число всяких обработчиков прерываний резко сократиться - ведь не на все события нужно реагировать с точность до мкс, опрашивать кнопки тоже нет смысла чаще, чем раз в 50мс. Т.е. для таких вещей хватает одного системного таймера оси (у меня такт в основном 1мс).
Короче, самописный асм на ARMе в своем коде - это крайне опасная и нежелательная вещь, ее нужно всячески избегать и исключать еще на этапе проектирования кода.



Obam
Цитата(scifi @ Jun 22 2016, 21:08) *
Слив защщитан biggrin.gif


Из оффсайда…

Так что ни разу wink.gif
ViKo
Цитата
Измените переменные на 32-битовые. Везде, где можно.

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

Цитата(Влад Р. @ Jun 23 2016, 08:52) *
Появилась новая проблема - написание обработчика прерывания на асме.

Только в качестве обучающего занятия. Примеры можно найти в книжках Дж. Ю, на одну из которых я ссылался.
Obam
Цитата(GetSmart @ Jun 22 2016, 22:19) *
… Bit-banding в СМ0 нет и не ожидается (без намёков). Точнее, подчеркивали что эта фича характерна для СМ3 и выше. И, как уже сказано, её не было в описании ARMv6-М от самого АРМа. В Architecture Reference Manual на какое-то ядро обазано быть данное описание.


Справедливости ради в Architecture Reference Manual этой темы нет, она отражена в Technical Reference Manual.

Цитата(Влад Р. @ Jun 23 2016, 09:52) *
Появилась новая проблема - написание обработчика прерывания на асме.

Кто-то может поделиться полезными ссылками, вроде каких-нибудь уроков, курсов в сети. Возможно есть проекты в свободном доступе, где прерывания тоже реализовывались на асме и работали с сишным кодом. Тоже будет полезно.


Нажмите для просмотра прикрепленного файла
Влад Р.
Цитата(Forger @ Jun 23 2016, 11:12) *
Абсолютно тупиковый путь, особенное, если планируется расширять проект (код)!
Я бы просто заново спроектировал проект.
Скорее всего нужно переходить на ртос, тогда число всяких обработчиков прерываний резко сократиться - ведь не на все события нужно реагировать с точность до мкс, опрашивать кнопки тоже нет смысла чаще, чем раз в 50мс. Т.е. для таких вещей хватает одного системного таймера оси (у меня такт в основном 1мс).
Короче, самописный асм на ARMе в своем коде - это крайне опасная и нежелательная вещь, ее нужно всячески избегать и исключать еще на этапе проектирования кода.

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

Цитата(ViKo @ Jun 23 2016, 11:19) *
Это уже сделали? Где листинг?

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

А для более широких задач почему не подойдет?
Заменил на 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



Цитата(Obam @ Jun 23 2016, 11:27) *
Vincent_Mahout_AssemblyLanguageProgramming_ARM_CortexM3.pdf

Похоже, то что нужно. Спасибо!
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.