Мікро-реалізація стандартної бібліотеки C++ -- uClibc++

Саморобна амфібія. (c) wiki

Якщо libcxxrt підміняє собою libsupc++, то uClibc++ намагається бути всім решта із libstdc++, що не входить в libsupc++. Тобто, для свого функціонування вона потребує libsupc++ (або libcxxrt) -- бібліотеку низькорівневої підтримки.

Подивимося, що це за звір. Скачати її можна на офіційному сайті. В архіві є файл INSTALL, в якому описана процедура інсталяції. На жаль, вона доволі нетривіальна і сильно зав'язана на Linux (хоча, перенесення під Windows видається можливим). Перший етап -- "make menuconfig", генерує конфігурацію бібліотеки -- можливості, які слід включити. Результатом його буде файл system_configuration.h, із купою макросів виду "#define __UCLIBCXX_STL_BUFFER_SIZE__ 32". Після чого слід виконати хитрі магічні процедури, в результаті яких буде отримано незалежний lib-файл.

Для економії часу, я схитрував --- критично важливий system_configuration.h згенерував на доступній мені Linux-машині, а решту операцій уник, додавши файли бібліотеки до проекту. Для ясності, це може виглядати так -- в директорії проекту створюється директорія uclibcxx, до неї копіюється вміст директорій src та include із архіву текстів бібліотеки, крім Makefile-ів та піддиректорії src/abi -- вона буде зайвою. В include кладемо і system_configuration.h. В середовищі створюємо відповідні групи, додаємо до них файли із цих директорій. (Готовий демонстраційний проект CoIDE, як завжди, можна скачати тут).

Додаємо libsupc++ до списку бібліотек (як це робити, не раз згадувалося в попередніх постах) -- uClibc++ покладається на неї. (libstdc++, навпаки, повністю самодостатня, фактично є "два-в-одному"). Також, вважаємо, що С-ний runtime, про який говорили раніше, присутній. "Свій" С++-ний runtime не додаємо --- цим займається libsupc++.

Пробуємо компілювати. Халяви немає -- купа помилок.

Retargetable printf з CoIDE та порівняння розмірів ROM/RAM для різних способів виводу

Ілюстрація з Вікі до
теми саморобок (DIY)

В попередньому пості було розглянуто, як забезпечити мінімалістичну підтримку стандартної бібліотеки С для мікроконтролерів сімейства STM32F1, (для контролерів інших сімейств, крім, власне, особливостей SemiHosting, відмінності будуть мінімальними, якщо взагалі будуть), працюючи з-під CoIDE. Однак, повноцінна підтримка цієї бібліотеки не завжди потрібна, а витрати пам'яті програм та RAM її printf(), в деяких ситуаціях можуть бути неприйнятними. На такий випадок CoIDE пропонує ще один варіант -- скористатися урізаною, мініатюрною реалізацією, яку воно називає Retargetable printf (Retarget_printf). (Взагалі, всі такі бібліотеки, де реалізувавши пару-другу функцій, можна "перенацілити" на роботу із іншим залізом, називають retargetable.)

Подивимося, що вона вміє, для чого може бути і як її подружити із SemiHosting --- виведенням повідомлень із використанням дебаггера.

Стандартна бібліотека C та SemiHosting (на прикладі STM32 і CoIDE)

Роль LibC в Linux. Зауважте, що
glibc надає значно більше інструментів,
ніж стандартна бібліотека С -- зокрема,
засоби POSIX. Нижче мови про них не буде.
(c) wiki

В попередньому пості було показано, як викристовувати CoIDE, програмуючи мікроконтролери (на прикладі плати STM32VLDiscovery). Розглянемо тепер, деякі загальні практичні питання програмування із використанням С. (В порівнянні із давнішими попередніми (1, 2) постами, тут більше подробиць, виправлено деякі помилки, і т.д.)

Увага (як часто буває в  embedded!), багато що із написаного нижче дуже сильно прив'язано до особливостей конкретного компілятора, GCC та конкретних його версій! Про Keil, можливо, колись напишу окремо. З іншого боку, особливої прив'язки до IDE немає, CoIDE згадується лише як конкретний приклад, котру галочку в котрому меню слід поставити для досягнення якогось результату. Розгляд ведеться для ARM-GCC 4.8 та 4.9, для новіших чи старіших версій можуть бути відмінності.

Стандартна бібліотека C

CoIDE 2

