Trice Collaboration/Sharing ideas

[matteofumagalli1275]

Hello,

I stumbled on trice from the trending repositories on github and the project inspired me with some ideas about an open source project I shared online some month ago.
I work as an embedded developer and to help debugging iot devices i started designing a tool capable of deferring trace rendering to a frontend instead of writing terminal codes for coloring.
It then quickly escalated to also parse and lint cbor cloud packets, jsons and many more stuff.

The project i'm talking about is this: Bellog
The built application can be found at: https://bel-log.github.io/
One of the most cool features is the possibility of reading the serial port from the browser, without the need to install anything.

I like trice so I think I'll work on a sample project to support that format for rendering.

If you want to give me an opinion or ideas for collaborating I would appreciate it.

Thanks

[rokath]

Hi Matteo,

the binary trice format is stable and the description is in https://github.com/rokath/trice/blob/master/docs/TriceUserGuide.md#15-binary-encoding. The Read function inside https://github.com/rokath/trice/blob/master/internal/trexDecoder/trexDecoder.go is the relevant example. Please consider, that the encoding usually is little endian but can be also big endian.

The file til.json is the ID-to-string translation table. The additional location information inside li.json you can simply skip. Both, the trice tool could generate in a different format too, if that helps.

All possible channels are handled inside https://github.com/rokath/trice/blob/master/internal/emitter/lineTransformerANSI.go only.

The binary trice packages are usually framed with TCOBS, but that the user can switch to normal COBS, what is easier to implement.

You could consider using Go too. It is an inredible language which can generate also Web-Assmbly code if that matters.

It could be easier for your project to use the trice tool for the coversion from the binary format into a format you can directly import. But maybe then trice needs to run in the background. From there it can use TCP for data transmission. But i do not understand enough so far from Bellog.

Hopefully this helps as starting point. BR Thomas

[matteofumagalli1275]

Thank you very much!

[matteofumagalli1275]

@rokath i successfully added trice to one of our projects, but i have a question.

In most of our projects the application code is a small part, most of the code is inside multiple submodules and have a config.h file where you provide the macro for priting.

#define SM_PRINTLINE(...) DEBUG_PRINT(__VA_ARGS__)

Using trice you can't just replace the macro inside the .h file of the module, because the pc software needs to replace all occurences and provide ids, so i would need to replace all calls inside all modules with trice instead of a generic macro.

I don't like the idea, but even if i do it i think it could create problems in scenarios where the module is added halfway of the project development and there is a trice 'id' conflict, the pc software i think it may replace the conflicting id in the module instead of the application.

One solution could be run the software after the preprocessor but i couldn't find a way to do it for propietary compilers like IAR.

Did i miss something? Is there a way you are currently addressing this kind of condition?

Thanks

[rokath]

trice, Trice and TRice are macros and currently i only see the option to replace SM_PRINTLINE with trice for example using a text replace utility.
There is issue #154 but it is planned to remove the IDs at all from the source code. Issue #421 addresses that now. I need a few calm days for implementing that.
What could be a quick option: ID ranges - see here https://github.com/rokath/trice/blob/master/docs/TriceUserGuide.md#17-trice-id-numbers

[matteofumagalli1275]

I see, that's great news.
From #421 i suppose that your idea is to do a replace-text in the post build to remove the 'id' generated by trace u.
What about give the option to set a trice alias with trace u, like trace u -alias SM_PRINTLINE and then restore the full file with trace z?
In that way i could keep SM_PRINTLINE in the code without changing the library.

Aside from our libraries i think this is a condition common with many libs, like for example lwip:

#ifndef LWIP_PLATFORM_DIAG
#include "config.h"
#define LWIP_PLATFORM_DIAG(x) do {LWIP_PRINT x;} while(0)
#endif

//in config.h
#define LWIP_PRINT(...)                     debug_console_printf(__VA_ARGS__) 

I think i could give this idea a try with some simple bash script, unfortunately i'm not used to Go.

[rokath]

Your proposal sounds cool and is probably doable. But I fear unwanted side effects. For example if the alias string occurs in an other context too. Also it would spoil the trice tool. Maybe it is better to let do the macro replacement in both directions a user tool written with awk or sed. Let us think a bit more about that.
One tool for one task.

[rokath]

v0.61.0 is out now and supports trice insert and trice clean. That allows to get rid of the IDs inside of the sources.