STM32F: Функция в RAM Опции

[amiller]

Раньше я много работал с серией микроконтроллеров C2000 от Техаса.
Там был механизм (CCStudio), позволяющий разместить любую функцию в RAM. Это позволяло существенно ускорить выполнение критического кода, а также избежать остановки выполнения программы в процессе записи или стирания Flash. Механизм примерно такой:
1. Для информирования линкера создавалась специальная секция: размещение во Flash, запуск из RAM.
2. При компоновке линкер все адреса вызовов модифицирует так, как будто этот код уже располагается в RAM.
3. В процессе инициализации эта секция копируется в RAM стандартно, по аналогии с инициализируемыми переменными.
4. При выполнении, при обращении к функции происходит переход по адресу в RAM.
К сожалению для STM32 я пока не обнаружил аналогичного механизма.
Больше всего меня смущает не быстродействие (конвейер в STM32 достаточно хорош), а проблема, связанная со стиранием больших секторов. Например в STM32F4 время, на которое код зависает при выполнении из Flash, может достигать сотен миллисекунд.
Конечно можно весь код разместить в RAM, но не всегда это возможно из соображений размера, да и защита от несанкционированного копирования кода в этом случае имеет проблемы.
Хотелось бы более красивое решение.
Есть мысли по этому поводу? Может я просто не нашёл нужный документ или пример?

[scifi]

Больше всего меня смущает не быстродействие (конвейер в STM32 достаточно хорош), а проблема, связанная со стиранием больших секторов. Например в STM32F4 время, на которое код зависает при выполнении из Flash, может достигать сотен миллисекунд.

Зависит от того, что вы хотите делать в течение этих сотен миллисекунд. Если что-то нетривиальное, то обнаружите, что половину вашего кода, если не больше, нужно будет размещать в ОЗУ. Причём отделить нужное от ненужного будет ой как не просто.
Кстати, зачем стираете большие сектора? Я для эмуляции EEPROM выделяю 2 сектора по 16 кБайт. Там типичное время стирания сектора 250 мс. В моих применениях программа может подождать 250 мс.

[amiller]

Зависит от того, что вы хотите делать в течение этих сотен миллисекунд. Если что-то нетривиальное, то обнаружите, что половину вашего кода, если не больше, нужно будет размещать в ОЗУ. Причём отделить нужное от ненужного будет ой как не просто.
Кстати, зачем стираете большие сектора? Я для эмуляции EEPROM выделяю 2 сектора по 16 кБайт. Там типичное время стирания сектора 250 мс. В моих применениях программа может подождать 250 мс.

У меня примерно так: Первые два сектора по 16к - загрузчик. Следующие два сектора по 16к - EEPROM. Затем код основной программы. В конце два больших сектора под запись протоколов.
Устройство должно протоколировать все события в системе. Протоколы пишутся во кругу в два сектора. И всё равно когда то наступает момент, когда нужно стереть сектор. Я конечно стараюсь отложить этот момент на время, безопасное со всех точек зрения, но проблема существует.
По поводу того, что именно помещать в ОЗУ, да такая проблема есть, но решаемая. Обычно это прерывания, плюс несколько важных функций.
В нормальном режиме у устройства обмен по нескольким каналам связи со скоростями 5-10кбайт в секунду. Зависание на такое время (сотни миллисекунд) даже визуально проявляется на мониторе связи. Не говоря уже о таких процессах, как управление ШИМ-преобразователем.
Кстати ещё один вопрос: Если во время стирания флэш, произойдёт любое обращение к флэш, то программа зависнет до окончания операции стирания? Или обработка прерывания возможна? Скорее всего, даже для того, чтобы работали прерывания, нужно на время операции стирания исключить любые обращения к флэш. Так?

Значит Вам повезло, потому что в папке doc есть файл EWARM_DevelopmentGuide.ENU.pdf.
Там есть описание как работает __ramfunc и какие изменения нужно сделать в конфиге линкера (initialize by copy { section .textrw }; ).

Спасибо, посмотрю. Наверное это то, что мне нужно. Хотя документ известный, вряд ли я мимо прошёл. Может чем то не устроил.

[SSerge]

Кстати ещё один вопрос: Если во время стирания флэш, произойдёт любое обращение к флэш, то программа зависнет до окончания операции стирания? Или обработка прерывания возможна? Скорее всего, даже для того, чтобы работали прерывания, нужно на время операции стирания исключить любые обращения к флэш. Так?

Именно.

Any attempt to read the Flash memory on STM32F4xx while it is being written or erased,
causes the bus to stall. Read operations are processed correctly once the program
operation has completed. This means that code or data fetches cannot be performed while
a write/erase operation is ongoing.

Т.е. читать можно, но это приведёт к приостановке выполнения программы до конца операции стирания или записи.
Именно это и происходит при обычном стирании/записи без перемещения программы в RAM.

On STM32F42xxx and STM32F43xxx devices, two banks are available allowing read
operation from one bank while a write/erase operation is performed to the other bank.

А на этих контроллерах можно исполнять программу из одного банка в то время как второй пишется или стирается.