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


Нет.
Я говорил уже не раз на форуме: stdlib IAR-а (и многих других компиляторов) имеет внутреннюю функцию:
extern "C" int _Printf( void *(*)(void *, int), void *, const char *, va_list *);
Она не декларирована в IAR-овских хидерах, но все прочие декларированные вовне printf, sprintf, vsprintf и всё это семейство внутри вызывают именно её.
Она обладает максимальными возможностями из всего этого семейства printf*, включает всё.
Я у себя в проектах IAR использую только её. И никаких других sprintf() или чего-то ещё.

а я вот туплю - как инициализировать семафор. я пользовался уже готовыми semTake, semGive.


вы уж меня извините но тащить этого монстра в свой проект я не буду.

Я не знаю как это делать в vxWork - не использовал её.
Но да - потокобезопасное добавление данных в очередь можно сделать на базе семафора. Это один из вариантов.
Другие варианты: а) критическая секция; б) интерфейс на базе аналога InterlockedCompareExchangePointer() + дин.память; в)...?


В смысле??
А это разве не Ваше?:

Читайте внимательнее мои посты:
Любая printf*-функция внутри вызывает _Printf() (в IAR). Воспользуйтесь отладчиком чтобы убедиться.
Так что Вы затащили ещё большего "монстра" к себе

нет. это - printf ("LIB ID = %d\n", lib_id); - в vxWork - там мне не важно, там у меня мощный камень и ОС. но в проектах на IAR я printf не использую.

И зря. У меня проект для motor-control с соответствующими требованиями к реалтаймовости (ШИМ == 20кГц). И _Printf() прекрасно в это время работает никак не мешая.
А Ваш суп из ItoA + пачка strcat - это те же яйца, только в профиль.

Эстетические) Процессы асинхронно просто вызывают некую функцию , которая уже внутри помещает сообщение в очередь. Получается естественно.
Другая задача асинхронно читает очередь, и получив очередное сообщение, форматирует его, готовит к записи в соответствующий файл.

Приветствую!

И не только красота - правильная очередь и функция записи в нее позволить
логровать например из прерываний или из других нехороших мест куда обычному printf вход заказан.

Удачи! Rob.

Заказан кем? Достаточный размер стека и... вуаля! - sprintf прекрасно работает и из ISR.

Приветствую!


Вобще то printf и sprintf это немного разные пчелы - жужжат по разному.
И стек этот наверное прямо в мозгу программиста будет - чтобы инфу получал без IO функций.

Удачи! Rob.

Вы не поверите, но практически одинаковые! Так как внутри они почти сразу вызывают указанную мной _Printf().
Только одна в первом аргументе передаёт ей указатель на callback-функцию записи в ОЗУ, а другая - на callback-функцию записи в поток ввода/вывода.
У меня, например, среди прочего _Printf() пишет прямо в поток TCP-сокета (расчленяя вывод на лету на отдельные кадры без промежуточного буфера и поддерживая ретрансмиссию тоже без буфера).
Свои callback-функции для _Printf() невероятно расширяют её возможности. Всё ограничивается только фантазией программиста.
А уж тривиальный вывод в буфер ограниченного размера делается через _Printf() на раз.

Приветствую!

Да неужели? поверю Вам на слово
Но если они для Вас так одинаковы - что мешает Вам использовать printf в прерывании?


То есть пока ACK для сегмента не получим из printf не уйдем ?
Да уж - фантазия программиста страшная штука - но моя только заставляла меня свои _Printf() писать падла

Удачи! Rob.

Ничего. Если будет нужно - использую.


Да с чего бы? Для каждого отправляемого TCP-сегмента _Printf() естественно вызывается отдельно. У меня весь сетевой стек построен построен на callback-ах: от самого низа (Ethernet-DMA) до верхних HTTP и пр. - всё в пределах одной задачи ОС.


Свой лисапед? А зачем если готовый есть?
Он вроде даже позволяет добавить обработку своих дополнительных букв %...

Приветствую!


Так я ж и говорю - неуемная фантазия программиста ну и ADuC812 - страшная штука!

Успехов! Rob.

Опасаюсь, что sprintf может задержать прерывание на время парсинга. А так - бросил в очередь. И пусть отдельная задача неспеша всё пишет.

Эт ж зависит от реализации. sprintf не боле чем имя, которое может быть переопределено.
В компиляторах даже обязывают проводить адаптацию нижнего уровня функций класса printf.
Так что объективно рассуждать о них под embedded не имеет смысла, там может быть что угодно.
В моих проектах printf применяется в прерываниях, поскольку выводит синхронно без циклов ожидания в канал RTT, профилирован и имеет известную глубину стека. Т.е. полностью детерминирован.