Nice improvements!
Also some good news (technically occurred several releases ago), is that the C++ plugin which I mentioned back in Logic 2.2.5 no longer has the rendering issue that blacks out the GUI!
There are still issues here which I will attempt to explain here and maybe this could be looked into if there is an internal issue in the implementation, something that has yet to be implemented to support the old versions behaviors/features, or a general compatibility issue with the new implementation which won’t be fixed for some reason.
In the figure below I am committing a frame that is intended for only a specific channel; in this case MISO which I outline the in green.
What I am finding is that committing this frame is generating bubble text to be rendered on unrelated channels. Normally my plugin does not render bubble text on the SPI clock channel but for testing purposes I added in the statement below:
In SpiAnalyzer::SetupResults() method:
mResults->AddChannelBubblesWillAppearOn(mSettings->mClockChannel);
Furthermore in SpiAnalyzerResults::GenerateBubbleText() I checked the “channel” parameter to see if the clock channel is specified, if so I return immediately thus no call to AddResultString() was performed for this channel.
In V1 this meant no bubble text / blue frame would be drawn on the channel at the currently processed frame’s timespan. This seems to have changed in V2.
So with this behavior I have 1 frame that is supposed to be drawn on MISO and instead it is also being drawn on MOSI and SCLK simply because these channels are added via AddChannelBubblesWillAppearOn().
Removing my modification for AddChannelBubblesWillAppearOn() it looks like this:
For reference here is how it is suppose to be rendered.
As you can see above, the “TIME” frame is being drawn on top of 4 other frames that were actually meant to be rendered on MOSI.
I believe with the standard Saleae plugins MOSI and MISO data are combined into a single frame. This is the main difference between this implementation and the standard SPI plugin. I believe any plugin that would be developed as a bi-directional asynchronous solution (i.e. think the standard serial plugin but using both TX and RX within the same plugin instance) would be problematic to support in this current state; of course in my case SPI is synchronous, but I break down the frame structure logically to be more user friendly in consuming the information (rather than lumping multiple fields into a single frame or breaking up a large frame into separate components). So I think this is an issue that should be resolved to make the framework more capable.