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].

Інсталяція

На інсталяції особливо не зупинятимуся -- вона менш-більш типова, крім того, добре описана (ще й в картинках) у документації: "Download and Install CoIDE". Коротко:

• Завантажити IDE можна за посиланням на головній сторінці проекту. Перш ніж перейти до завантаження, потрібно зареєструватися, але реєстрація проста, а CoIDE повністю безкоштовних. [Хоча в Інтернет і лазить постійно, в основному до репозиторію звертаючись, але будемо сподіватися, що авторам оболонки не весь наш код відсилає. :-)]
• Інсталяція, в значній мірі, зводиться до натискання "next", але див. згадану "Download and Install CoIDE". Ніяких пробілів чи кирилиці у повному шляху!
•  Крім самого середовища потрібен компілятор. Орієнтуємося, як і автори середовища, на ARM GCC 4.9 (опис див. тут). Завантажуємо версію для Windows ( gcc-arm-none-eabi-4_9-<дата>-win32.zip), розархівовуємо за шляхом, котрий не містить пробілів та кирилиці. (Взагалі, хороше правило для всіляких інструментів програмерських!)
• Запустивши середовище, вибираєте пункт "Select Toolchain path" із меню Project,  та вказуєте місце, де лежать програми компілятора (типу arm-none-eabi-gcc.exe ). Зазвичай, це буде піддиректорія bin того місця, куди розархівували компілятор. Все. Але див. також "09.01 Select Toolchain" офіційної документації.

 eabi в назві архіву компілятора -- абревіатура від Embedded Application Binary Interface -- бінарний інтерфейс вбудовуваних програм ("офіційно" слово Application перекладають як застосунки, але за цього життя я їх так називати не планую).

Середовище готове до роботи. Воно використовує наступні шляхи (крім першого, вибраного мною вручну, такі -- за замовчуванням):

• C:\CooCox\CoIDE_V2Beta -- сама програма
• C:\Users\%USERNAME%\CoIDE\workspace -- директорія за замовчуванням для проектів користувача. (Рідко нею користуюся -- надаю перевагу, щоб проекти CoIDE лежали у директоріях, присвячених відповідним продуктам/проектам -- програмні продукти, крім власне коду, включають багато ще чого).
• C:\Users\%USERNAME%\Appdata\Roaming\CooCox\CoIDE -- директорія для тимчасових файлів, завантажених компонент, конфігурації і т.д. Іноді може бути корисним заглянути до неї.

Створення проекту

Працюватимемо із все тією ж STM32VLDiscovery (див. також більш ранній текст "Огляд STM32 (ARM Cortex-M від STMicroelectronics)"). 

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

1. Запускаємо середовище. Вибираємо "Create a New Project":

2. Перед нами, із певною затримкою (що поробиш, Java, та ще й в Інет лізе), постає Репозиторій. Там можна вибрати конкретний мікроконтролер (скроллінг працює, хоч скроллбара поки немає):

Спочатку обираємо компанію-виробника, ST, потім сімейство --- STM32F100, потім конкретну модель, STM32F100RBT6B. Можна, також, скористатися пошуком. Клікаємо по контролеру, вискакує ось таке віконечко:

Вибираємо New Project.

3. Середовище пропонує задати назву проекту. Це буде також назвою директорії, тому -- ніяких пробілів чи кирилиці!

Є можливість обрати директорію проектів, відмінну від типової, для цього слід спершу забрати галочку із "Use default path".

4. З'являється вікно репозиторію. Ліворуч видно щойно створений проект, який поки складається із одного файлу, main.c -- проект, за замовчуванням, С-ний. (Про С++ поговоримо трохи пізніше).

Обираємо необхідні компоненти. Пам'ятайте, що бере воно їх з Інтернету, з централізованого репозиторію! А значить, потрібна наявність Інету.

Для обраного контролера доступно 12 пунктів для "On-chip Peripherals" та 5 в розділі "Drivers".

