I agree, a consistent timeline as in first class math lesson.
Thanks Jonathan, good catch. We built an adapter to connect the original analyzer API to our new database, and some of the functionality changed - sometimes intentionally, sometimes not. We’re pretty unsatisfied with how Elasticsearch has turned out in the new application, so we’re likely going to switch to another solution the next time we visit the analyzer results view, which should be soon.
It looks like skipping “empty” items should be an easy fix, we’ll get that taken care of - likely our next bug crunch day.
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)
Turns out our own analyzers used this very inconsistently. Rani went though and updated the C++ sources (you can review on our github organization) to make this consistent. However I don’t quite recall what we landed on.
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.
Good catch. I’ve just reviewed the code of the old and new applications, and the new application just joins all frames with a newline character while the old code added each result as a separate entry into the database. Do you have any preference on this?
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.
Yup, this has been in the SDK since the very first release, and we never implemented front end support. I think we forgot about it after writing the enum. None of the analyzers we wrote use AnalyzerSettingInterfaceText, even in the normal text mode.
One of the joys of writing the front-end of the alpha software in HTML & Javascript is that fixing things like this couldn’t be easier. I just threw one together now. It needs a little more work, which I’d like to take care of on our next bug crunch day.
Final note - please check out the 2.2.6 release if you haven’t already. It contains support for custom Python “high level analyzers” which allow you to run code on top of existing analyzers. The SPI support isn’t very good at the moment, but your feedback could help a lot in improving the experience.
@Jonathan I’ve just added support for FilePath and FolderPath in the new UI, if you set the text setting to one of those modes, a browse button will be available in the analyzer settings UI.
This will ship in 2.2.7, likely early next week.
Thanks Mark, appreciate the detailed feedback on this.
Good catch. I’ve just reviewed the code of the old and new applications, and the new application just joins all frames with a newline character while the old code added each result as a separate entry into the database. Do you have any preference on this?
It is a little hard to say from my standpoint. Really the reason why I use multiple Tabular Text entries for a single frame are due to the following limitations that exist in V1:
- No UI support for visualization of a “packet”.
- The SDK of course supports packets but when it comes to displaying them there is no indication for a user to observe (other than exporting data to a file).
- I think a highlight/box around a group of bubble texts in the plot and some form of highlighting/boxing of decoded protocol entries associated with a packet would help users visualize what a packet is versus a frame. With SPI framing is pretty obvious with the presence of chipselect, but some SPI devices support 3-wire mode (the device my protocol is based around optionally supports this).
- The subwindow lacked resize-ability.
- This has certainly been improved upon in V2, but there are still limits to how far the subwindow can be resized horizontally.
- Ultimately there is a point where it is impractical for a user to resize the width of this subwindow. The developer of a plugin may have to make a choice on how much information to show or consider ways to shorten the description so that it does not take up too much space. Otherwise the text may run off the screen and a user has no way to easily read it without exporting the data.
- For instance a frame that is a U8, U16, U32 which contains bit-fields. If all flags are asserted it may be challenging to fit all that information in the visible space provided (using acronyms or abbreviations can only go so far). Perhaps a hover tooltip on the decoded protocol text could assist in this situation?
- The fundamental nature of committing frames for SPI full duplex communication.
- Normally with full duplex SPI communication it is only natural that the MOSI/MISO frames committed in the plugin end up being interleaved (or combined into the same frame as the stock Saleae SPI plugin handled it).
- I made a design choice to collect all MOSI SPI frames for a given packet and the add all decoded protocol texts for that packet during a specific frame and then perform the same operation in the MISO direction. This helped to separate the MOSI frame data from the MISO and allow for more user friendly way to read the information.
By having all my frame data for a given packet be highlighted together when clicked on (see the original Figure H), the user gets some level of feedback that the data belongs together which I think helps users more quickly understand the data they are looking at. But this is more of a workaround than a desired solution. I used this in conjunction with a header (i.e. “-----MOSI MESSAGE-----” or “-----MISO MESSAGE-----”) to further improve this visual separation of information.
- Ideally it would be nice to have a built-in header/title-entry for a packet in the decoded protocols section (in place of my MOSI/MISO message strings mentioned above), which when clicked on, would fit the logic view to contain the first and last frame in the view space.
- Also I think there could be some improvement on how searching decoded protocols is handled when considering a “packet” search versus a “frame” search. This discussion ties into my other thought above about a possible regex; which I think is a complex topic to figure out the right way to do it.
Final note - please check out the 2.2.6 release if you haven’t already.
I will be checking out the python functionality soon.
Thanks @Jonathan, that’s fantastic feedback!
We want to completely rewrite the data table in the software to support analyzer-specific columns. I’d also love to add the ability to expand/collapse packets. We’ll need to discuss internally, since that level of functionality complicates things quite a bit.
The full duplex nature is tricky. Are the transmitted and received packets that are overlapped related in any way? Do they have the same length, and starting location? Or is MISO and MOSI treated as two independent streams, which can be involved in unrelated packets at any time?
I think this is a great example of what we need to be able to support to ensure the tool is as capable as possible. Any additional details would be great.
On another note, the next release should also have the fix where frames with no entries from GenerateFrameTabularText will not be included in the current list view.
The nature of SPI is that it has one clock line, one Master Out Slave In line and one Master In Slave Out line. The both master (MOSI) and slave (MISO) output bits are serially clocked out by the master provided clock. Often the three wires are connected to multiple devices and an enable line is used to select the specific device the master wishes to communicate with. For devices like ADCs the enable often also provides framing information for multiple channel transfers.
It is inherent in the system that the input and output data is overlapped bit for bit in time. For many devices the MISO data is the old contents of a register or port while the new contents are being provided over MOSI.
I feel I may be telling you stuff you already know, in which case I apologize!
1 Like
Couple terms which I use below:
-
“Host” is the SPI-master (this is to differentiate from the industrial network master/PLC)
-
“Module” is the SPI-slave (the Anybus CompactCom)
Are the transmitted and received packets that are overlapped related in any way?
Yes, there is some intercommunication between the packets but overall it is quite limited.
For a little background info:
In industrial communications there are typically two forms of communication.
- “Acyclic data” (also known as explicit messaging, or service data)
- Handles request/response messaging to perform various operations in an explicit nature. Commonly used for accessing diagnostics or configuration.
- “Cyclic data” (also known as implicit messaging or process data)
- A regular update interval is used where one device produces data and another consumes it. Typically to drive the actual industrial process.
This SPI protocol is an abstraction of this concept to ideally simplify the process of supporting the various network specific protocols. So, what we have is an SPI packet format that can exchange cyclic and acyclic data. And there is a bunch of other functionalities built in which help with:
-
the host device determining the state of the network
-
the module determining the state of the host device
-
SPI communication errors (so that retransmission can be performed); detected via CRC.
-
Message fragmentation and segmentation to support transfer of large explicit messaging payloads between the host and module. These concepts may be used, for example, to communicate a file transfer for firmware update.
-
And so on.
If you want more details on this, we have a bunch of documentation which you could refer to on the product site. I can link it if desired; the most relevant document in this discussion would be the ABCC40 Software Design Guide.
The main fields that have this intercommunication relationship are the “Message Data Length” and “Process Data Length” fields of the MOSI frame. Once these lengths have been “clocked in” to the module on the MISO line, the module changes how it assembles the SPI packet on-the-fly within the same packet transfer.
Do they have the same length, and starting location?
Yes, the host and module have a common understanding of what the overall SPI packet length is based on the “Message Data Length” and “Process Data Length” fields previously mentioned.
Even in 3-wire mode the “starting point” of a packet is still the same on both; after an IDLE condition is detected both host and module will transmit their first byte of the packet on the first 8-bits clocked by the SPI-master clock.
Or is MISO and MOSI treated as two independent streams, which can be involved in unrelated packets at any time?
I am not entirely sure I understand this question; but perhaps what I mention above clarified this point.
Some additional information which may provide some insight:
-
The message data field of the SPI packet is used to convey acyclic/explicit data via an “object messaging” concept (our Software Design Guide goes into details on this). The idea is that both the master and slave can create a command to ask the other link partner to do something, and then respond as appropriate (i.e. a requested parameter’s value, a status/error code, etc). When such a command is received there is an allocated “source identifier” which is used internally by the sender/source of the command to track a command/response “transaction”. Having such a concept allows for both host and module to make additional requests before a prior command has been responded to (i.e. we can receive out-of-order responses if an application is threaded).
-
From an industrial network perspective, a PLC on the network may want to read some diagnostic information from the device. This read request would be using some network-specific mechanism which the module then translates into this “object messaging” protocol. The host application receives this request and responds with the appropriate information; however, as alluded to above, this does not have to be responded to within the next SPI transfer/packet (though industrial protocols usually utilize some sort of timeout condition). Until the host is able to provide a response, the host application is able to continue making new SPI transfers so that it can keep up to date with network status information and handling of its cyclic application and the process data exchange with the industrial network protocol.
@P.Jaquiery I believe that the issue was fixed. Please let us know if you encounter it again