Deutsch English Français Italiano |
<v2pdpi$279aq$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: pozz <pozzugno@gmail.com> Newsgroups: comp.arch.embedded Subject: Re: Log for debug purposes Date: Fri, 24 May 2024 08:57:54 +0200 Organization: A noiseless patient Spider Lines: 113 Message-ID: <v2pdpi$279aq$1@dont-email.me> References: <v2ll04$1bga1$1@dont-email.me> <v2naaq$1o14p$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 24 May 2024 08:57:55 +0200 (CEST) Injection-Info: dont-email.me; posting-host="16b3c7d5ea7be6be439203ded68b3b4a"; logging-data="2336090"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19tdCy7AwRkEHcbGdQmpxnAT19kdQz0tnY=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:fc+e8PNJ2GU8POvQeQDAaCOkBxw= In-Reply-To: <v2naaq$1o14p$1@dont-email.me> Content-Language: it Bytes: 5540 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. > > 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. The drawback of your approach is that the developer must invent every time a different trace name. Suppose you want to emit several trace messages inside a function: void new_position(uint32_t x, uint32_y, int16_t a) { trice(new_position_enter, "Entering new position(%lud, %lud, %d)", x, y, a); if (a == 0) { trice(new_position_a0, "Hey, you pass a wrong parameter for a"); } if ((cr_x != x) || (cr_y != y) || (cr_a != a)) { trice(new_position_changed, "The new position really changed (cr=%lud,%lud,%d)", cr_x, cr_y, cr_a); cr_x = x; cr_y = y; cr_a = a; } ... } Here the postfixs "new_position_enter", "new_position_a0", "new_position_changed" are needed to create a different ID by calculating the 32-bits hash of the string "position.c <postfix>". What about using the line number instead of a custom postfix that the developer must invent at every trace macro? Surely the line number is not constant during developing, but I don't think it's important. The tracer tool running on the host could reload the json file (with IDs) when it changes. In this case, every build is linked to a trace json file, like a symbol file.