Додати компоненту можна, натиснувши кнопочку "Add" із зеленим плюсиком. Забрати після того -- "Remove" із червоним мінусом. Після натискання "Add" бачимо:

Щоб повернутися назад, до списку, тиснемо "On-chip Peripherals". Інший спосіб повернутися назад -- натиснути "Backspace": вікно репозиторія веде себе як браузер (в тому числі, без проблем блукаючи Інтернетом, а сторінку компонент видно і в звичайному браузері). Можливість навігації за гіперпосиланнями зручна, іноді незамінна -- середовище все ще трохи сире, але слід користуватися нею обережно -- можна заблукати! Наприклад, воно може "забути", для якого контролера вибирає компоненти.

Натиснувши на назві компоненти, можна перейти до її детального опису (див. рис. нижче). Зроблено воно трохи кривувато, але можливість корисна. Також, під назвою може бути короткий опис.

Як видно, також є можливість зробити свою гілку компоненти (Fork), додати до своєї онлайн-колекції, тощо.

Якщо компонента залежить від інших, при її додаванні, їх теж буде додано. (Але видалення не видалятиме автоматично компоненти, залежні від даної, чи, тим більше, автоматично додані для її потреб. В не дуже вилизаній системі це, швидше, перевага.)
 
На відміну від CoIDE 1.x.x, якщо додати компоненту, змінити її файл(и), потім видалити і знову додати -- змінені файли зберігаються. (Як змінювати файли, що належать компонентам -- див. нижче. По замовчуванню вони захищені від запису.)

5. Розібравшись, як керувати компонентами, слід визначитися, а які компоненти взагалі потрібні. Список по замовчуванню (безпосередньо зараз -- може змінюватися!), містить наступне:

• C_library -- реалізації-заглушки мінімального комплекту функцій, необхідних для компіляції реалізації стандартної бібліотеки С, що використовується ARM GCC, Newlib. Про них ще буде розмова далі. Попередньо: іноді -- потрібна річ.
• cmsis_core -- власне, CMSIS, яка згадувалася вище.
• CooCox_CoOS -- вбудовувана операційна система реального часу (Embedded RTOS) від авторів CoIDE. Детальніше див. тут.
• Cox_Interface -- портабельна бібліотека для ARM-ів, від авторів CoIDE. Підтримуються мікроконтролери Nuvoton, NXP, ST (STM32F1/2/3/4/0!), TI (Stellaris/TM4C), Holtek, FreeScale, Atmel. Взагалі, виглядає цікавою, але складно сказати, наскільки перспективна...
• Явно зайві в цьому списку M0518_Series_BSP_CMSIS, NUC029xAN, NUC505, які стосуються інших контролерів. (Будьте готові, що таке буває!).
• Retarget_printf -- компактна реалізація printf, яку можна змусити працювати із різними джерелами-отримувачами літер -- UART, SemiHosting, etc. Конфліктуватиме із libC, звичайно. Подробиці -- в наступних постах.
• Semihosting -- реалізація GetChar/SendChar (назви очевидні) із використанням  Semihosting, технології обміну інформації між контролером та дебаггером. 
• STM32F10x_HD_VL_STDLIB/STM32F10x_LD_VL_STDLIB/STM32F10x_MD_VL_STDLIB -- різні варіанти Standard Peripherals Library, SPL --- спроба ST надати вищий рівень абстракції, ніж CMSIS із її вознею з окремим регістрами. Спроба не те щоб аж дуже вдала, але іноді корисна. Кілька слів про неї із посиланнями на подальші джерела, див. тут: "Огляд STM32 (ARM Cortex-M від STMicroelectronics)". Зауважу, що з того часу ST випустила і потроху доводить до ладу більш приємну спробу, HAL, про неї буде окремий пост. Залишається питання -- чому їх три? Справа в тому, що контролери STM32 випускаються в декількох варіаціях: Value line(High, Medium and Low), Connectivity line, XL-, High-, Medium-, Low- Density Devices. Наприклад, згаданий STM32F100RBT6B -- Value Line Medium Density пристрій, MD_VL, іншими словами.

