Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27067
| 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 |
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
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