Missing V1 analyzer SDK plugin features and ideas

Logic 2 Software
1

Perhaps these are already on the list of TODOs/backlog but I figure I would mention them here:

In V1 an analyzer had the option to define any given “export” option. This is currently not available in V2 and is a major feature that is missing in my opinion. While the integrated spreadsheet in V2 is nice, it is quite limited in nature and it cannot possibly cover all the use cases that a developer of a plugin may want.

Is there a plan to support this?

Here is an example of a plugin running on V2 and its hamburger menu.
image

Here is the same plugin running on V1 which provides 3 custom define export options:
image

Is there a plan to also support the plugin’s “simulated data” that originates from the GenerateSimulationData analyzer API?

One thing that I have for a long time felt was missing from the analyzer SDK is an API for the analyzer to specify a version indicator. From a support standpoint it is often the case we would want to know what version of the analyzer plugin they are using in order to better diagnose the issue (of course with Windows DLLs you can embed this into the metadata of the DLL itself, but this is OS-specific). Today I have a very hacky, but clever, way of doing this by using the simulation data to convey a test sequence that embeds the version information and the user can then us the export options (as mentioned above) to produce a human readable version.

The better option would be for the API to allow the DLL to call some function during setup/initialization which would then be used in the analyzer’s settings window. Example:

image
image552×561 23.6 KB

2

What I missed from the export options the ability to export timestampless.

When reverse engineering protocols I often generated traces with A and B and diffed them (after removing manually the timestamp column with a regexp).

3

Hello,

You can achieve this by setting the environment variable ENABLE_SIMULATION to 1.

The export is a very useful feature, is there any progress on adding it back to Logic 2.x?
I can export the data from my custom low-level analyzer as it is shown in the data table by clicking on the three vertical dots next to the table search bar and then clicking “Export Table”. However, since there is only v1frame type available, only the value column can be used to display information. Thus if you don’t want to just show the hex value, you have to use text in the value column and not in a dedicated “description” column, for example. This is bad for further automated processing.
In Logic 1.x the AnalyzerResults::GenerateExportFile() function was used to generate a custom export. This seems to no longer be supported in Logic 2.x. If I click on the three vertical dots next to my analyzer and then select “Export to TXT/CSV”, I simply get an empty file.

1 Like
4

Hi @cg1 - Good to hear from you! My responses are below:

However, since there is only v1frame type available, only the value column can be used to display information.

In Logic 1.x the AnalyzerResults::GenerateExportFile() function was used to generate a custom export. This seems to no longer be supported in Logic 2.x

This is true. Unfortunately, we haven’t made any progress on getting these features added to the Logic 2 app. In the past, I created the 2 idea posts below, and it looks like you’ve got your vote in on both of them. We’ve decided to continue monitoring interest in this feature in the idea posts below before committing these to the roadmap.

If I click on the three vertical dots next to my analyzer and then select “Export to TXT/CSV”, I simply get an empty file.

The empty file is likely due to Logic 2 not supporting the AnalyzerResults::GenerateExportFile() function. Although I haven’t tested this recently, custom analyzer exports should work with the Logic 2 app. In case you’d like me to double check this for you, feel free to send me your source code using the link below. Just make sure to include a link to this discuss forum post so that I know it’s you.
https://contact.saleae.com/hc/en-us/requests/new

5

Hi @timreyes,
I’ve checked my code again and I loop over packets before looping over frames within packets. It seems that Logic 2.x does not support packets any more because GetNumFrames() returns the correct amount of total frames but GetNumPackets() returns 0. I’m chunking the frames into packets though and it worked with Logic 1.x.

I got it working now by iterating through the frames even if there are no packets but I’ve noticed an issue. The export always uses an absolute time base, with 0 being the beginning of the capture. With a normal time based capture everything is fine. However, if you use a trigger and there is any pre-trigger data, the Logic 2.x GUI shows the trigger as time 0 (thanks btw, was a request), whereas the export uses the beginning of the capture as time 0. Therefore when looking at the export compared to the GUI the timings are misaligned. Would be nice if the export used the same timings as the GUI.

Edit: Could also be solved by adding a function to get the timestamp of the trigger and doing the math (start of frame - trigger timing) manually. If no trigger is set, simply return 0.

6

@cg1, very sorry for the trouble with the analyzer API.

Getting the existing C++ analyzer API implemented in the Logic 2 software was a huge undertaking and a serious square peg → round hole problem.

The original API never supported data trimming, editable capture start time, looping mode, and many other features of Logic 2. In the old software, analyzers would not start until the digital trigger was found, guaranteeing that all results produced by the analyzer would be valid over the lifespan of the session, and that the capture origin time would never change.

It’s a big project, but ultimately we want to pare back the functionality of the C++ analyzer SDK, and try to move operations like export, multi-layer analysis, etc, into higher level abstractions like our high-level analyzer system.

We’re still in an interim period when we don’t have support (both for C++ analyzers and for python high level analyzers) for a lot of the features of the Logic 1.x custom analyzers. The two main issues are missing packet support, and limited custom export support.

At this time, if you have a C++ analyzer and need to use all features of that analyzer, without significant modification, you may want to consider sticking with the 1.x software for now.

I do have a handful of workarounds you could use to get better functionality out of the Logic 2 software, but it’s a bit of a hack.

You might want to consider migrating to a python high-level analyzer, that uses the results produced by our stock SPI analyzer too. More information here:

The HLA system doesn’t support custom export, but you can create pretty complex results for the data table, which has its own export functionality.

Issues with the Logic 2 API implementation:

  1. GetTriggerSample always returns 0.
    In the old application, this value was an invariant, however in Logic 2, it will change when the trigger is found, and also changed any time the user edits the trigger point. I’ve added support for updating this in Logic 2 when an export is started, which should make export timestamps match the timeline under all circumstances. I hope to get that into the next release.
  2. All packet commands are unimplemented.
    We haven’t added this yet, due to edge cases associated with data deletion. I’m not sure if we will implement support for these functions in Logic 2, however you could implement your own version of this. Keep in mind that the worker thread and the various result functions are not thread safe, so synchronization is required when writing or reading any collection. (the built-in Frame functions have thread safety built-in)
  3. The Logic 2 UI shows a single fixed export option, rather than the list of export options provided by the Analyzer. This is a bug we have logged, in the meantime, I would suggest adding another option to your analyzer settings for the user to select export type, then expose only 1 export option through AddExportOption. Note the label shown in the app is not editable either.