Крім того, розділ Drivers теж містить цікаві речі -- рекомендую заглянути у нього, однак вони занадто далеко відволічуть від основної теми поста, тому тут не обговорюватимемо.

Якщо не бути мінімалістом, для роботи нам буде потрібно cmsis_core,
STM32F10x_MD_VL_STDLIB, Semihosting  та C_library (в наступних постах ми її покращимо) або Retarget_printf. Додаємо їх.


Забігаючи наперед, кілька слів про те, як повернутися до репозиторію. Навіть коли працювати із іншими вкладками, вкладка Repository залишається. Однак, якщо її закрити, очевидного способу її повернути я не знайшов. Можливо ще виправлять, або просто я неуважний. Поки використовую наступний трюк -- Help/Welcome відкриє вкладку, яку ми бачили в п.1, там можна клікнути по "Browse in Repository".

Проект готовий -- можна починати роботу.

Робота із проектом 

Почнемо із базових операцій.

Компіляція: Project --> Build, відповідна іконка в тулбарі, або просто F7.

Прошивка в контролер: "Flash"-->"Program download", або відповідна іконка.

Якщо програматор підтримує (ST-Link-и на платах STM32xxx Discovery підтримують), працює і відладка -- breakpoint-и, покрокове виконання, перегляд змінних, тощо.

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

Опис основних елементів рисунку вище: 

1. Компіляція.
2. Відладка.
3. Запис прошивки у контролер.
4. Структури проекту.
5. Компоненти, підключені до проекту.
6. Файли, що належать компонентам, редагувати заборонено. Про це  повідомляє іконка-замочок. Так як іноді їх редагувати таки треба, як той же, відмічений syscalls.c, шукав спосіб дозволити. Єдиний, який знайшов -- перетягнути файл із папки components:
   
   Як не дивно, коли видалити відповідний компонент, файл із списку пропадає, але фізично залишається, коли додати компонент знову -- зміни зберігалася. АЛЕ! Не покладайтеся на це!
   
7. Вікно Welcome, з якого можна, наприклад, добратися до репозиторію.
8. Вкладка репозиторію.
9. Вкладка конфігурації -- про неї детальніше нижче.
10. Файл із кодом програми.
11. Повідомлення про помилки та попередження компіляції.
12. Неопрацьований (сирий) вивід компілятора та інших інструментів. Часто -- дуже корисна інформація.
13. Результат компіляції.

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

Конфігурація проекту

Відкрити вкладку конфігурації можна в контекстному меню проекту (спосіб доступу від версії до версії блукає, але тут ця вкладка була, здається, завжди).

Виглядає вона так:

Видно, що має свої вкладки. Перша, яка зразу активна -- Compile. У ній, знову ж таки, є вкладки третього рівня -- Basic settings i Advanced Settings.

Basic settings  включають:

• Математичний сопроцесор --- Floating Point Unit, FPU. Даний контролер його немає, тому поле не активне.
• Оптимізація -- достатньо очевидно, але на список варіантів подивіться.
• Debug, зневадження -- про те, наскільки детально зберігати інформацію для зневадежння (відладки).
• Warnign --- керування попередженнями під час компіляції. Варто залишити як є -- не слід в коді залишати місця, які викликають попередження. На крайній випадок, окремі класи попереджень можна вимкнути, скориставшись Advanced Settings. 
• Includepaths -- шляхи до файлів заголовків (headers), те що потраплятиме опції -I.
• Defined Symbols -- наперед визначені макроси препроцесора, те що створюється опцією компілятора -D. По замовчуванню створюється один, зараз це STM32F100RBT6B --- версія мікроконтролера.
• Внизу є дуже цінна компонента, Compiler Control string --- повний список опцій, що будуть передані компілятору в результаті чаклування із засобами керування вище. 

