Лучше ли не использовать типы char в программировании stm32 или embedded?
Например, если вы хотите прочитать что-то из 24c02, лучше не использовать %c, чтобы отобразить и прочитать вот так? Как на рисунке.

Мама дорогая! printf на микроконтроллере!..
Вы туда еще malloc запихайте ради полного "Щассья".

а почему не обычный массив uint8?
И функции принф тоже не особо нужны, кож можно написать и без них. Всего то пара циклов

Eddy_Em, а что не так с этим printf и malloc?

printf - очень жирная фиговина. Некоторые кривые реализации вообще чуть ли не 2кБ отжирают! А иметь сложный форматированный вывод на МК - блажь! Флоаты там нафиг не нужны, т.е. математика в основном целочисленная или с фиксированной точкой → сделать при необходимости форматированный вывод можно и самому, без этих килобайтов.
Что до алллокаторов памяти, то без MMU они нафиг не нужы, т.к. тоже через одно место делаются и вносят лишний оверхед.

Это еще мало.Ну на мега8 malloc занимает где-то 350 байт кода, и весь код охота уместить в 2кило кода в месте с таблицей на 3кило флеша, что бы еще места осталось.
Ну а на Raspberry Pi pico 264кб SRAM и 2 Мб встроенной флэш-памяти, да я б об этом и не волновался.

Для отладки можно. Быстрее нагородить форматный вывод в UART, чем в 100500-й раз реализовывать вывод в захардкоженном формате.
А в случае сложного обмена по тому же UART'у даже и в финальной версии может быть опревдано.
Как связаны аллокаторы и MMU? Распределением памяти программа занимается самостоятельно в виртуальном линейном пространстве. Доступа к MMU у нее нет.
---
Что с malloc, что с printf проблема не во флеше или аппаратных модулях, а в скорости и оперативке. Сколько времени уйдет на формирование строки по хитрому формату? Сколько памяти потребуется чтобы хранить служебную информацию malloc?

А "вот так" это вот как?
Если имеется в виду пять %c подряд, то я бы отладочную информацию выводил по-другому:

Но это у меня есть функция вывода в UART сырого массива. Можно через строковый вывод:


Для полноценной реализации примерно столько и уйдет. Вот только в контроллерах эта полноценная реализация нужна примерно никогда.

Кстати, я как-то видел еще и sscanf у ардуинщиков! Вот уж треш - так треш!..
Что до печати HEX, то это легко делается самостоятельно, как-то так.

если нужна только печать HEX, то, наверно, можно сэкономить 2 кило флеш с 2Мб, будет оправдано.
Повторяю, у ТС Raspberry Pi pico.

Не заметил. Но если у ТС - "пика", то почему он в заголовке о STM32 говорит?
Но все равно если есть возможность сэкономить, лучше сэкономить. Зачем уподобляться всяким "разработчикам" под андроиды и гейфы, да "веб-погромистам", которые настолько ленивы, что считают, раз есть дофига оперативы, можно и не оптимизировать ничего. А если оперативы не хватает, пусть пользователь новую модель покупает!

Копроэкономика в чистом виде.

Если есть вероятность переносить свою прогу на восьмибитные МК, то налетишь на то, что у printf нет форматного преобразования char для печати его как десятичного или шестнадцатеричного числа, поэтому тупо написать "%d" и передать char может закончиться печатью фигни, если не сделать явное приведение char к int. Тонкость в том, объявление этой функции в стандартной библиотеке как

int printf( const char*, .. );

напрочь отключает проверки соответствия формата выводимых чисел и фактически переданных, и, значит, к отсутствию сообщений об ошибках.
Сталкивался с таким в Кейле, в остальных компилятор нужно проверять.

Это никак не отменяет, что написать sprintf для отладки быстрее, чем искать в каком же исходнике ты это в последний раз писал или писать заново с нуля.
Кстати, мне после AVR не нравится сдвиг на (4*j), лучше бы исходное число двигать, как в выводе десятичного:

Или в более общем виде

и там и там cortex. так какая разница?

Разница огромная! У популярных STM32 нет FPU, нулевки даже делить не умеют.
Ну, это ваше дело, как МК использовать. Я не люблю, когда ядро чем-то слишком долго занимается. Ведь тогда приходится ломать КА, впихивая всякие некошерные прерывания!

а char и FPU как связаны?

Просто какая-то фантастика: одному делить не нравится, второму сдвиг не нравится ...

Я проект ARV DIGISCRIPT написанный и заточенный под 8 битную платформу AVR перенес на 32 битную платформу F100 и F030 без малейшей правки основного кода.
И все крутится и работает и сдвигается и делится.

Вернемся к первоначальному вопросу
По чему нельзя использовать?а ты, ТС, загнал туда, в 24c02, эти символы, что бы их потом прочитать, или, хотя бы терминал в HEX переключил?

printf нормально обрабатывается как там так и тут, все зависит от программиста.

При чем здесь char? Речь о printf. Особенно типа

Особенно, если f - double или даже float на МК без FPU!

А ардуинщики что-то смело f используют и на МК без FPU.

Вот когда речь будет идти о производительности вот тогда и поговорим, а пока вопрос ТС

Абдуринщики, "аудиофилы", антипрививочники, ЛГБТ и т.п. — просто разные последствия повреждения головного мозга.

Что до вопроса ТС, то вся проблема кроется в его непонимании. Как поймет, так и не будет глупых вопросов задавать. Если он хочет char отобразить как int, так пусть и вызывает printf("%d\n", c). А если ему беззнаковое целое нужно, то стоило вместо char сразу брать uint8_t…

Я бы не стал так отзываться о других, мы сами не лучше их, мы ни чего не создали чем можно было бы гордиться, пока что у нас получаются 1 Гигабатные браузеры и 50 Гигабатные игры. Так чем мы лучше их?