C++ із ARM GCC + STM32 (+ CoIDE)

Автор С++, Б'ярн Страуструп
Фото взято тут.

Програми практично на будь-якій (*) мові програмування потребує підтримки так-званого коду часу виконання --- runtime. Для С цей код відносно простий, С++ вимагає складнішого --- всілякі там ініціалізації статичних змінних, підтримка роботи із виключеннями, тощо. Зазвичай програмісти не повинні про це турбуватися --- компілятор, разом із операційною системою все забезпечує. Однак, програмуючи мікроконтролери, дуже часто доводиться обходитися без операційних систем (про RTOS всілякі поговоримо іншим разом), а відповідно, без підтримки стандартних бібліотек, які змушені звертатися до ОС для виконання своїх функцій. При тому,  якщо необхідний мінімум підтримки мовних конструкцій С присутній майже завжди, із С++ типова ситуація гірша. Це нікуди не годиться, насправді.

(*) З традиційною обмовкою, що всезагальні твердження про об'єкти реального світу, завжди помилкові -- включаючи це твердження. :-)

Давайте подивимося, яка runtime-підтримка потрібна C++, а потім -- що потрібно "допилювати" вручну, щоб добитися її, працюючи із наступним комплектом інструментів: ARM GCC 4.8 та 4.9 + STM32 CMSIS + CoIDE. Для інших компіляторів -- будуть суттєві відмінності, навіть для інших версій GCC певні відмінності можуть бути. Для інших контролерів -- будуть відмінності. Із середовищем -- як повезе. [Можливо, про Keil поговоримо окремо.]

Розгляд нижче -- достатньо мінімалістичний. І так пост непомірно великий. Про підтримку локалей мова не йде, для контролерів вони просто не вартують затрат. Взагалі, про ціну за використання окремих можливостей С++ буде окремий пост -- сюди воно просто не влазить. Хіба скажу -- зазвичай ця ціна нульова або незначна. Основні винятки описані нижче -- виключення і RTTI.

Вважатимемо, що вже обговорена підтримка стандартної бібліотеки у нас є. Працюватимемо все із тією ж STM32VLDiscovery, обладнаною мікроконтролером STM32F100RB. Сама по собі модель мікроконтролера не є аж такою важливою, але для ясності, орієнтуватимемося на його ресурси -- 128 Кб пам'яті програм, 8Кб оперативної пам'яті.

Так як пост вийшов достатньо великим і трохи плутаним, почну  із короткого огляду:

• C++ runtime. Огляд задач, які стоять перед кодом часу підтримки, зокрема -- перед його реалізаціями, libstdc++ і libsupc++.
• Ініціалізація. З чого починає роботу контролер, і як добитися, щоб стандартна для С++ процедура підготовки програми перед входом в main(), зокрема -- виклик конструкторів глобальних об'єктів відбувалася, як очікується. Розглядається процедура ініціалізації контролера, підхід GCC  до ініціалізації програми (зокрема, всілякі там crt0.o) та обробник переривання Reset. Також, для повноти, зачіпається тема "деініціалізації" -- виклику деструкторів по завершенню main(), хоча для контролерів можливість не є особливо цінною.
• Оператори new, new[], delete, delete[]. Особливості реалізації, вимоги до них, опис цілого зоопарку цих операторів.
• Виключення. Дуже корисна можливість сучасних мов програмування, яка, на жаль, вимагає складної підтримки часу виконання і помітних ресурсів для своєї роботи (помітних -- в масштабах доступних контролеру ресурсів). Самопальною тут не обійдешся. Тому рекомендується їх просто не використовувати. Якщо ж таки є потреба у них, (чи є просто бажання спробувати), розповідається, як підключити їх підтримку засобами libsupc++, і чого це коштуватиме. Звертається увага на відмінності обробки виключень в GCC  для ARM та його ж для інших архітектур. Є посилання для подальшого заглиблення. Згадується альтернативна реалізація C++ runtime -- libcxxrt, про яку буде окремий пост.
• RTTI -- RunTime Type Information. Так само, як із виключенням, краще без цієї можливості обійтися, якщо ж таки дуже треба (не вдається прожити без dynamic_cast<> :-), розповідається, як її підключити -- крім компонування із libsupc++ слід додати декілька функцій: __cxa_bad_cast(), __cxa_bad_typeid(), що задають реакцію на відповідні події.
• Реакція на виклик чисто віртуальних чи видалених функцій. Власне -- воно, пара функцій, що викликатимуться у таких нещасливих випадках. Компілятор вставляє їх виклик в патологічних місцях коду, без надання їх реалізації будуть помилки компонування.
• Локальні статичні змінні. Для захисту від одночасного доступу, race condition, під час ініціалізації статичних змінних в багатопоточному середовищі, компілятор вставляє спеціальні захисні виклики (таке собі блокування-розблокування мютекса). Написати ці функції коректно відносно складно, тому тут, для початку, описано мінімальні заглушки, які, насправді, не захищають, але дозволяють коду скомпілюватися. (За більш  повною реалізацією див. ту ж libcxxrt).
• C++11. Більшість мовних засобів мали б працювати зразу, без додаткової підтримки.
• Стандартна бібліотека С++. Включаючи STL. Огляд того, що вдасться використовувати зразу, що потребує певної підтримки часу виконання, а для чого доведеться тягнути цілу libstdc++. Якщо коротко -- послідовні контейнери (vector<>, deque<>, list<>, array<>, і т.д.) та більшість алгоритмів можна використовувати майже зразу. Асоціативні вимагають компонуватися із libstdc++. Паралельно розглянуті деякі брудні трюки, що дозволяють справитися із дещо непомірними її апетитами щодо RAM. Ілюстрація затрат ресурсів на це все.
• Керування та відстеження динамічного виділення пам'яті.
• Опис демонстраційного проекту.
• Додаток містить прокоментований скрипт лінкера.

Для лінивих, демонстраційний проект тут.

На жаль, якорі HTML в цьому блозі чомусь дуже капризно поводяться, тому, щоб не витрачати додаткового часу (даний пост його спожив неміряно!), не використовую їх для посилання на розділи нижче (може потім додам, під настрій).

Перш ніж перейти до тексту, див. заголовок блогу --- виклад не всюди робиться із повним розумінням процесів, іноді -- емпіричний, тому ніяких гарантій. Звичайно, буду вдячний за уточнення та виправлення!