Лучше не использовать типы char в stm32?

[Marlin Boardley]

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

[Eddy_Em]

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

[es131245]

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

[Dimon456]

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

[Eddy_Em]

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

[Dimon456]

Некоторые кривые реализации вообще чуть ли не 2кБ отжирают!

Это еще мало.

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

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

[COKPOWEHEU]

printf - очень жирная фиговина.

Для отладки можно. Быстрее нагородить форматный вывод в UART, чем в 100500-й раз реализовывать вывод в захардкоженном формате.
А в случае сложного обмена по тому же UART'у даже и в финальной версии может быть опревдано.

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

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

чтобы отобразить и прочитать вот так? Как на рисунке.

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

Код: Выделить всё

UART_puts("ID OCT-");
UART_write(&str[18], 5);

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

Код: Выделить всё

UART_puts("ID OCT-");
str[23] = 0; //терминирующий ноль
UART_puts(&str[18]);

Некоторые кривые реализации вообще чуть ли не 2кБ отжирают!

Это еще мало.

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

[Eddy_Em]

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

[Dimon456]

Что до печати HEX

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

[Eddy_Em]

[uquote="Dimon456",url="/forum/viewtopic.php?p=4105652#p4105652"]Повторяю, у ТС Raspberry Pi pico.[/uquote]
Не заметил. Но если у ТС - "пика", то почему он в заголовке о STM32 говорит?
Но все равно если есть возможность сэкономить, лучше сэкономить. Зачем уподобляться всяким "разработчикам" под андроиды и гейфы, да "веб-погромистам", которые настолько ленивы, что считают, раз есть дофига оперативы, можно и не оптимизировать ничего. А если оперативы не хватает, пусть пользователь новую модель покупает!

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

[tonyk]

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

int printf( const char*, .. );

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

[COKPOWEHEU]

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4105567#p4105567"]Что до печати HEX, то это легко делается самостоятельно, как-то так.[/uquote]
Это никак не отменяет, что написать sprintf для отладки быстрее, чем искать в каком же исходнике ты это в последний раз писал или писать заново с нуля.
Кстати, мне после AVR не нравится сдвиг на (4*j), лучше бы исходное число двигать, как в выводе десятичного:

Код: Выделить всё

do{
  uint8_t temp = val & 0xFF;
  buf[1] = temp & 0x0F;
  if(buf[1] < 10)buf[1] += '0'; else buf[1] = buf[1] - 0x0A + 'A';
  buf[0] = temp >> 4;
  if(buf[0] < 10)buf[0] += '0'; else buf[0] = buf[0] - 0x0A + 'A';
  buf -= 2;
  val >>= 8; //не все контроллеры любят сдвиг на нецелое число, поэтому сдвигаем на байт
}while(val);

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

Код: Выделить всё

do{
  buf[0] = val % base;
  if(buf[0] < 10)buf[0] += '0'; else buf[0] = buf[0] - 0x0A + 'A';
  buf--;
  val /= base;
}while(val);

[parovoZZ]

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4105671#p4105671"][uquote="Dimon456",url="/forum/viewtopic.php?p=4105652#p4105652"]Повторяю, у ТС Raspberry Pi pico.[/uquote]
Не заметил. Но если у ТС - "пика", то почему он в заголовке о STM32 говорит?[/uquote]
и там и там cortex. так какая разница?

[Eddy_Em]

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

[parovoZZ]

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

[Dimon456]

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

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

Вернемся к первоначальному вопросу

Лучше ли не использовать типы char в программировании stm32

По чему нельзя использовать?

если вы хотите прочитать что-то из 24c02, лучше не использовать %c

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

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

[Eddy_Em]

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

Код: Выделить всё

printf("%10.3f\n", f);

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

[Dimon456]

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

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

Лучше ли не использовать типы char в программировании stm32 или embedded?

[Eddy_Em]

[uquote="Dimon456",url="/forum/viewtopic.php?p=4106167#p4106167"]А ардуинщики что-то смело f используют и на МК без FPU.[/uquote]
Абдуринщики, "аудиофилы", антипрививочники, ЛГБТ и т.п. — просто разные последствия повреждения головного мозга.

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

[Dimon456]

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