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

Groups > comp.arch.embedded > #27078

Re: Efficient debug log

Show all headers | View raw

On 27/07/17 10:23, Stef wrote:
> On 2017-07-26 pozz wrote in comp.arch.embedded:
>>
>> I have another situation. I want to include a member in a structure, but 
>> it's only used in debug. This member is used only in debug_printf calls, 
>> so it can be omitted in the Release build. If I use #ifdef DEBUG_ENABLE 
>> #endif to avoid including the member, I will have an error during build 
>> (because debug_print refers to a member that doesn't exist).
>> If I leave the member in the structure in Release build, I will waste 
>> some space.
>>
>> Is there a trick to solve this problem?
> 
> I often find this "waste of space" argument a bit irrelevant. On large
> targets, the few extra bytes usually don't matter at all. On small targets,
> the space argument may seem valid. But often, you want to be able to run
> the debug version on the same target as the release version. This means
> the target must have space for this data and that this space will simply
> be vacant if you have a release version with the data removed.
> 
> There is even a danger of expanding the code in release mode and then
> finding it does not fit anymore when you need to switch back to debug.
> 
> But there may be situations where you have a special (larger) target for
> debug than is used for the release. Or situations where you have to store
> or transmit binaries and space is tight or expensive.
> 
> So for these situations (or others, or just for the fun of it), I do find
> Davids exercise in the other reply very interesting.
> 

When working with very small systems, it is not uncommon to use a larger
or faster device for prototyping, testing, etc., and then a cost-optimal
device for mass production.  Sometimes that is just devices in the same
families with different memory sizes, but it could easily be that your
development and software testing is done mainly on an evaluation board
with a large chip, extra UARTs for debug output, etc., and the final
version will run on a different device.

Even when you have just a single device for everything, you may have
different balances.  Perhaps the release system will hold a log of the
last 24 hours of sensor values, while for debugging it is fine for the
log to be 6 hours and use the extra space for debugging information.

There are lots of possibilities here - even though you are right that
the space cost of an extra debug data item or two is rarely significant.

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