[kvandr 0]

Подскажите, кто знает, как в STM32F7 весь код загрузить вo внутреннюю ram и оттуда выполнять. Например в Keil. Для большей предсказуемости времени выполнения. Спасибо.

[scifi 1]

Я делал вот так:

extern char __etext, __data_start__, __data_end__, __bss_start__, __bss_end__, __vtab_start__;

// copy to RAM for execution
int src = 0;
int dst = 0x20000000;
int len = (int)(&__etext + (&__data_end__ - &__data_start__));
memcpy((void*)dst, (void*)src, len);

RCC->APB2ENR |= RCC_APB2ENR_SYSCFGEN;
SYSCFG->MEMRMP = 3; // map RAM at 0

Правда, у меня STM32F4 и GNU Arm Embedded.

 

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

[kvandr 0]

В F7 в принципе код выполняется странно. Даже кол-во _nop точно не выдерживается.

 

[Forger 17]

Для большей предсказуемости времени выполнения.

Может есть смысл размещать в ОЗУ не весь код, а только тот, который этого требует?

Особенно выгодно по скорости выполнения размещать код в области ОЗУ, которая напрямую подключена к ядру (в STM32 она называется TCM RAM).

В KEIL это делается очень просто, почитайте мануал.

Если нужно весь код, то я бы сделал так:

пишем простейший загрузчик (стартуемый из FLASH), который копирует и возможно даже на ходу распаковывает сжатый код из FLASH в ОЗУ.

Делает ремап векторов (в NVIC поправить всего один регистр) и запускает загруженный код.

 

А сам код для исполнения в ОЗУ собирается уже с другими параметрами линкера (в скрипте линкера нужно лишь поправить несколько строчек кода).

 

После чего его (BIN файл) можно упаковать (при желании) и добавить в прошивку загрузчика как внешний файл. KEIL это умеет.

 

 

Т. е. можно так настроить, что нужный HEХ при компиляции будет формироваться автоматически, для этого лишь нужно выбрать нужный режим (у меня обычно DEBUG/RELEASE) в выпадающем списке.

 

 

[kvandr 0]

 

На каком этапе этот загрузчик поместить в код?

Изменено 10 ноября, 2017 пользователем IgorKossak
бездумное цитирование

[jcxz 184]

В F7 в принципе код выполняется странно. Даже кол-во _nop точно не выдерживается.

На F7 (да и пожалуй на любом из старших ARMов) в принципе не надо писать код, основанный на времени выполнения NOPов.

[Forger 17]

На каком этапе этот загрузчик поместить в код?

Создаете ДВА проекта -

проект А - для формирования финальной прошивки (бинарник берем из проекта B ) вместе с простым загрузчиком.

проект B - для целевого кода, в сборке DEBUG выполняется и отлаживается как обычно из флэш, в RELEASE сборке - финальная прошивка с размещением всего кода в ОЗУ.

 

А почему не хотите переместить в ОЗУ лишь части проекта, которым это действительно необходимо?

[kvandr 0]

 

А почему не хотите переместить в ОЗУ лишь части проекта, которым это действительно необходимо?

 

 

Код всего 56 кб, а ресурсов ему много надо. И к тому же скорость и повторяемость по времени выполнения. Иначе на экране дрожит сигнал.

[Forger 17]

Код всего 56 кб, а ресурсов ему много надо.

Каких ресурсов?

 

И к тому же скорость и повторяемость по времени выполнения.

Разметите критический важный кусок кода внутри отдельных функций, размещенных в отдельном С/CPP файле, поместите весь файл в секцию RAM (как это сделать, см. мануал на Keil).

Тогда не придется городить загрузчик лишь для того, чтобы весь код засунуть в ОЗУ.

 

Иначе на экране дрожит сигнал.

Вы действительно полагаете, что перемещение ВСЕГО кода в ОЗУ поможет решить эту проблему? ;)

[kvandr 0]

Каких ресурсов?

 

Вы действительно полагаете, что перемещение ВСЕГО кода в ОЗУ поможет решить эту проблему? ;)

 

Три четверти функций очень чувствительны и к скорости и к синхронности. Где-то так. Очень не хочется плиску ставить. Всё работает, но не хватает скорости совсем немного.

Отсутствие 5ти -6 ти waitstates может помочь.

Изменено 10 ноября, 2017 пользователем quandr

[Forger 17]

Три четверти функций очень чувствительны и к скорости и к синхронности. Где-то так.

Чисто праздный интерес: каким способом вы пришли к тому, что перенос кода в ОЗУ решит проблему?

[kvandr 0]

Чисто праздный интерес: каким способом вы пришли к тому, что перенос кода в ОЗУ решит проблему?

 

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

[Forger 17]

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

Если не секрет, то о какому чудо-проекте идет речь? Любопытно ))

[kvandr 0]

Если не секрет, то о какому чудо-проекте идет речь? Любопытно ))

Ультразвуковой прибор. Внутренний ЦАП через ДМА управляет VGA, а внешний АЦП через DMA2 GPIO и TIM8 в режиме ШИМ оцифровывает сигнал со скоростью 20 MSPS. Приколы начинаются с того, что после излучения импульса 500 нс, почему-то проходит разное время до запуска дма. Хотя больше ничего не выполняется и systick выключен. От этого и дрожит сигнал. Потом еще бих фильтр полосовой, фильтр экрана нужен и вывод картинки.

Изменено 10 ноября, 2017 пользователем quandr

[Forger 17]

Внутренний ЦАП через ДМА управляет VGA, а внешний АЦП через DMA2 GPIO и TIM8 в режиме ШИМ оцифровывает сигнал со скоростью 20 MSPS.

Лютое решение (((

Конечно, уже поздно переделывать железо, но почему решили все это чисто на MCU, а не поставили хотя бы FPGA в связке с практически любым МК?

 

если 2/3 кода требуют работы из ОЗУ, так разместите этот код в отдельный файл, разместите его в секции ОЗУ, а все остальное оставьте во флэш.

Таблицу векторов желательно скопировать в ОЗУ с перенастройкой NVIC, причем кидать в TCM ОЗУ. Судя по размеру проекта, хватит всей TCM на весь код )))