Why the file and line are not part of the til.json?

[rokath]

Good point! In fact its a bit historical - file and line came in later as a quick fix. Some thoughts:

• If file and line are bound to the ID, we do not need transfer them during runtime, what is a PLUS.
• But if you alllow the same ID to be used on different locations ( trice u -sharedIDs) what then? OK, we could drop that option.
• Imagine you have several firmware versions. Id(100) for example is used in file1.c at line 100 in version 1 and in version 2 some code was removed and Id(100) is used in line 63 of file1.c. Then you cannot display correct location information for both firmware versions out of the box. You would need different location information for each firmware version, what would blow up the til.json file and needs additional communication logik, for example a firmware hash code transmission every second or so.
• Right now the price we pay are 4 additional bytes for each Trice.
• In Issue #242 the idea is noted to add a task ID as well to the location information. So a better solution should also include that.

[liborw]

Thanks for clarification, I get the sharedIDs point, but the two firmware version is easily solved by two til.json i.e. different branch in a repository, same as you have to have two version of the file1.c to find the actual location...

The idea I'm working on is to save the data raw as they come from target and "play it" later for analysis, and then 4 bytes for each message are quite noticeable.

[rokath]

Please describe your use case a bit more in detail. Data logging into FLASH memory?

Data handling

• JLinkRTTLogger writes raw data in a file & trice l -p FILE -args name can display it.
  • When using trice -p JLINK -args ... the raw data arrive in a temporary file.
  • The -v option shows its name.

Data reducing

• You can aways disable the location information and also target timestamps.
• Use TRICE8 and TRICE16 when possible, to reduce needed raw data space if more than 1 value.
• You can modify the encoding and drop padding bytes and also the COBS encoding.
  • This new encoding gets a separate name then.

Disadvantages

• Several til.json would complicate the handling.
• More data inside til.json would slow down trice.

Possible Solution

• The ID carries the location information. It is simply not inside til.json.
• The trice tool could parse the sources and generate an actual location information file li.json.
• That is easy, has no big impact and we get what you want.
• Then the different versions do not affect the integration til.json.
• If the user provides a wrong li.json, only the location information is affected.
• What do you think?

[liborw]

The user case is a project that will run couple of hours, and log as much data as possible as these runs are not easy to perform, and then analyze the logged data, i.e. plots of some key values, etc. It was just an idea to decrease the size of the logged file.

Disadvantages: I still do not understand the problem with two til.json, as you still have two version of each file (the two firmware versions). Also I'm not sure how go implements dictionaries but I would guess that as long as the number of keys (iDs) is same the performance does not change much.

I'm not trying to push change, just thinking. Actually, currently I'm using just the firmware and pyocd to get the Trice messages through RTT out of the MCU and the processing them in python (online or offline), as I do not know go, so it was hard to modify it to mi purpose.

[rokath]

If data minimizing for recording really matters, check here: https://github.com/rokath/trice/blob/master/docs/TriceObsoleteEncodings.md#411-flex-short-sub-encoding - The FLEX encoding worked well and you can get away with 4 bytes per Trice in the minimum case which includes 2 data bytes. I dropped it in favour for COBS and to keep the TRICE syntax clean. Thinking about your use case, brings me to the conclusion to reactivate it but not spoiling the TRICE syntax. Just a SMALL encoding allowing only 2 value bytes.

[rokath]

Dealing with with several til.json versions, believe me, brings a lot of discomfort especially if colleges simply want watch the logs. It is much easier to tell them just to use the latest til.json version without knowledge about the firmware variant and version. In this context they are not interested in location information. The SW developer generates an li.json and when the trice tool it finds, the location information is displayable.