It turns out that displaying large tables in a terminal window gets a bit confusing and unruly. So I have switched to a graphical interface. Editing doesn't work yet but tables can be displayed.

Added some rudimentary support for getting categories from XDF files and displaying them. Does not work well with nested categories (un-nests them).

I am probably going to create my own file format and have a built in converter for XDFs. This will eliminate most of the road blocks I've been running into. Unfortunately the XDF format seems to be very hacky (though I dislike XML/heavily generic data structures given my primarily embedded background, so I am biased) and a lot of things seem like they were an afterthought.

Also I will try to remove axis definitions, I already support editing axis directly from an opened table, so having the extra tables makes little sense.

Also added in file pickers, so the bin/xdf paths aren't hard coded.

Thanks. It is a fun project, and I get to look forward to eventually not needing to use my windows laptop at all. KWP flashing will be interesting when I get around to it. Gives me something easy to do in between tweaking my tune and trying to learn how ME7 works. Once I have a better understanding of tuning I'll probably move on to writing my own assembly patches, which should be much easier as I already have a strong understanding of low level computing (having written several instruction sets/architectures of my own). It would be nice to give myself some more room in some of the maps just as a starter project.

Hopefully other people will find it useful when its more mature, although I do not recommend using it right now, while everything does work, it's very clunky and lacks some important QoL features (like mass editing cells, comparing bins, graphing...)

Next up I will be adding graphs though.

That is the end goal, most development is happening from an arm64 MacBook running Linux. I eventually want to get kwp flashing and logging from something embedded like an ESP32. Once I figure out how kwp works over serial with these vag kkl cables I'm sure it will be fairly straightforward.

My next step is to assemble the bench harness I got parts for and then flash the stock software to my unitronic ECU so I don't have to worry about any oddities with that. I don't have much use for the unitronic software anymore anyways, my own tune seems to run noticeably (hesitant to say much) smoother even with my very minimal knowledge from a couple weeks reading this forum and the wiki. Glad the PO payed for the OTS tune and not me.
Once I have the bench setup I'll be able to iterate pretty quickly with flashing/logging implementations.

Also, I added graphing capabilities earlier this evening before I went and messed with the load tables in my car. I haven't actually pushed the code yet though. I will probably do that tomorrow after some cleanup.

A lot of this wouldn't be possible in such short amounts of time without the amazing amount of libraries people have made for rust. A lot of things (like the graphing) are turned into an exercise of reading documentation instead of designing and implementing entire packages. This is just to say that I can't take credit for everything.

ECU is fine, something wrong with the harness. Probably missed something in all the guides I read...

Question 1: so while I am heavily leaning towards designing my own open file format for map definitions, does anybody have recommendations of existing open formats to consider? Even if I don't use it directly I may write a converter so this app can use it.

Question 2: how does ME7Info actually work? If I write a logger I would want to implement its functionality.

Also for now I am avoiding reading any GPL code, as my goal is to release this as MIT or BSD0, but that may change if/when I make a final decision on licensing and well I progress without looking at the existing projects like the Nefmoto flasher. Ultimately I don't really care what the license is, but it would be nice if it were truly free.

ME7Info works by parsing the structure defined in TKMWL.
Tool I wrote for pattern matching was an idea, but it's quite useless tbh, as you needed to define patterns in xml.

Internally these days I have something much better.
It can take any C166/ST10/PowerPC/TriCore binary, automatically detect the code areas and registers.
It can then disassemble it in-process, and with a bunch of clever algos and false positive rejection go through the code on a known and unknown binary and match all the memory accesses.
It tracks subroutines, calls, jumps, registers, copies between registers and so on.

This is the basis of being able to provide the Logger advanced service, because it is impossible to have the exact A2L for every file.
Been working on it for years. Unfortunately I don't think I can ever opensource it nor does it find maps, because I never intended for it to do that (I just work with measurements).

As shown in the screenshot, this takes just 4 seconds on ME7 on my mid tier laptop.

Alternative when you have a lot more time, is to use bindiff in Ghidra or Ida. It can also do a lot for finding symbols between files.
This of course takes much longer, as you have to load every binary correctly and process it. So what takes my tool under 30 seconds can easily take an hour using this method.
Good if you need to get the addresses for one car, but not viable commercially.

I'm saying you don't have to nobody is going to sue you