Кому як, а мені, дивлячись на  Advanced Settings, в першу чергу кидаються у вічі незвичні кнопки. Чи то я так від життя відстав? -- десь я вже схожі бачив... :-) Ліве їх положення -- вимкнено, праве -- ввімкнуто, при тому зразу змінюється і їх колір --- вони ніби підсвічуються.

Щоб побачити, які опції додано до виклику компілятора, доведеться повертатися до Basic settings  -- тут Compiler Control string не дублюється.

• "Use ‘-std=c90’ In C mode, use ‘-std=c++98’ In C++ mode"  -- думаю, очевидно.
• Крім того, внизу є два списки, "Specify the C standard" та "Specify the C++ standard", які дозволяють вибрати версію стандарту: С90/С99/С11/gnu90/gnu99/gnu11 для C та C++98/C++1/gnu++98/gnu++11 для С++, де gnu означає використання нестандартних розширень GCC (чого ми, звичайно, намагатимемося уникати).
• C++ Optimizate включає опції керування генерацією коду:
• "Disable generation of information about every class with virtual functions for use by the C++ run-time type identification features" -- фактично, заборонити використання RTTI, (-fno-rtti).
• "Do not emit the extra code to use the routines specified in the C++ ABI for thread-safe initialization of local statics" -- заборонити безпечну щодо потоків ініціалізацію статичних об'єктів, (-fno-threadsafe-statics).
• "Disable exceptions" -- заборонити виключення, (-fno-exceptions). 
• "Don’t generate code to check for violation of exception specifications at run time." -- заборонити перевірку специфікації виключень (ті що throw(...), яку, anyway визнано застарілою та не рекомендованою в C++11, опція -fno-enforce-eh-specs).
• "Disable diagnostics that the standard says a compiler does not need to issue." -- заборонити компілятору друкувати необов'язкові попередження,  (-fno-optional-diags).
• "This switch declares that the user does not attempt to compare pointers to inline functions or methods where the addresses of the two functions are taken in different shared objects." Подробиці див., наприклад, тут: "Why is the new C++ visibility support so useful?", (-fvisibility-inlines-hidden).
• Нарешті, Misc Controls дозволяє вказувати довільні опції компілятора.

Хоча, не зважаючи на популярну забобону, С++ є цілком корисним і на мікроконтролерах (а за мінімальної акуратності нічим не програє коду на чистому С, іноді виграючи у нього!), однак, такі речі, як виключення та RTTI достатньо важкі, вимагають складної підтримки часу виконання (runtime) і для контролерів створюють більше проблем, ніж вирішують. Тому, в типовому випадку, варто їх заборонити. Якщо не планується реалізовувати багатопоточність (знову ж таки, runtime її не підтримує на голому залізі), те ж варто зробити і з пунктом про підтримку безпечної багатопоточної ініціалізації статичних об'єктів.

Іншою дуже важливою вкладкою є Link --- керування зв'язуванням/компонуванням коду.

Вона теж має дві вкладки, Basic settings i Advanced Settings, але Advanced  містить лише стрічку для введення опцій для лінкера вручну, тому на ній не зупинятимемося.

• "Use Memory Layout form Memory Window" --- використовує карту пам'яті, введену у полі нижче, з іменем "Memory Areas". Якщо вимкнено, використовується скрипт лінкера, заданий в полі "Scatter File". Коли вперше створювати цей скрипт, середовище заповнює його значеннями по замовчуванню, що відповідають карті пам'яті.
• "Discard unused sections" --- інструкція для лінкера викидати секції, які не використовуються. Корисна річ, в більшості випадків -- розмір пам'яті програм (флеш-пам'яті), все ж, доволі обмежений.
• "Don't use standard system startup files" -- власне, воно. Забороняє підключати всілякі файли типу crt0.o. Див. також "Mini FAQ about the misc libc/gcc crt files" та "crt0.o and crt1.o — What's the difference?", (див. також наступні пости).
• Library дозволяє вибрати, яку реалізацію стандартної бібліотеки використовувати, (див. наступні пости).
• Linked Libraries, праворуч, дозволяє додати зовнішні бібліотеки.
• "Debug in Flsh"/"Debug in RAM" -- перемикання між використанням для відлагодження коду пам'яті програм (flash) чи оперативної пам'яті (RAM). Останнє може використовуватися для прискорення процесу заливки та зменшення зношування флешу.
• Нарешті,  "Scatter File" дозволяє вручну задати скрипт для лінкера -- на противагу згенерованого автоматично. До цієї можливості ми ще повернемося, коли мова йтиме про С++.
• А ось опція LTO --- Link Time Optimization десь пропала...(Хоча, в файлі проекту відповідний пункт залишається, графічний інтерфейс до нього доступу не надає.) Ввімкнути цю опцію просто вручну -- слід додати опцію "-flto" як на вкладці Advanced для компілятора, так і для лінкера.

