LINUX.ORG.RU

реализация printf/sprintf для MCU с поддержкой double

 , ,


0

1

Добрый день! Есть ли где ХОРОШАЯ реализация printf/sprintf для MCU. Требования 1) Бережное отношение к памяти. 2) Никакой динамики 3) бережное отношение к стеку. Не надо ширину вывода для %10d хранить в size_t. int8 вполне хватит. не надо по каждому чиху заводить переменную. 4) Понятно, нужна заточка для MCU (т.е. например, не писать в строку, а вызывать калбак итд) 5) Стандартные параметры форматирования. чтобы можно было прикрутить атрибут для проверки строки форматирования

★★★

Ты понимаешь, что printf/sprintf на микроконтроллерах — явный признак быдлокода? Такой же признак, как и комментарии на русском или тонны копипасты.

Никакой динамики

Какая может быть динамика без RTOS? Или ты сам решил написать свои sbrk/mmap?

int8 вполне хватит.

На 32-битном МК ты получишь выгоду от int8 только если впихаешь их в упакованную структуру, иначе int8 будет столько же места занимать, сколько int32.

Ну и, есличо, в glibc эта хрень есть. От тебя требуется лишь написать базовые функции (работа с файлами, памятью).

Eddy_Em ☆☆☆☆☆
()

Реализация в musl не выделяет память и вызывает функцию вывода. Без понятия за другие реализации, просто исходники этой смотрел, может выйдёт переделать. Так как код там слабо читаемый, то вероятно они на чём-то экономят :)

xaizek ★★★★★
()
Ответ на: комментарий от Eddy_Em

По поводу быдлокода - мне это это нужно для отдадки.

То, что в glibc это есть, я знаю. Но там используется в том числе и маллос. т.е. как раз придется писать свой sbrk.

vromanov ★★★
() автор топика

printf/sprintf для MCU

В кои-то веки соглашусь с Эдди - быдлокодеры, для вас же питон придумали.

anonymous
()
Ответ на: комментарий от anonymous

Более-менее ничего, но допиливать надо.. long long не поддерживается. форматирование идет в буффер, а уже потом выводится на uart.

vromanov ★★★
() автор топика
Ответ на: комментарий от vromanov

Если тебе нужен полноценный printf (оставим в стороне разумность и целесообразность), то просто компиляй с glibc!

Вместо sbrk/mmap подсунь пустышки (все равно для printf они не нужны, разве что если ты scanf будешь использовать, но это уж совсем вершина рукожопия). Аналогично — пустышки для всяких IO. Ну, а _write через свое устройство вывода реализуй (скажем, алиасом на usb_write_byte или как там у тебя эта функция обзывается).

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

если «printf/sprintf на микроконтроллерах — явный признак быдлокода», интересно как отлаживать реалтайм? протоколы там всякие и т.п.?))

zudwa
()
Ответ на: комментарий от vromanov

нужно для отдадки

Если система такая встроенная, не думал сделать бинарные данные в логе и простой парсер на каком-нибудь перле на хосте, который бы, используя исходники, приводил это в человеческий вид? Это ещё и избавит от необходимости хранить на плате форматные строки printf-ов.

sergej ★★★★★
()
Ответ на: комментарий от zudwa

Элементарно: "usb_write..."

Сам так и отлаживаю. Нафиг printf? Кстати, может, через недельку-другую, если будет желание, выложу на гитхаб/сосфорж примерчик, как printf разжиряет код.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от zudwa

Короче, смотри мои stm8samples, stm32samples и ircontroller на гитхабе/сосфорже.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

посмотрел, ничего революционного не увидел.

ТС требует более менее стандартный интерфейс в виде строки форматирования printf, а ты предлагаешь usb-cdc и prnt(uint8_t *wrd), которая имхо должна бы обзываться puts.

Как передать целое число в консоль через prnt? Видимо, написать собственный itoa.

Кстати, зачем prnt копирует строку в выходной буфер через usb_send, который блокирует мутекс на каждый символ. Оверхед же)) Может usb_send_buf(const char* buf, size_t buflen) дописать?

zudwa
()
Ответ на: комментарий от zudwa

отлаживать реалтайм
printf/sprintf

Упрлс? Скидываешь как есть куда придется, а потом с внешним просмоторщиком медитируешь. А то понавтыкают отладки, а потом «чёт мы не укладываемся»...

Stil ★★★★★
()
Ответ на: комментарий от Stil

вот так «наскидывашь как есть куда придется», сидишь это вовне разглядываешь и медитируешь: а не «упрлс» ли я?

zudwa
()
Ответ на: комментарий от Stil

Упрлс? Скидываешь как есть куда придется, а потом с внешним просмоторщиком медитируешь. А то понавтыкают отладки, а потом «чёт мы не укладываемся»...

Люто лорчую.

Pavval ★★★★★
()
Ответ на: комментарий от zudwa

Кстати, зачем prnt копирует строку в выходной буфер через usb_send, который блокирует мутекс на каждый символ. Оверхед же)) Может usb_send_buf(const char* buf, size_t buflen) дописать?

ХЗ, не помню уже. Надо глянуть. Действительно, буфером проще будет вытолкнуть, все равно оно блоками по 64 туда-сюда бродит.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от vromanov

Ты, кстати, логический анализатор юзаешь? Крайне советую. Простой клон saleae logick на ибее вполне недорого стоит. Я себе прикупил, просто не нарадуюсь!

Вот, только вчера сидел, тупил: сделал 1-wire на STM8, при работе с отладочным кодом все ОК, а как только эти "принты" убираю, глючит. Посмотрел анализатором — оказывается, это из-за того, что я слишком шустро начинаю следующий байт передавать (нужно было хотя бы микросекунд 60 подождать, т.к. я по compare/capture прерыванию убиваю таймер). Просто воткнул опрос КА 1-wire не на каждой итерации while(1) в main, а не чаще, чем 1 раз в 1мс. И все зашибись!

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

У меня есть настоящий Logic Pro 16 :). Есть и осцилограф с анализатором.

vromanov ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.