Path: ...!3.eu.feeder.erje.net!feeder.erje.net!news2.arglkargh.de!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch.embedded
Subject: Re: Log for debug purposes
Date: Thu, 23 May 2024 13:46:34 +0200
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <v2naaq$1o14p$1@dont-email.me>
References: <v2ll04$1bga1$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 May 2024 13:46:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f9e44f8620308395335310dec31cb554";
	logging-data="1836185"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/RbRkeCJYkYj/7XrZlqB+b4QmlHRpyOew="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:fs/CoG1RFXZDjTIrEguMcBMHYMY=
Content-Language: en-GB
In-Reply-To: <v2ll04$1bga1$1@dont-email.me>
Bytes: 4588

On 22/05/2024 22:36, pozz wrote:
> I don't repeat here what is written there[1]. I found trice library and 
> I find it interesting to emit log messages for debug purposes, avoiding 
> printf execution on the target.
> 
> What I don't like is patching my code before compiling. This step delays 
> the build process and could mess up the repository, even if is simple to 
> un-patch the code before committing.
> 
> Do you apply other strategies?
> 
> I'm thinking to introduce this type of log in one of my application 
> where the firmware runs on an embedded platform indirectly connected to 
> Internet. I mean the main MCU is connected to another Internet-connected 
> device by a RS485 bus.
> 
> It could be very useful to receive logs from the main MCU through Internet.
> 
> 
> [1] https://github.com/rokath/trice


I would not use a system that changed my source code - it's just out of 
the question for me.  I'm fine with /generation/ of source code files as 
part of a build process, but not /changing/ code I have written.  So if 
I were making a system like this, I would definitely not have it change 
the source code.

Suppose you want to trace calls to the "new_position" function in your 
source code file "positioning.c".  With trice, you'd have something like:

void new_position(uint32_t x, uint32_y, int16_t a)
{
	trice("Moved to new position %lud, %lud, %d", x, y, a);
	...
}

After the patching, you get a parameter "iD(1234)" added to that macro.

My way to handle this would be that you write :

	trice(new_position, "Moved to new position %lud, %lud, %d", x,
				y, a);


Here, I'd be using a definition of the macro "trice" to convert this to:

	trice_new_position(x, y, a)

The pre-processing step, the equivalent of "trice insert", would run 
through the file "positioning.c" and generate files 
"positioning.trace.json" and "positioning.trace.h".  The id would be 
generated from a 32-bit hash (say 1234) of "positioning.c" and 
"new_position", and the json file would include an entry with the hash, 
the filename, function name and line number, the format string, and the 
names of the parameters.  The header file would contain a line:

#define trice_new_position(x, y, a) do_trice_3(1234, x, y, a)

And do_trice_3() would be an inline function that sends out the trace on 
the uart (or whatever).


The file "positioning.c" would have a line #include 
"positioning.trice.h".  The generated files (including that header) 
would be in the build directory, not the source directory, and generated 
automatically by the makefile whenever the C code changed.


This would give you everything you get from the "trice" library, but 
without any patching or unpatching, and with the trace generation 
updated automatically as part of the "make" process.

I think it could be done a bit smarter, using _Generic macros to handle 
detection of the types of the parameters so that sizes get handled 
automatically.


In real work now, however, I'd use C++ to avoid any need of modifying 
the source code or generating header files.  (You would still need to 
chew through the source code to make the json file or other input to the 
PC side of the tracer.  But I think if portability is not an issue, that 
could be handled by having the "trice" macros put the information in a 
special elf section that is then read by the tracer program.)