Важливим є вибір стандартної бібліотеки С:

По порядку:

• "Не використовувати стандарту бібліотеку C".
• "Використовувати nano C", компактну модифікацію Newlib, від розробників ARM GCC, яку вони називають Newlib-nano. Якщо вибрати її, можна додатково підключити підтримку роботи із числами з рухомою крапкою: Printf float та Scanf float, які по замовчуванню викинуто.
• "Використанням звичайної Newlib libc".
• "Використовувати лише підтримку Semihosting". Деякі подробиці, що ж це таке за опція, див., наприклад, тут.
• "Використовувати лише "перенацілювану", компактну, реалізацію printf". Перенацілюваною її називають тому, що реалізувавши функцію PrintChar(), можна виводити куди завгодно. Для інших реалізації цю ж роль виконують функції із компоненти C_library, про яку йшла мова вище (файл syscalls.c, про який теж буде окрема розмова).  

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

Вкладка User дозволяє задати код для виконання перед і після компіляції. Опечатки цікаві. :-)

Наступна вкладка --- Debugger:

На рисунку показано цілком прийнятні значення по замовчуванню для STM32VLDiscovery.

• Adapter --- програматор, що використовується. STM32VLDiscovery містить в собі ST-Link. Port -- SWD, частота --- 1МГц, хоча цілком можна використовувати і 2МГц.
• Run to main --- під час запуску виконувати код ініціалізації, не зупиняючись, аж до початку main().
• Reset Mode: SYSRESETREQ. Для цієї плати можна не змінювати. (SYSRESETREQ -- запит до схем мікроконтролера виконати Reset, VECTRESET -- перезавантажити ядро мікроконтролера (крім підсистеми відладки), не чіпаючи периферії, HW RESET -- перевантаження вручну, натисканням кнопки).
• Якщо планується використовувати Semihosting, слід його дозволити! По замовчуванню --- вимкнена. В старіших версіях CoIDE ця опція мала звичку самовільно вимикатися. 2.0 такого собі не дозволяло, але тримайте на контролі. 
• Про решту промовчу -- отак сходу подробиць не знаю, що автори оболонки під ними мають на увазі, а потреби розбиратися не було поки...

Остання по порядку, але дуже важлива вкладка --- Download, керування заливкою прошивки у контролер:

• Auto Download Before Debugging --- власне, воно -- при запуску відладки, заливати найсвіжішу прошивку. Правда, не забудьте скомпілювати перед тим! Останні версії CoIDE скомпілюють автоматично, але якщо компіляція провалиться -- будуть сюрпризи.
• Verify After Download --- перевіряти після запису у флеш.
• Erase --- режим стирання, всю пам'ять, тільки ту, куди відбуватиметься запис, не стирати (не рекомендується!).
• Programming Algorithm --- файлик із алгоритмом програмування. Якщо все під'єднано, а прошивка не записується --- перевірте, що тут. Середовище іноді "забуває" вказати правильний файл. Обрати вручну його нескладно. Наприклад, зараз це <userfolder>\AppData\Roaming\CooCox\CoIDE\config\flash\CooCox-Flash\CoIDE_STM32F1xx_MD_128K\STM32F10x_MD_128.elf -- контролер сімейства STM32F1xx, 128Kb флеш-пам'яті, а конкретніше --- STM32F10x_MD_128, тобто, уточнено, що не просто F1xx, a F10x, Medium Dencity. 

