Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Свой __write
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > IAR
Dron_Gus
Хочу перенаправить printf на dbgu. Отключаю C-Spy пишу функцию size_t __write(int out, unsigned char const *pBuf, size_t len); Все бы хорошо, но данные скидываются этой функции по одному символу. PDC не применить. sad.gif А очень хочется. Может это как-то настраивается? Ведь передается же size_t len функции зачем-то?
axle
А какой компилятор, библиотека "С" какая?
Я разбирался с arm-elf-gcc и newlib - все работало. Там printf вообще создавала собственный буфер и писала данные в него, пока он не заполнялся или не появлялся символ перевода строки, и только тогда все разом перекидывала во __write.
scifi
Если очень хочется, то можно создать свой буфер, накапливать в нём данные и слать пачками.
Dron_Gus
Компилятор IAR'овский. Он шлет по одному. sad.gif Накапливать и посылать - слишком большие накладные расходы на вызов функци, ИМХО.
zltigo
Цитата(axle @ Apr 24 2007, 19:30) *
Я разбирался с arm-elf-gcc и newlib - все работало. Там printf вообще создавала собственный буфер и писала данные в него, пока он не заполнялся или не появлялся символ перевода строки, и только тогда все разом перекидывала во __write.

Жуть, если так обстоит дело - самочинная буферизация с malloc-ами! Думаю, что Вы ошиблись.



Цитата(Dron_Gus @ Apr 24 2007, 23:21) *
Накапливать и посылать - слишком большие накладные расходы на вызов функци, ИМХО.

свой printf() на базе vsprintf() при статическом буфере даже при последующем побайтном (фифофированном) выводе в UART работает быстрее (немного sad.gif )штатного IAR-овского printf(). Цена - буфер под строчку.
Alex B._
>> Жуть, если так обстоит дело - самочинная буферизация с
>> malloc-ами! Думаю, что Вы ошиблись.
так и есть. f/printf там heap-а требует. И только по fflush(stdout) можно это дело ускорить.
Сергей Борщ
Цитата(zltigo @ Apr 24 2007, 22:40) *
Цена - буфер под строчку.
Поправьте, если я неправ - printf требует море ОЗУ в частности и из-за того, что резервирует на стеке место под буфер на все случаи жизни. Получается, если vsprintf использует внешний буфер, то задавая буфер адекватного размера можно еще и на требованиях к стеку выиграть. Я ошибаюсь?
zltigo
Цитата(Сергей Борщ @ Apr 25 2007, 01:11) *
Поправьте, если я неправ - printf требует море ОЗУ в частности и из-за того, что резервирует на стеке место под буфер на все случаи жизни.


Все известные мне реализации printf() и прочих ...f() есть обертки одного и того же. И в следствие этого не имеют радикальных отличий по использованию стека.
В IAR это выглядит так:
Код
int (printf)(const char *fmt, ...)
    {    /* print formatted to stdout */
    int ans;
    va_list ap;

    va_start(ap, fmt);
    ans = _Printf(&_Prout, (void *)1, fmt, &ap);
    va_end(ap);
    return (ans);
    }

int (vsnprintf)(char *s, size_t size,
    const char *fmt, va_list ap)
    {    /* print formatted to string from arg list */
        int ans;
    _SNProutInfo x;

        x.count = 0;
    if (size == 0)
        {    /* write nothing */
        x.s = (char *)&x.size;    /* place to junk terminating nul */
        x.size = 0;
        }
    else
        {    /* set up buffer */
        x.s = s;
        x.size = --size;
        }
    ans = _Printf(&_SNProut, &x, fmt, &ap);
    *x.s = '\0';

    return ans < 0 ? ans : x.count;
    }

Собственно движок ....f() память под буфер кушает только на размер одного максимального равертутого формата знак+число+экспонента 40 с хвостиком байт, что не так трагично.
vromanov
FYI - В CrossWorks реализация printf вызывает и требует __putc(int c).
Dron_Gus
Написал свой printf на основе vsprintf по совету zltigo. Примерно так
Код
int printf(const char *format, ...)
  {
  int len;
  __Va_list ap;
  va_start(ap, format);
  len = vsprintf(OutTempStr, format, ap);
  dbgu_cdma(OutTempStr);
  va_end(ap);
  return len;
  }


В погоне за дальнейшим ускорением собираюсь передавать ф-ии vsprintf сразу нужную позичию в кольцевом буфере, чтоб писать сразу в буфер. Возник вопрос, как бы оценить размер того, что vsprintf нагенерирует? Есть ли какое-то ограничение на размер генерируемой строки? Просто не хочется "наезжать" на соседние данные и в то же время не хочется лишний раз копировать туда-сюда.
zltigo
Цитата(Dron_Gus @ May 1 2007, 19:38) *
Возник вопрос, как бы оценить размер того, что vsprintf нагенерирует? Есть ли какое-то ограничение на размер генерируемой строки?

Разумеется ограничения нет, но тут вроде и проблемы нет - Вы же сами-же и пользуетесь этой печатью и знаете какого обьема куски печатать собираетесь.
Ну и если Вы собираетесь "печатать" в байтовый кольцевой буфер, то идея с влетающими группами байт становится уже неудобной smile.gif. Ограничтесь байтовой печатью а усилия направьте на оптимизацию работы кольцевого буфера.
Я тут когда-то уже распинался по поводу эффективного кольцевого буфера.
DASM
Не припомните где именно по поводу буфера ? Третий раз его сам писал, с интервалами год. Интересно было глядеть на свою эволюцию. И интересно поглядеть на чужое
zltigo
Цитата(DASM @ May 1 2007, 22:16) *
Не припомните где именно по поводу буфера ?

Тут. Начиналось не с буфера то потом дошло:
http://electronix.ru/forum/index.php?showt...amp;hl=uart_isr
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.