Here are some issues that I have come across in the V2. NOTE: This is utilizing a plugin I wrote which I understand may not be in a supported state right now.
To test the behaviors below the plugin can be obtained here:
https://github.com/hms-networks/AbccSpiAnalyzer/releases
And a test capture is available here:
AbccSpi_Example_Startup.sal (56.4 KB)
- An analyzer plugin’s committed frames seems to now always create an entry in the “Decoded Protocols” subwindow even through no tabular text was added via AddTabularText() . (see Figure A below)
- In simple protocols this probably does not seems like an issue but once you start adding complex framing into a protocol there can be a lot of cases where it simply is undesirable to provide all data in the decoded protocols section but it is still desired to render bubble text for the corresponding field in the logic waveform.
- While the way the old Logic software worked was sufficient, if the way the new software works is the “desired behavior” I feel that it is essential to provide the user with more powerful filtering options in the decoded protocols subwindow. Otherwise they may be overburdened with useless information that makes scrolling through the protocol cumbersome. The protocol this plugin concerns can have SPI packets that span over one thousand bytes…but only a couple dozen bytes are what I consider essential to understanding the communication at a high level. In this plugin’s case, I felt it was best to enable powerful file export options in the plugin to inspect data more closely and keep the tabular text for more high-level information. Searching for a message data byte equal to 0x33 (as an example) could yield many matches with no context of what that byte actually addresses in the protocol. And then removing the “search expression” in the decoded protocols subwindow there is no automatic navigation to what was last selected before clearing the search (see Figure B illustrating this behavior below using the old software)
- Some ideas on this: Support user-specified regular expressions in the search bar or provide an API to allow a plugin to fetch the user-defined search expression and allow it to handle returning relevant search results in the tabular text. This could enable plugins to support custom query operations that otherwise would not be possible with a baseline regular expression evaluation (i.e. special query commands)
- It seems the wrong metadata is being used in the UI from what the analyzer plugin API provides. The UI appears to be using the configuration’s SetTitleAndTooltip() strings instead of the AddChannel() strings. (see Figure A below)
- On this note to help support potentially long channel names, the UI may want to support the use of an ellipsis to trim the channel name string when it would otherwise exceed the horizontal rendering space and provide a tooltip to help a user resolve the full name of the channel. Or alternatively make the channel column re-sizable to fit the full name of the channels’ strings.
Figure A:
Figure B: Example showing search behavior of old Logic software:
For comparison the Figures C and D below show what the old Logic software looked like regarding the channel names. The plugin simply uses “MOSI”, “MISO”, “CLOCK”, and “ENABLE” for each channel name when calling AddChannel(). The analyzer plugin itself is named “ABCC SPI Protocol”. As can be seen the “Analyzer settings” title for each channel is what the new Logic software is using instead for the channel name.
Figure C:
Figure D:
SIDE NOTE: In the image above the “Advanced settings” textbox is technically a AnalyzerSettingInterfaceText::FilePath which according to the original SDK document this type was supposed to have a file browse button. Is there any plan to add support for this? It would be very much appreciated if this support could be finally added in.
- The UI renderer breaks (no recovery possible without application relaunch) when zooming in on capture. It is unclear what is causing this but worth mentioning. (see Figure E below)
- You can use the *.sal linked above to test or even the software’s “simulation mode” currently causes this behavior (but I have no idea if the “simulation” is technically working from the V2 software side or not yet.)
Figure E:
- Analyzer’s hamburger menu option “Stream to terminal” does not deselect and instead a click event for “Show in results table” is clicked during the “uncheck” click event. (see Figure F below)
Figure F:
- The time shown in Figure G below seems to be handled wrong. I would expect this to say “-1 s” not “+9 s”. When you zoom in (this is from the *.sal available above) this gets corrected…so it seems to be an issue in the “most zoomed out” state of the capture.
Figure G:
- On a similar note this capture has a large pre-trigger than I normally like and I wanted to reconfigure the pre-trigger buffer size. Is there a way to set this in the new software? On the old software you were able to set this in the application preferences. Currently it seems you must create a specific pre-trigger size by using some basic math (shown below). I usually like to have a fixed pre-trigger capture size to get a little bit of context of the conversation leading up to the trigger event but then like to change the capture duration after the event. This is a minor inconvenience that leads to managing two parameters instead of a single parameter when wanting to change the capture duration:
pre-trigger size in seconds = “After stopping, trim to last s.” - “Capture duration after trigger”
- This could be an unintended side effect that Saleae never intended or perhaps an issue in V2. When making multiple calls to AddTabularText() Logic software V1 would display these as new lines in the “decoded protocols” where as V2 keeps the entries all on the same row. See Figure H below for comparison.
Figure H:
ANOTHER SIDE NOTE: The SDK has for quite some time had provisions for supporting transactions. Is there any plan to finally support this in someway? The protocol that this plugin is based on has a concept of a message “source ID” which is a method for tracking a command/response transaction in the SPI communication and allow for multiple commands to be invoked before responses are received. It would be interesting to hear what plans there are for supporting this.
Anyways, I have been watching V2 evolve for some months now…really great work and look forward to the continued evolution of this software.