Давненько я про CoIDE не писав. Воно потроху розвивався, виходили нові версії, фіксилися старі баги, вносилися нові. З'явилася підтримка STM32F3 -- тих, що в STM32F3Discovery, з'явилася, в значній мірі -- формальна (див. наступні пости) підтримка C++. Остання доступна версія - 1.7.8. Однак, попередні рік-два, не зважаючи на вихід згаданої 1.7.8, основні зусилля були зосереджені на новій версії, CoIDE-2. Перші його випуски видалися мені претензійним, але мало-юзабельним. Однак, минав час, випала нагода з ним знову попрацювати, і виявилося, що версія 2.0.3, все ще бета, але вже цілком придатна для повсякденної роботи. 

Так як і в самому CoIDE, і в CMSIS (*) з часу попередніх постів ("CooCox CoIDE [1.5.1]", "CoIDE 1.7.1"), багато що змінилося, вирішив написати знову. Спочатку планувався один пост, потім він переріс у цілу серію, але, як би там не було, серія ця запланована як незалежна від попередніх матеріалів, але абсолютної гарантії не дам -- у них може бути щось важливе, що я забув згадати тут. Буду вдячний за bug-report-и. :-)

(*) CMSIS -- "стандартна бібліотека" для ARM-івських контролерів, основу якої, для спільного у всіх них ядра, випускає ARM Inc, а кожен розробник конкретних мікроконтролерів доповнює підтримкою своїх "фіч" --- реалізованих ними периферійних засобів та можливостей, див [1], [2].

CoIDE 1.7.1

З часу попередньої статті китайці випустили декілька оновлень свого славного CoIDE. Сказати, стала оболонка кращою чи гіршою, мені складно -- там такий мікс дрібних приємностей і дрібних косяків... :-) Але трішки по іншому стало точно. 

Спробую розповісти, як робота із CoIDE виглядає зараз. Версія, яку розглядав раніше -- 1.5.1, поточна -- 1.7.1. Багато відсилатимуся до попередньої статті -- щоб не повторюватися, хоча дрібні шматки просто цитуватиму. Розглядатимемо на прикладі плати STM32VLDiscovey. Тут, власне, сидить головне розчарування від останніх релізів. Ні підтримки STM32F3 (включаючи STM32F3Discovery), ні підтримки Stellaris (включаючи Stellaris Launchpad), поки так і не з'явилося. В принципі, принаймні STM32F3, можна пробувати додати самому -- див. діалог на форумі, "STM32F3Discovery - Demo Project for CoIDE", але я поки не пробував. Декілька слів буде і про прикручування C++.

[Update від листопаду 2015 року. Частина, присвячена С (Newlib) та С++ runtime містить багато неточностей та помилок. Існує більш детальний та точний варіант: "Стандартна бібліотека C та SemiHosting (на прикладі STM32 і CoIDE)" і "C++ із ARM GCC + STM32 (+ CoIDE)", відповідно. Крім того, див. пост про нову версію CoIDE, 2.0.3 beta: "CoIDE 2".] 

CooCox CoIDE

Про оболонку CoIDE від CooCox вже згадувалося у попередньому пості. Вона проста та зручна, і вартує уваги, особливо для початківців у роботі з контролерами ARM Cortex-M. Поміж недоліків -- "Windows only", відсутність підтримки C++ "з коробки", при чому останнє легко виправити (хоча б частково).

Думаю, варто розповісти про неї детальніше. Щоправда, базові аспекти роботи, з одного боку, менш-більш інтуїтивні, з іншого, описані:

• Частина статті "STM32: Урок 1 - Настраиваем IDE" від Robocraft. В основному вона про підготовку власного середовища на базі Eclipse, але зачіпає і роботу з CoIDE. Навіть якщо поки що самостійно "збирати" середовище не планується, варто її прочитати, щоб краще розуміти механізми роботи IDE, їх взаємодію з компілятором та програматорами
• "Необходимый софт" від EasySTM32 -- налаштування і робота з CoIDE. Створення проекту, компіляція, прошивка

Тому нижче зосереджуся на деяких нюансах -- прикручування підтримки С++, робота із репозиторієм,  всілякі дрібні потенційні "граблі". Розглядаю CoIDE останньої,  на момент написання, версії, 1.5.1.

[Update від листопаду 2015 року. Частина, присвячена С (Newlib) та С++ runtime містить багато неточностей та помилок. Існує більш детальний та точний варіант: "Стандартна бібліотека C та SemiHosting (на прикладі STM32 і CoIDE)" і "C++ із ARM GCC + STM32 (+ CoIDE)", відповідно. Крім того, див. пост про нову версію CoIDE, 2.0.3 beta: "CoIDE 2".]