Hi @timreyes,
Thank you for the response and no need to apologize for this issue. =)
I am fully aware of the timeline of Saleae logic v1 and Windows 11. I have been using Saleae logic since the very first Logic 8 and the even older Windows 7 Aero style GUI that predated the QT-based GUI; I own the Logic 8, Logic 16, and Logic 16 Pro; if a Logic 32 Pro existed, I might be tempted to get that too =P. I was merely asking if anyone has encountered this issue, or if it might have been an issue on my end. Or maybe someone found a more elegant solution.
The reason why I need/want this older version is that I have a fairly complex plugin (See the wiki page if you want to see more on what the plugin does):
GitHub - hms-networks/AbccSpiAnalyzer
And this plugin is based on an even more complex SPI device (most SPI devices we see day-to-day are extremely simple in comparison). If curious, this is the documentation page for the starterkit of the product which targets a lot of different industrial protocols and communication technologies:
Anybus CompactCom Starter Kit
The “hardware design guide” covers the basics of the different embedded communication interfaces supported, while the “software design guides” and “network guides” cover the SPI packet’s (data) fields and object model that is used in this communication.
I have not looked too closely at the V2 releases as of late to re-evaluate my position on this topic. But last I knew the following features of my plugin were not supported in V2 (I have posted about these in several threads here during the early (pre-)release builds of V2):
- Exporting frames to custom CSV formats that are optimized for certain focus points / development workflows.
- Simulation mode, which is used to help with test and verification of the plugin logic. This also has a feature which allows a specifically formatted log file (taken from devices running this protocol) to be reproduced to help with decoding the data that otherwise would just be a sequence of HEX bytes instead of enumerated values.
On top of these, I use a behavior of V1 which I have been told on several occasions is not actually supported by Saleae and it “just happens to work”. Basically, I submit two separate sequences of frames, one sequence for MISO and another for MOSI. This allows for more precise framing of the underlying protocol (instead of having the word size fixed) that this plugin is based on. Below is an image that shows this behavior. Notice the CRC frames are not aligned to one another and that there are frame lengths of different sizes 1-byte frames, 2-byte frames, and 4-byte frames, all sized to match the underlying SPI packet’s data fields. This representation is much clearer from a readability standpoint than using say a 2-byte word size and splitting up the CRC32’s into halves.
I decided to forego this warning years ago when I first started development of this plugin since in my eyes the improved user experience/readability was/is worth the potential risk of future incompatibilities (I stand by this decision still).
If V2 is not feature complete with what was available in V1 it is a hard sell for me to want to migrate to a lesser experience for this plugin. Do not get me wrong, I really like the HLA component of V2, but V1 still has legitimate reasons for it being considered a better option in some cases. One other general reason I like V1 is it just overall feels snappier and more performant than V2. I cannot say I have tried a comparison lately to know if this has changed, but I recall earlier on, V2 could not keep up with high data rates as well as V1 which, to me, can be quite important.
