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().
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.
I think there are two different problems here, both of which we should look at.
you’re right, in the SDK, if GenerateBubbleText is called, and your code just calls ClearResultStrings and never adds any result strings, it should not be displayed on the given channel. I haven’t tested this myself, but I don’t think we took this into account when we implemented this for Logic 2. It should be a simple fix - however, I think we have a larger problem.
The original analyzer SDK was not intended to support overlapping frames. This limitation would prevent you from displaying different bubble ranges on one channel and another, which is what your analyzer is doing. In the V1 software, this happened to work because most of the frame rendering code just looked at the starting sample of each frame - the ending sample was largely ignored.
The V2 software implements bubble merging code, which may break this behavior - although I haven’t tested it yet. I suspect the bubble merging code requires all frames to be in ascending order of starting sample number and ascending order of ending sample number. If that’s the case, that would probably break for analyzers like yours.
We’re working on a solution for this in Python High Level Analyzers (HLAs). HLAs also only support a single stream of output frames at the moment, we’re still working out how to support outputting frames on multiple layers or streams, like you’re trying to do here.
Could you share your analyzer source code, so we could use it to reproduce the first issue over here for debugging? If not, we can just modify our SPI analyzer to mimic the behavior.
I’ll talk to the team about the second issue you’re seeing, but I think we’ll mainly focus on how to support this in the HLA API. Could you send any details about what you’re trying to accomplish? Any thoughts on what functionality you would like to see would be great!
Hi @rei_vilo! Rani already asked for captures, but I want to also ask for samples of your I2C and SPI data. We have some sample data over here but it’s very limited - the terminal works fine for it, but it’s not a realistic representation of real data. That would help me debug the terminal behavior.
Could you share your analyzer source code, so we could use it to reproduce the first issue over here for debugging? If not, we can just modify our SPI analyzer to mimic the behavior.
The link I provided in the previous post has details on this but here are the links for convenience:
The plugin supports simulation but I think that feature is still missing in V2, so if you need a capture the link here has a file which can be used:
The plugin is quite complex and not the easiest to understand what is going on; so here are some additional details that might help:
The actual SPI packet structure is as follow (taken from the ABCC40 Software Design Guide):
NOTE: What is shown in the image above is one SPI packet (one instance where chipselect may assert low and then deassert). What I show within the red box is what my previous images correlate with. In the same timespan as MISO’s “NETTIME” field, the MOSI has “APP STAT”, “INT MASK”, and 2 bytes of the message data field which in this case I implement each byte of the message field as its own V1 frame.
Effectively my plugin is creating the following V1 frames:
Over this time span there are a total of 5 frames added. 1 for MISO, and 4 for MOSI. I use the flags field of the V1 Frame to indicate whether the frame is for MOSI or MISO (if looking at the source code this is “SPI_MOSI_FLAG”).
The logic implemented in GenerateBubbleText() is separated into a few parts. The main two sections consist of:
Logic that ONLY concerns MOSI
Logic that ONLY concerns MISO.
Effectively, when a MOSI-indicated frame (i.e. the special SPI_MOSI_FLAG is asserted in the V1 Frame’s flags field) is passed into GenerateBubbleText() with the “channel” parameter set to MISO, this frame (in most cases) will be skipped (no call to AddResultString is made). This is how this separation of MOSI/MISO frame structure is supported.
The exceptions to this is for common/shared events that both channels exhibit at the same time. This for instance is for things like an SPI fragment where the SPI chipselect deasserts before the end of the packet is reached. Such an event may be handled for both MOSI and MISO. In these cases the frame time span is identical (and the same exact V1 frame).
Comparatively, the Saleae SPI plugin does this (where the frame size is specified by user settings):
In other words, a V1 frame that is committed contains data for both MISO and MOSI. This means the SPI packet framing structure must be identical for both MISO/MOSI. The previous example avoids this by committing frames for MOSI independent of MISO.
During initial development of the plugin I considered the alternate approach where the plugin would always use a frame size of 16-bits this would make both MOSI and MISO have the same frame size.
Current framing structure:
MOSI (CH1): [ APP STAT ][ INT MASK ][ MSG DATA ][ MSG DATA ]
MISO (CH2): [ NETTIME ]
TIME: --------------------------------------------------------------->
I opt’d against it since using a field’s actual data size as the frame size is more intuitive than splitting up a 32-bit value into two 16-bit frames. And certain features like the CRC32 field where computation is performed and the bubble text will indicate to the user if the CRC32 is invalid would not be as clean of an implementation.
NOTE: You might wonder why did I not consider 32-bit framing structure instead of 16-bit frames? Well the SPI packet structure does not have this guarantee. The protocol defined here only guarantees the number of bytes transmitted will always be evenly divisible by 2.
