Навіщо виконувати код з ОЗУ?

Я щойно натрапив на макроси мого компілятора мікроконтролера, щоб змусити (або запропонувати) функцію виконувати з ОЗП.

https://siliconlabs.github.io/Gecko_SDK_Doc/efr32mg1/html/group__RAMFUNC.html#gac6abbc7f869eec9fb47e57427587c556

http://processors.wiki.ti.com/index.php/Placing_functions_in_RAM

https://www.iar.com/support/tech-notes/linker/controlling-placement-of-the-section-where-__ramfunc-functions-reside-ewarm-5.x--6.x/

https://community.nxp.com/thread/389099

У яких випадках це цінно? Чому б мені просто не завжди виконувати оперативну пам’ять, якщо користь лише підвищена швидкість? Це, як правило, спричиняє більший розрив струму?

На додаток до швидкості та інших функцій, про які вже згадували інші, виконання коду з оперативної пам’яті може бути корисним у завантажувачах, де потрібно перепрограмувати спалах мікрофона - ви не можете виконати код із спалаху, який ви посередині стираєте & перепрограмування.

Я не дивився на таблицю даних для цього мікрофона. Однак у цій ситуації часто трапляється, що завантаження з оперативної пам’яті відбувається швидше, ніж отримання флеш-пам’яті, з якої реалізована пам'ять програми.

Перевага спалаху в тому, що великі кількості можуть бути відносно дешевими. Тому виробники мікроконтролерів іноді ставлять багато спалаху на мікросхемі, а потім надають більш обмежений простір оперативної пам’яті, з якого може виконуватись код. Це дозволяє копіювати критичні за часом підпрограми в оперативну пам'ять, а потім виконувати їх звідти.

Перемикач компілятора, на який ви посилаєтесь, ймовірно, працює з лінкером і позначає цей розділ спалаху, який повинен бути скопійований в оперативну пам’ять кодом часу виконання компілятора, який працює від скидання. Різні реалізації залежать від деталей.

Коли ви хочете виконати оперативну пам’ять, тому що це швидше, це зазвичай тому, що оперативна пам'ять знаходиться на чіпі SRAM. Це дефіцитний ресурс, який ви, мабуть, захочете для даних, які потребують доступу для читання / запису.

Використання його для коду, коли ви вже маєте код у ROM / flash означає, що вам потрібна кількість X спалаху та додаткова кількість X оперативної пам’яті.

Також потрібна додаткова стадія копіювання під час завантаження або коли ви хочете запустити її, хоча це здебільшого незначно.

Традиційно це вирішується кешем інструкцій, але в мікроконтролері може бути більше сенсу зберігати внутрішній SRAM загальний, тому що ви не використовуєте мікроконтроллер, тому що вам потрібна максимальна швидкість виконання.

Існує також проблема з надійністю - виконання коду у фактичному ПЗУ важко змінити кодом помилок.

Окрім усіх хороших відповідей:

Чому б мені просто не завжди виконувати оперативну пам’ять, якщо користь лише підвищена швидкість?

Оскільки у вбудованій системі зазвичай не вистачає необхідної кількості оперативної пам’яті. Наприклад, STM32, що має 32 кБ або оперативну пам'ять і 512 кБ EEPROM. Щоб мати змогу виконати всю програму в оперативній пам'яті, вам знадобиться розмір оперативної пам’яті більше, ніж EEPROM.

Інші відповіді, здається, не дуже обговорювали споживання електроенергії, про що ви спеціально запитали.

Відповідь полягає в тому, що це дещо залежить від мікроконтролера, але часто виконання оперативної пам’яті може зменшити споживання енергії, оскільки для читання інструкцій з ОЗУ потрібно менше енергії, ніж з флеш-пам’яті.

Типовим способом буде використання функції "сну" з низькою потужністю від оперативної пам'яті, при відключенні флеш-пам'яті. Мало того, що зменшується енергоспоживання, але якщо мікроконтролеру потрібно швидко прокинутися (наприклад, у відповідь на зовнішнє переривання), затримки не відбувається, коли флеш-пам’ять знову увімкнеться.

Деякі деталі, такі як деякі з асортименту Atmel SAM, мають спеціальну оперативну пам'ять надмірної потужності, яку можна використовувати для цієї мети. Це дозволяє завантажувати невелику кількість коду до спеціальної оперативної пам’яті, тоді як основна кількість наявної оперативної пам’яті та всіх інших пам’яток призупиняється, а мікроконтролер переходить у режим глибокого сну.

Окрім потенційних переваг швидкості, згаданих іншими, код оперативної пам’яті також є динамічним і може бути змінений під час руху за допомогою певного кодового коду у FLASH, якщо потрібно.

Це може бути таким же простим, як зміна декількох параметрів, або ж цілі підпрограми обробника, завантажені віддалено.

Виконання коду з оперативної пам'яті значно швидше, ніж його виконання з флеш-пам'яті. Більшість процесорів сильно оптимізовані для якнайшвидшого доступу до ОЗУ, і навіть найшвидша флеш-пам'ять досягає лише частки швидкості оперативної пам'яті.

Однак майте на увазі, що переміщення коду з флеш-пам’яті також потребує часу. Якщо код виконується лише один раз, його потрібно прочитати лише один раз, і тому ви фактично втратите час для копіювання його в оперативну пам’ять, а не безпосередньо його виконання. Якщо код виконується періодично (тому його копіювання в оперативну пам’ять збільшить виконання вдруге, коли він викликається), але система, як правило, не працює, тоді ви виконали б цей код швидше, скопіювавши його в оперативну пам'ять, але ніхто не піклується, оскільки система має достатньо часу для проведення.

Тож такі оптимізації варті лише зусиль, якщо код виконується часто, і ви виміряли його як точку захвату системи.

З іншого боку, оперативній пам'яті потрібно активно зберігати дані, що зберігаються, а флеш-пам’яті цього немає, тому загальне енергоспоживання збільшується, якщо оперативну пам’ять потрібно підтримувати активною. Однак це актуально лише в тому випадку, якщо оперативна пам’ять інакше взагалі не використовується, але більшість сучасних систем, так чи інакше, вже використовуватимуть наявну оперативну пам’ять і тому вже підтримують її активною.

Існує дві дуже поширені причини для виконання коду з ОЗУ:

1. Деякі мікропроцесори не можуть виконати спалах під час програмування флеш - хоча багато хто може це робити, якщо код знаходиться в іншому блоці від записаного спалаху. Запис Flash може бути перепрограмуванням програми (корпус завантажувача) або коли флеш використовується для зберігання інформації про нелетучу програму (конфігурація, калібрування тощо)

2. На багатьох мікропроцесорах оперативна пам'ять набагато швидша, ніж спалах. Для цих пристроїв невеликі режими, пов'язані з швидкістю швидкості, можуть виконуватися з оперативної пам’яті, хоча зазвичай оперативна пам’ять набагато коротше, ніж спалах.

Ще одна справа використання для оперативної пам’яті лише для захисту від випадкових бітфліпів. Ми використовуємо цю модель на нашому маленькому кубізоті, оскільки на головній платі комп'ютера є баран ECC, який переносить бітфліпи через радіацію. Вся ОС завантажується в операційний модуль, оскільки рамковий диск під час запуску повністю працює в середовищі ECC.

Спалах не захищений ECC (стандартні картки micro SD SD), однак у нас є інші методи перевірки корупції (кілька зображень, контрольних сум тощо)