Отож, із середовищем сяк-так розібралися. Воно місцями неохайне, але, на загал, зручне і просте у використанні. Для початківців -- саме те, що треба. Звичайно, розглянуто далеко не всі його можливості. Наприклад, воно вміє давати підказки по регістрам:

Та й робота із відладчиком є не зовсім тривіальною:

Тому -- є сенс експериментувати. Офіційна документація знаходиться тут: "coide-dev-manual.en".

Власний скрипт лінкера

Можливо, в наступних версіях проблему, про яку мова нижче, буде усунуто, але станом на версію 2.0.3 beta вона присутня, тому опишу, як боровся -- на жаль, вирішення не було тривіальним.

Коли на вкладці Configuration->Link вимкнути "Use memory layout from main window", з'явиться можливість вказати свій скрипт лінкера, в полі Scatter file.

Однак, не все так просто. Там порожньо, якщо натиснути Edit, середовище створить та відкриє відповідний файл, але знаходитиметься він десь тут: c:/users/<username>/appdata/roaming/coocox/coide/configuration/programdata/hello_cpp_02/arm-gcc-link.ld --- аж ніяк не в директорії проекту. Крім того, хоч і не кожен раз, при перезапуску середовища іноді його стиратиме.

Після серії експериментів, прийшов до наступної, потворної, але дієвої, послідовності дій:

• Вимикаю "Use memory layout from main window", тисну "Edit". 
• Копіюю отриманий файл в директорію проекту (наприклад, ./app, де лежать *.c та *.cpp файли).
• Натискаю три крапочки, ліворуч від Edit, щоб обрати саме цей файл. 
• Додаю його до проекту. (При тому воно каже, що файл вже існує, питається, чи його перезаписати. Підтверджую. Здається, воно копіює із згаданої директорії в c:/users, але без попереднього кроку іноді себе дивно веде.) Потрібно це, щоб після зміни цього файлу відбувалася перекомпіляція. 
• І ось тут стає зовсім весело. В більшості випадків (!бета, блін!), Configuration зразу забуває всі зміни. Закриваєш вкладку, відкриваєш -- все по старому. Після багатьох спроб дійти толку з GUI, змушений був редагувати файл проекту вручну. Закриваємо CoIDE 2, відкриваємо в текстовому редакторі <projectname>\<projectname>.coproj, робимо у ньому наступне (вказую лише змінені рядки, шукати їх можна по значенню поля name): 

        <Option name="UserEditLinkder" value="app/arm-gcc-link.ld"/>
        <Option name="UseMemoryLayout" value="0"/>
Зберігаємо, перезапускаємо середовище. Що цікаво, після цього працювати із конфігурацією можна безпечно -- налаштування більше так просто не губляться.

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

Інші заскоки, заморочки та "фічі" CoIDE

Крім описаної вище проблеми із власними скриптами лінкера, середовище має й інші нюанси в роботі.

• Перейменування файлу засобами середовища змінює лише його відображення в середовищі, фізичне ім'я залишається тим же. Тому, зокрема, навіть якщо в середовищі ви перейменували file.c в file.cpp, на диску він залишиться як .с, і компілюватиметься gcc як С-файл а не С++-файл. Тому типова послідовність перейменування -- видалити з проекту, перейменувати на диску, додати до проекту.
• Перетягування файлу із групи компоненти дозволяє його редагувати, але при тому фізично  файл залишається на місці.

До речі, на офіційному сайті є величезний список компаній та корпорацій, для яких виробник CoIDE є офіційним партнером. Поміж них і STMicroelectronics.


Наступним постом ще раз подивимося на libc/printf/semihosting. А поки все ---

Дякую за увагу!