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


Groups > comp.arch.embedded > #27067

Re: Efficient debug log

Subject Re: Efficient debug log
Newsgroups comp.arch.embedded
References <okpt2m$sok$1@dont-email.me>
From Clifford Heath <no.spam@please.net>
Organization Tell him he's dreaming
Message-ID <g4ecB.95706$_25.60397@fx09.iad> (permalink)
Date 2017-07-21 12:57 +1000

Show all headers | View raw


On 20/07/17 19:31, pozz wrote:
> I usually prints some messages on a free UART used as a debug port. They 
> are very useful during debugging to understand the flow of execution.
> 
> Most of the time, I don't compile the debug log facility in release build.
> 
> I sometimes need to disable messages from some modules and enable 
> messages from other modules under debugging.
> Moreover I sometimes need to enable/disable less important messages.
> 
> Do you suggest some efficient implementation of debug log macros that 
> include all the features above?

We used to use a 32-bit trace-control word with bit-fields assigned for
different subject areas. In large systems, 26 such words under letters
of the alphabet, so you could enable tracing e.g. "t0-3,c6", etc.

The trace function took a first argument that packed a letter and a
number (0..31) into 16 bits, which made it quick to check whether
that trace flag was enabled. printf-style string & varargs followed.
It also returned the "enabled" boolean, so you could avoid a code
path whose only purpose is to generate detailed tracing.

More recently (2005) I implemented an even more powerful system, but
it would only suit the largest embedded systems. It had an inlined
test for the trace class being enabled (less than 2ns if disabled,
after the first pass that bound the control variable), then queued
the control strings and parameters into a large shared memory buffer.
The buffer used lock-free synchronisation, so on normal Intel
hardware could achieve >1GBps. One or more trace consumer threads
could format the messages and write to a file, or send them over a
TCP link. This consumer thread also listened for local connection
requests so you could remotely enable and listen to tracing on a
program while it was already running.

So yeah, the sky is the limit as far as sophistication goes ;)

Clifford Heath.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Efficient debug log pozz <pozzugno@gmail.com> - 2017-07-20 11:31 +0200
  Re: Efficient debug log Anders.Montonen@kapsi.spam.stop.fi.invalid - 2017-07-20 10:35 +0000
  Re: Efficient debug log Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2017-07-20 23:14 +0200
    Re: Efficient debug log David Brown <david.brown@hesbynett.no> - 2017-07-24 09:40 +0200
      Re: Efficient debug log pozz <pozzugno@gmail.com> - 2017-07-26 11:15 +0200
        Re: Efficient debug log David Brown <david.brown@hesbynett.no> - 2017-07-26 14:24 +0200
        Re: Efficient debug log Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2017-07-27 10:23 +0200
          Re: Efficient debug log David Brown <david.brown@hesbynett.no> - 2017-07-27 11:14 +0200
      Re: Efficient debug log Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2017-07-27 10:06 +0200
        Re: Efficient debug log David Brown <david.brown@hesbynett.no> - 2017-07-27 11:35 +0200
  Re: Efficient debug log Clifford Heath <no.spam@please.net> - 2017-07-21 12:57 +1000
  Re: Efficient debug log Jack <jack4747@gmail.com> - 2017-07-20 23:17 -0700
  Re: Efficient debug log Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-29 12:47 +0000
    Re: Efficient debug log pozz <pozzugno@gmail.com> - 2017-07-31 10:45 +0200
      Re: Efficient debug log Chris <xxx.syseng.yyy@gfsys.co.uk> - 2017-07-31 16:44 +0000

csiph-web