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 }; ).

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

[scifi]

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

Да.

Или обработка прерывания возможна?

Нет.

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

Да.

Кстати, в том же STM32F427 есть такая штука, как два банка флеш. Пока один банк стирается, программа может выполняться из другого.
Или поставьте внешнюю флешку SOIC8 из 25-й серии. Их везде как грязи, и стоят они копейки.