Nixon

Вряд ли. Вам нужно будет вычислить тот же объем работы для создания маски сколько и для прямой записи битбандингом плюс еще сохранение этой маски плюс запись этой маски в нужный регистр. Единственно что может ускорить вывод в порт произвольного значения - это формирование таблицы перекодировки "Значение данных - Маска Set - Маска Reset" на этапе компиляции. Но как вы понимаете кушать память оно будет огого.

Я возможно неправильно вас понимаю, но имея порт шириной 4 на пинах, допустим, <1,3,5,7> и желая установить на него произвольное значение типа 0bxxxx вы не сможете предварительно создать маску этого самого произвольного значения для записи этого значения на нужные пины.

Как вы создадите маску для произвольных данных?

А это все равно быстрее будет чем формировать нужную маску

Цикл не нужен. Посмотрите как реализован SetDout и как определяются DOUTx_ADDR // CLASS PORTPINS TEMPLATE template < char port, uint8_t... pins > class PortPins; template < char port, uint8_t pin0, uint8_t... pins> class PortPins<port, pin0, pins...> { private: enum { PIN_COUNT = sizeof...(pins) + 1 }; static constexpr uint8_t pinlist[16] = { pin0, pins... }; static constexpr bool NO_DOUBLED_PIN ( void ) { for (int i = 0; i < PIN_COUNT; i++) for (int j = i + 1; j < PIN_COUNT; j++) if (pinlist[i] == pinlist[j]) return false; return true; } static_assert((port >= 'A') && (port <= 'F'), "Error!!! Illegal GPIO port name!!!"); static_assert((sizeof...(pins) < 16), "Error!!! Illegal pins count!!!"); static_assert((pin0 < 16), "Error!!! Illegal pin number!!!"); static_assert(NO_DOUBLED_PIN(), "Error!!! Doubled pins found!!!"); enum { GPIOx_BASE = port_base_t<port>::GPIOx_BASE }; enum { DOUTBB_BASE = 0x42000000UL + (GPIOx_BASE + offsetof(GPIOxTypeDef, DOUT) - 0x40000000UL) * 32 }; enum { DOUT0_ADDR = (DOUTBB_BASE + pinlist[0] * 4) * ((0 < PIN_COUNT) ? 1 : 0) }; ... enum { DOUT15_ADDR = (DOUTBB_BASE + pinlist[15] * 4) * ((15 < PIN_COUNT) ? 1 : 0) }; ... private: INLINE static void SetDout ( int value ) { if constexpr (DOUT0_ADDR) { *(volatile uint32_t*)DOUT0_ADDR = value; value >>= 1; } ... if constexpr (DOUT15_ADDR) { *(volatile uint32_t*)DOUT15_ADDR = value; value >>= 1; } } ... }

Старею, не распознал :)

У вас тормозит "индусский" код? Тогда мы идем к вам!

Не выдумывайте - это работа максимум на один день для программиста средней квалификации. Например для IAR: 1) oткрыть текстовый файл *.map 2) найти в нем блок "ENTRY LIST" 3) распарсить в массив "файл-функция-адрес-длина-тип" 4) найти свой адрес в этом массиве 5) вывести "файл-имя" Все. Строчек 100 кода на C#. Даже пример кода бросать не буду, чтоб интерес не убивать на корню.

Можно. В настройках проекта, в категории Debugger увидите поле "Setup macro". Включите галочку и выберите/создайте макро файл с командами Язык этого файла С-подобен, пример execUserFlashInit() { // unlock flash __writeMemory32(0x45670123, 0x40023C04, "Memory"); // FLASH->FKEYR = FLASH_KEY1; __writeMemory32(0xCDEF89AB, 0x40023C04, "Memory"); // FLASH->FKEYR = FLASH_KEY2; } Более подробно читайте в help раздел "C-Spy Macro". По сути вы можете со своей целевой платформой творить все что захотите не загружая компилированную программу

Мой бездумный копипаст :) . Спасибо за указание на ошибку. Исправил.

struct TICKCOUNTER { inline static void RESET ( void ) { CoreDebug->DEMCR |= 0x01000000; DWT->CYCCNT = 0; DWT->CTRL = 0; } inline static void START ( void ) { DWT->CTRL |= 1; } inline static uint32_t STOP ( void ) { DWT->CTRL &= ~1; return DWT->CYCCNT; } }; Сделано по документации на M3.

Исользуя С/С++ всегда есть возможность себе что-то отстрелить... :) Задача у меня была простая - есть проект в котором некоторые переменные должны иметь зеркало во внешней памяти (назовите это конфигом, архивом, аудитом и т.п.). Желательно было иметь функционал позволяющий без дополнительных усилий изменять список этих переменных, менять их расположение (внешней памяти может быть несколько видов, несколько копий и т.д.) в одном месте. Ну и конечно, вы правильно заметили - RAM мало, ROM много, желательно иметь элемент связи между переменной и ее зеркалом расположенный в ROM. Проблемы расположения переменных линкером в данном примере НЕ имеют влияния. P.S. Ранее этот движок был реализован на чистом С и требовал при модификации списка переменных изменений в 8 (!!!) местах проекта, что неимоверно раздражало, плюс таблицы адресов/типов/размеров переменных формировались в рантайме и кушали изрядный кусок RAM. P.S.S. Исправил ошибку - добавил НЕ

Весь движок в vault.hpp. Fram.hpp и eeprom.hpp - это примеры создания НЕСКОЛЬКИХ объектов хранилища (требование моего проекта). Ну а в main.cpp собственно использование с массой ненужного.

Можно. Недавно такую задачу решал - создание на этапе компиляции таблицы смещений параметров во внешней памяти по списку параметров. Посмотрите мой пример - это тестовый проект. Там много вам ненужного, но суть будет понятна. Основной файл - vault.hpp vault.7z

Беги