Delayed "printf" - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Delayed "printf"
On Mon, 24 Apr 2017 19:42:30 -0500, Tim Wescott wrote:

Quoted text here. Click to load it

The responses so far are really making me think.

I guess the better way to frame my desire is thus:

I want some way to print free-form debug data to a serial port in such a  
way that anything slow (formatting and waiting on the UART) is performed  
in a low-priority task.

Some printf-like thing may not be the best way to do it -- but I still  
want to do it!!

--  

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Delayed "printf"
Tim Wescott wrote:
Quoted text here. Click to load it

So look over a few varargs examples. If the first argument is a count of  
other arguments, and it's "format string" driven, then you should be  
able to just copy the args to .... something and pick 'em up later.

Just be careful of the lifetime of objects to be printed.

--  
Les Cargill

Re: Delayed "printf"
On 26.4.17 00:11, Tim Wescott wrote:
Quoted text here. Click to load it


Your main problem may be to know when the printf() is done, so
that the source data is free to be used again. You may need to
copy the printf argument values to a buffer, or maybe do a sprintf()
and queue the string to the output device. In any case, delaying
the output means needing to have buffer space.

The problem is similar to one in many networking hacks, where
the protocol stack forces delaying sending the data.

--  

-TV

Re: Delayed "printf"
I recently had a similar problem. What I did was:
- Create a virtual base class with a printf pure virtual function
- derived classes add required parameters and appropriate printf
- fast/time-sensitive task creates+enqueues derived-class objects
- slow path dequeues and prints
This is with FreeRTOS where elapsed time to create/enqueue is
very fast (wrt my application, your mileage...).

Hope that helps!
Best Regards, Dave

PS: C code would do the same with enum for type, union parameter sets, etc.
Not as easy and neat as C++...

Re: Delayed "printf"
Tim Wescott wrote:
Quoted text here. Click to load it

There is nothing dumb about it at all. It can be a bit tricky, though.
But it's really just a variation on logging in general, so there
may be a logger laying around somewhere that fits your specs so you  
don't have to spend a lot of time building one.

--  
Les Cargill

Re: Delayed "printf"
Quoted text here. Click to load it

It's so dumb that I do it often. Usually as a ring buffer of {format string
ptr, arg...} with a fixed limit on the number of args. Sometime I actually
do the print offline, from coredumps or shared memory.


Re: Delayed "printf"
Quoted text here. Click to load it

I do something similar.  In the latest incarnation, there's a
dedicated sourceid/instance index, two 32-bit "parameters", and the
printf "format" string is limited to somehting like 16 bytes.

There's a C macro that puts that stuff into a circular buffer in
shared memory.  Then there is a seperate utility to print the buffer
contents.

--  
Grant Edwards               grant.b.edwards        Yow! Wow!  Look!!  A stray
                                  at               meatball!!  Let's interview
We've slightly trimmed the long signature. Click to see the full one.
Re: Delayed "printf"
Quoted text here. Click to load it

If you want to save even more time/space, you can require that the
format string have a static lifetime, and just copy a pointer into the
circular buffer.

--  
Grant Edwards               grant.b.edwards        Yow! You mean you don't
                                  at               want to watch WRESTLING
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline