Форум arduino.ua

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

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

Як сказано вище, у вас чомусь дві бібліотеки, що надають Control_Surface.h. Що таке Control-Surface-main?
Як ви встановлювали Control_Surface? Яку версію?

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

Та наче і Legacy IDE, і 2.x IDE використовують один і той же тулчейн з gcc 7.3.0.

Щойно перевірив: в Arduino IDE 1.8.19 приклад "3. MIDI Interfaces/USBMIDI-Adapter" з Control_Surface версії 2.1.0 компілюється успішно для UNO, якщо замінити "midi_ser {Serial1}" на "midi_ser {Serial}". Але це ніяк не повʼязано з помилкою, що вилазить у автора.

Припускаю, що автор багато років не оновлював тулчейн, і там ще якийсь 5.x. Але це не точно. Потрібно бачити лог компіляції.

Ну, блоби фірмварі зараз багато де завантажуються: на GPU, на аудіочіпах, на мережевих адаптерах. Але що в ESP32 воно прямо на одному з ядер виконується, не знав. Не розумію таких рішень.

100%

Ні, не памʼятаю такого в своїй біографії)

Therac-25? Якраз після того інциденту вимоги до сертифікації в мед.індустрії були переглянуті та суттєво посилені.

Яка там у автора мотивація використовувати STM32 і RTOS для цієї задачі - то не моя справа) Я про загальну тенденцію в індустрії, де "не влазить в STM32F103 - візми STM32F411", бо так виходить дешевше.

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

Можна відмовитись від ардуіно фреймворка і збирати прямо з FreeRTOS. Звісно, бібліотеки, що використовують ардуіно-специфічні API, доведеться або адаптувати, або замінити, або реалізувати самому.

Жирне воно буде в будь-якому разі. 32 кілобайта на 32-бітній архітектурі - це не ті ж 32 кілобайта на 8-бітній.   

Доречі, хіба у 1602 дисплея рідний інтерфейс - I2C? Там же мабуть HD44780 і екстендер типу PCF8574. Якщо підключити через рідний інтерфейс, то не потрібно ні Wire, ні I2C HAL. Датчик MAX6675 на SPI же наче б то.

Що у вас за конфігурація platformio?
Які саме ліби використовуєте?

Для термостата що там потрібно? Регулятор та примітивний UI. Не дуже розумію, навіщо там RTOS.

А objdump що показує? Окрім .text є ще секції .data та .rodata.

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

Їх може і який-небудь snprintf() притягнути.

Так це мабуть ардуінівська Wire. Вона дурна.
UPD: сама по собі HAL_I2C_EV_IRQHandler() в stm32f1xx_hal_i2c.c монструозна. Не розумію, навіщо імплементувати і master, і slave mode в одному місці одночасно.

З даташита Atmega328P:

Це якщо сконфігуровано для External Clock. Якщо сконфігуровано для кварца, то таке взагалі не передбачається.

Чисто теоретично, в повністю статичному МК (без DRAM, такому як AVR), якщо імпульси з правильними фронтами (з одного боку достатній slew rate, з іншого вищі гармоніки на допустимому рівні), то має працювати (ще питання по роботі АЦП та записі в EEPROM).
Але які там будуть імпульси, коли генерація ще не стабілізувалась? От перевищить амплітуда поріг на декілька наносекунд, один блок МК сприйме це за тактовий імпульс, а інший його пропустить, і все.
В деяких схемах ставлять D-тригер для поділу частоти кварца навпіл, це дещо підвищує стабільність, але не у всіх випадках.

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

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

Наприклад, у STM32 та деяких AVR є апаратний механізм Clock Failure Detection. У ESP32 такого не зустрічав. Може тому що розробники вирішили, що збій осциляції не є проблемою у сценаріях застосування ESP32, а може тому що стабільність забезпечуєься якимись іншими внутрішніми механізмами.
Brownout Detector наче б то є у всіх.

github.com/BruceDevices/firmware/issues  - тут уже дивились?

Флеш посипалась, усьо.
Воно-то може полежати і після стирання ще почати програмуватись, але я б на це не розраховував і цьому чіпу не довіряв.