Hi @KurtE, great questions!
First, mFlags should work. Our SPI analyzer already uses the flags SPI_ERROR_FLAG (1 << 0 ) and #define DISPLAY_AS_ERROR_FLAG ( 1 << 7 )
(however DISPLAY_AS_ERROR_FLAG is ignored, that was a nice idea back when we wrote the API, but never used it)
You should be able to use flags in between like 1 << 1 through 1 << 6 without issue.
Our software does not do anything special with mFlags, it should work just as well as mData1. If you delete the usage of SPI_ERROR_FLAG and DISPLAY_AS_ERROR_FLAG from the SPI source, you could store any value you like in mFlags.
Second, new analyzers based on our existing analyzers won’t be merged back in. I can’t recall if you can change the name of a github fork, but if you can’t, you can always create a new repository but add all the commits from the original repository.
We are interested in pull requests for things like bug fixes, adding missing functionality that the official protocol specification includes, adding support for new versions of the protocol (where these are backwards compatible) and things like improving clarity, etc. However, for different protocols, even ones that are supersets of existing protocols, we would like to encourage developers to keep these separate, re-name them to match the protocol or application, and maintain github releases using the example we provide in the SampleAnalyzer.
Longer term, we really want to get marketplace support for C++ analyzers.
Lastly, nice work on the USB analyzer FrameV2 support! Another member of our team ran into similar trouble when dealing with the precise Framev2 output organization when working on the USB analyzer on the side last year. I’ve forwarded your issue over to him to see if he could share some of his thoughts.
Also, it’s worth mentioning, if you haven’t found it, that you can hide columns by right-clicking any column label. It’s a manual process, but quite necessary for problems like this. Suggestions welcome.
My USB PD protocol decoder also suffers from a large number of columns.