Средства и методы разработки

системную

консоль, принтер и даже тупо в нуль. тут вспоминается легкая ржака - у мелкософта была версия Windows Fundamentals for Legacy PCs в которой искаропки был выпилен драйвер dev/null - Null.sys. можно вспомнить консольную отправку данных в тот же ком-порт, при этом в той же винде команду mode... а в лялихе ком-порт это и системный выхлоп (со своими настройками, в т.ч. скорости) и стандартный вывод для запущенной программы, и, если в программе используется выхлоп именно в тот же ком-порт, то оно тоже функционирует, но её настройки для скорости перебиваются при следующем попавшемся системном выхлопе... дебаг это дебаг (причем в таргете релиз по правилам хорошего тона он должен отключаться - рулёжка с одиноким системным printf это ещё тот секас), а правильный дебажный выхлоп должен оказывать минимальное влияние на <i>пользовательскую </i>задачу и жрать ресурсы не на все денньги. смешивание же системного и пользовательского отношу к "детской болезни левизны"(С). в примерах от вас ниже есть вариант с маллоком, за который в большинстве случаев я бы бил ногами по рукам, и варианты с тем или иным статическим буфером и предпочтительным использованием snprintf - сильно не рассматривал, но отвращение не нападало. КМК, использование SWO, RTT и подобных быстрых механизмов со всякими debug_printf не только освобождает ресурсы UART и DMA (хоть вам, похоже, их и не было жалко), но и "воспитывает" в плане отделения мух от котлет - системного от пользовательского.