Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32181

Re: Log for debug purposes

Show all headers | View raw

Il 23/05/2024 13:46, David Brown ha scritto:
> 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.

This is the same reason I didn't completely like that project. However 
it remains interesting.


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

Sure it could be an improvement.


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

Too complex for me to follow this arguments.

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

Thread

Log for debug purposes pozz <pozzugno@gmail.com> - 2024-05-22 22:36 +0200
  Re: Log for debug purposes David Brown <david.brown@hesbynett.no> - 2024-05-23 13:46 +0200
    Re: Log for debug purposes pozz <pozzugno@gmail.com> - 2024-05-23 22:25 +0200
    Re: Log for debug purposes pozz <pozzugno@gmail.com> - 2024-05-24 08:57 +0200
      Re: Log for debug purposes David Brown <david.brown@hesbynett.no> - 2024-05-24 11:07 +0200

csiph-web