Скорость работы пина зависит от других пинов. Это нормально?

@xintrea · Регистрация: 29.10.2013

Студворк — интернет-сервис помощи студентам

Привет, народ!

Заметил такую странность, которую не знаю как объяснить. Плата STM32F103C8T6 (Blue Pill)

Я хотел сделать мигание светодиодом на ноге A0 при инициализации контроллера на 72MHz.

Взял сделанный ранее проект и стал его упрощать. И вот когда оставил в проекте, по-сути, только:

- инициализацию на 72Mhz
- включение тактирования портов
- настройку пина A0,

то заметил, что код мигания стал работать медленнее! Т. е. мигание, сделанное в бесконечном цикле, стало в 1.5-2 раза медленнее, чем было до.

Я стал разбираться, что могло на это повлиять. И вернул вызов ненужной функции, в которой инициализировались пины A8, A9, B3, B4, B6, B7. И о чудо, мигание стало опять быстрым! Повторюсь, в этой функции делается только инициализация пинов, и она вызывается один раз в начале программы, ничего более.

Вот полный код: https://pastebin.com/Z7d0LZif

А вот код функции, которая "разгоняет" выполнение кода:

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// Настройка пинов A8, A9, B3, B4, B6, B7
void otherPortInit(void)
{
    // Для начала сброс конфигурации всех используемых портов в ноль
    GPIOA->CRH &= ~(GPIO_CRH_MODE8 | GPIO_CRH_CNF8);
    GPIOA->CRH &= ~(GPIO_CRH_MODE9 | GPIO_CRH_CNF9);
 
    GPIOB->CRL &= ~(GPIO_CRL_MODE3 | GPIO_CRL_CNF3);
    GPIOB->CRL &= ~(GPIO_CRL_MODE4 | GPIO_CRL_CNF4);
    GPIOB->CRL &= ~(GPIO_CRL_MODE6 | GPIO_CRL_CNF6);
    GPIOB->CRL &= ~(GPIO_CRL_MODE7 | GPIO_CRL_CNF7);
 
 
    uint32_t mode;
    uint32_t cnf;
 
    mode=0b11; // Режим выхода, с максимальной частотой 50 МГц
    cnf=0b00;  // Режим push-pull
    GPIOA->CRH |= (mode << GPIO_CRH_MODE8_Pos) | (cnf << GPIO_CRH_CNF8_Pos);
    GPIOA->CRH |= (mode << GPIO_CRH_MODE9_Pos) | (cnf << GPIO_CRH_CNF9_Pos);
 
    mode=0b00; // Режим входа
    cnf=0b01;  // Режим плавающего входа, подтяжки нет
    GPIOB->CRL |= (mode << GPIO_CRL_MODE3_Pos) | (cnf << GPIO_CRL_CNF3_Pos);
    GPIOB->CRL |= (mode << GPIO_CRL_MODE4_Pos) | (cnf << GPIO_CRL_CNF4_Pos);
    GPIOB->CRL |= (mode << GPIO_CRL_MODE6_Pos) | (cnf << GPIO_CRL_CNF6_Pos);
    GPIOB->CRL |= (mode << GPIO_CRL_MODE7_Pos) | (cnf << GPIO_CRL_CNF7_Pos);
}

Я не могу эту вещь объяснить. Почему настройки пинов, которые не используются в коде, так странно влияют на скорость выполнения программы контроллером? Мало того, в базовом проекте, на точно таком же коде я обнаружил обратный эффект: вызов этой функции инициализации портов замедляет мигание, а комментирование ее вызова - ускоряет.

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

Вопрос 1: Как единственный вызов этой функции может влиять на скорость выполнения основного цикла?
Вопрос 2: Почему вызов этой функции может давать строго обратный эффект?

@VladimirU · 03.05.2022, 22:14

Чёт связано с перефирией. Выходит лучше явно определить не используемые пины портов чем оставить их в воздухе?

@xintrea · 03.05.2022, 22:21 **[ТС]**

Но эта функция не определяет ВСЕ пины на портах A и B, а только A8, A9, B3, B4, B6, B7. Остальные так и болтаются несконфигуренными.

@alexey6689 · 04.05.2022, 23:19

Посмотрите на код, создаваемый компилятором для функции msdelay(int) в обеих случаях. Вангую, что он будет разным -)).

@xintrea · 05.05.2022, 00:19 **[ТС]**

Нет, он одинаковый, байт в байт. Только смещения самой функции разное, и видимо именно в этом и дело.

Скриншот сравнения прикреплен.

@alexey6689 · 05.05.2022, 00:56

Попробуйте переключить режим порта отладки в режим SWD. Для этого:
- включите тактирование AFIO (RCC_APB2ENR, бит 0 установить в 1).
- после этого в AFIO_MAPR поле SWJ_CFG[2:0] переключите в состояние 010 (JTAG-DP disabled, SW-DP enabled).

Добавлено через 1 минуту
Естественно это можно делать только если вы используете отладчик SWD.

@xintrea · 05.05.2022, 01:06 **[ТС]**

Похоже, разобрались в проблеме. Дело было в выравнивании кода на FLASH.

Подробности тут: https://www.linux.org.ru/forum... t/16860172

@alexey6689 · 05.05.2022, 01:22

Да, интересно -)).

Новые блоги и статьи Все статьи Все блоги /
Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .
Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .

@VladimirU 62 / 187 / 31 Регистрация: 14.02.2013 Сообщений: 1,701
	03.05.2022, 22:14
	Чёт связано с перефирией. Выходит лучше явно определить не используемые пины портов чем оставить их в воздухе? 0

@xintrea 1 / 1 / 0 Регистрация: 29.10.2013 Сообщений: 74
	03.05.2022, 22:21 [ТС]
	Но эта функция не определяет ВСЕ пины на портах A и B, а только A8, A9, B3, B4, B6, B7. Остальные так и болтаются несконфигуренными. 0

@alexey6689 210 / 163 / 36 Регистрация: 15.11.2012 Сообщений: 788
	04.05.2022, 23:19
	Посмотрите на код, создаваемый компилятором для функции msdelay(int) в обеих случаях. Вангую, что он будет разным -)). 0

@xintrea 1 / 1 / 0 Регистрация: 29.10.2013 Сообщений: 74
	05.05.2022, 00:19 [ТС]
	Нет, он одинаковый, байт в байт. Только смещения самой функции разное, и видимо именно в этом и дело. Скриншот сравнения прикреплен. Миниатюры 0

@alexey6689 210 / 163 / 36 Регистрация: 15.11.2012 Сообщений: 788
	05.05.2022, 00:56
	Попробуйте переключить режим порта отладки в режим SWD. Для этого: - включите тактирование AFIO (RCC_APB2ENR, бит 0 установить в 1). - после этого в AFIO_MAPR поле SWJ_CFG[2:0] переключите в состояние 010 (JTAG-DP disabled, SW-DP enabled). Добавлено через 1 минуту Естественно это можно делать только если вы используете отладчик SWD. 0

@xintrea 1 / 1 / 0 Регистрация: 29.10.2013 Сообщений: 74
	05.05.2022, 01:06 [ТС]
	Похоже, разобрались в проблеме. Дело было в выравнивании кода на FLASH. Подробности тут: https://www.linux.org.ru/forum... t/16860172 0

@alexey6689 210 / 163 / 36 Регистрация: 15.11.2012 Сообщений: 788
	05.05.2022, 01:22
	Да, интересно -)). 0