Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26407 > unrolled thread

Delayed "printf"

Back to article view | Back to comp.arch.embedded

Contents

  Delayed "printf" Tim Wescott <seemywebsite@myfooter.really> - 2017-04-24 19:42 -0500
    Re: Delayed "printf" Don Y <blockedofcourse@foo.invalid> - 2017-04-24 18:51 -0700
      Re: Delayed "printf" Tim Wescott <tim@seemywebsite.com> - 2017-04-24 21:54 -0500
        Re: Delayed "printf" Don Y <blockedofcourse@foo.invalid> - 2017-04-24 21:27 -0700
    Re: Delayed "printf" Paul Rubin <no.email@nospam.invalid> - 2017-04-24 19:53 -0700
    Re: Delayed "printf" Clifford Heath <no.spam@please.net> - 2017-04-25 13:01 +1000
      Re: Delayed "printf" Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-04-25 18:51 +0100
        Re: Delayed "printf" Clifford Heath <no.spam@please.net> - 2017-04-26 12:59 +1000
          Re: Delayed "printf" Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-04-26 13:24 +0100
    Re: Delayed "printf" Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 00:19 -0500
      Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 10:44 +0200
        Re: Delayed "printf" Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 09:22 -0500
          Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 16:37 +0200
      Re: Delayed "printf" Tim Wescott <tim@seemywebsite.com> - 2017-04-25 10:49 -0500
    Re: Delayed "printf" Jack <jack4747@gmail.com> - 2017-04-24 23:33 -0700
    Re: Delayed "printf" Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-04-25 08:09 +0100
    Re: Delayed "printf" John Devereux <john@devereux.me.uk> - 2017-04-25 08:14 +0100
    Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 10:58 +0200
    Re: Delayed "printf" Stefan Reuther <stefan.news@arcor.de> - 2017-04-25 18:46 +0200
    Re: Delayed "printf" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-04-25 21:03 +0200
    Re: Delayed "printf" Tim Wescott <seemywebsite@myfooter.really> - 2017-04-25 16:11 -0500
      Re: Delayed "printf" Les Cargill <lcargill99@comcast.com> - 2017-04-25 17:28 -0500
      Re: Delayed "printf" Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-04-26 10:03 +0300
    Re: Delayed "printf" Dave Nadler <drn@nadler.com> - 2017-04-25 14:31 -0700
    Re: Delayed "printf" Les Cargill <lcargill99@comcast.com> - 2017-04-25 17:25 -0500
    Re: Delayed "printf" mac <acolvin@efunct.com> - 2017-04-26 17:22 +0000
      Re: Delayed "printf" Grant Edwards <invalid@invalid.invalid> - 2017-04-26 17:37 +0000
        Re: Delayed "printf" Grant Edwards <invalid@invalid.invalid> - 2017-04-26 17:38 +0000

Page 2 of 2 — ← Prev page 1 [2]

#26431

On Mon, 24 Apr 2017 19:42:30 -0500, Tim Wescott wrote:

> Sometimes it's necessary to float a notion just so that someone can
> affirm your suspicion that yes, you really are an idiot.
> 
> On the off chance that I'm a genius, though, here goes:
> 
> I don't like putting "printf" in fast tasks for obvious reasons -- even
> with infinite spooling, it can take time to process a format string.  In
> my usual context, this can result in audible sounds from motors when I
> print some bit of debugging information from a high-priority task.  The
> problem can't be alleviated by spooling the output of the printf,
> because it's the execution time of the printf itself that's the problem.
> 
> Just how dumb is it to have "printf" queue up the format string AND the
> parameters into a buffer, to be printed out in some low-priority task?
> For a system with sufficient memory, this seems like an astonishingly
> sensible thing to me.
> 
> Clearly you'd have to wrap it up somehow so that if the buffer was full
> no printf at all would happen -- but I'm kinda liking the notion.
> 
> So -- whatcha think?

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
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [prev] | [next] | [standalone]

#26434

Tim Wescott wrote:
> On Mon, 24 Apr 2017 19:42:30 -0500, Tim Wescott wrote:
>
>> Sometimes it's necessary to float a notion just so that someone
>> can affirm your suspicion that yes, you really are an idiot.
>>
>> On the off chance that I'm a genius, though, here goes:
>>
>> I don't like putting "printf" in fast tasks for obvious reasons --
>> even with infinite spooling, it can take time to process a format
>> string.  In my usual context, this can result in audible sounds
>> from motors when I print some bit of debugging information from a
>> high-priority task.  The problem can't be alleviated by spooling
>> the output of the printf, because it's the execution time of the
>> printf itself that's the problem.
>>
>> Just how dumb is it to have "printf" queue up the format string AND
>> the parameters into a buffer, to be printed out in some
>> low-priority task? For a system with sufficient memory, this seems
>> like an astonishingly sensible thing to me.
>>
>> Clearly you'd have to wrap it up somehow so that if the buffer was
>> full no printf at all would happen -- but I'm kinda liking the
>> notion.
>>
>> So -- whatcha think?
>
> 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!!
>

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

[toc] | [prev] | [next] | [standalone]

#26438

On 26.4.17 00:11, Tim Wescott wrote:
> 
> 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!!


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

[toc] | [prev] | [next] | [standalone]

#26432

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++...

[toc] | [prev] | [next] | [standalone]

#26433

Tim Wescott wrote:
> Sometimes it's necessary to float a notion just so that someone can
> affirm your suspicion that yes, you really are an idiot.
>
> On the off chance that I'm a genius, though, here goes:
>
> I don't like putting "printf" in fast tasks for obvious reasons --
> even with infinite spooling, it can take time to process a format
> string.  In my usual context, this can result in audible sounds from
> motors when I print some bit of debugging information from a
> high-priority task.  The problem can't be alleviated by spooling the
> output of the printf, because it's the execution time of the printf
> itself that's the problem.
>
> Just how dumb is it to have "printf" queue up the format string AND
> the parameters into a buffer, to be printed out in some low-priority
> task? For a system with sufficient memory, this seems like an
> astonishingly sensible thing to me.
>
> Clearly you'd have to wrap it up somehow so that if the buffer was
> full no printf at all would happen -- but I'm kinda liking the
> notion.
>
> So -- whatcha think?
>

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

[toc] | [prev] | [next] | [standalone]

#26442

> Just how dumb is it to have "printf" queue up the format string AND the 
> parameters into a buffer, to be printed out in some low-priority task?  
> For a system with sufficient memory, this seems like an astonishingly 
> sensible thing to me.

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.

[toc] | [prev] | [next] | [standalone]

#26443

On 2017-04-26, mac <acolvin@efunct.com> wrote:
>> Just how dumb is it to have "printf" queue up the format string AND the 
>> parameters into a buffer, to be printed out in some low-priority task?  
>> For a system with sufficient memory, this seems like an astonishingly 
>> sensible thing to me.
>
> 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.

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
                              gmail.com            it!

[toc] | [prev] | [next] | [standalone]

#26444

On 2017-04-26, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2017-04-26, mac <acolvin@efunct.com> wrote:
>>> Just how dumb is it to have "printf" queue up the format string AND the 
>>> parameters into a buffer, to be printed out in some low-priority task?  
>>> For a system with sufficient memory, this seems like an astonishingly 
>>> sensible thing to me.
>>
>> 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.
>
> 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.

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
                              gmail.com            from ATLANTA?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web