Awesome analyzer! Thanks for the feedback on the process too, that helps a lot! We consider the current state of the marketplace and the HLA api very rough, and we’re trying to get as much feedback as we can to help plan improvements.
How could I add Quad and Octal flash support?
In the current HLA API, there is no way to read the other inputs directly. That said, there are some low-level analyzers (C++ libraries) that other users have written for Quad SPI.
For example:
You could fork one of these, or write your own.
Out of the box these low-level analyzers (LLAs) won’t feed data into HLAs without some modifications. We haven’t made the API for this official yet, so it’s subject to change, but you can see how we added “FrameV2” support to our SPI analyzer here:
Could we provide defaults for settings? For example address bytes should default to 3.
Unfortunately not yet, but that’s something we’ll probably add directly to the settings classes as an optional parameter.
Could we have boolean settings? I have different classes of commands that it’d be nice to enable and disable independently.
Good catch. Any other types you would like to see?
Could we enter numeric values as hex? Addresses are awkward in decimal.
This could probably just be built in.
In this case, would you prefer to have more features built into the NumberSetting class (e.g. float vs. integer, custom validator, etc)?
Alternatively, you could just use a StringSetting setting and validate it yourself. We don’t have a super clean solution for this, but right now you can raise an exception when your class is constructed.
What format is the “format” value in result_types? I tried treating it like a Python string format to print the value as hex but it didn’t work.
This really needs to be in our documentation, sorry about that.
“format” is a handlebars format string that’s passed the complete frame object that was returned by the decode function.
It needs a lot of work. We’re planning on adding a number of custom helpers to make it easier to format values, but in the meantime, you might want to just store strings in your output object to get the display you want.
I think in 2.3.9, we now respect the display radix of the HLA, but I need to double check. (HLA display radix is set by right-clicking the HLA in the analyzer sidebar, it also affects the data table radix)
The most helpful thing to mention is that triple braces {{{ }}} tells the template to just display the string without any escape characters, which is needed for strings like “=” to display properly.
A few more things I would like to add. We’re currently working on big “under the hood” improvements for the data processing system, but when we get back to HLAs and the Marketplace, the first order of business will be to make improvements to the ability to discover, install, and manage extensions. Once that’s in reasonable shape, the next step for the marketplace and HLAs will be the developer experience, including documentation, tooling and the API. Speaking of the API, our current plan is to expand the API in a backward compatible way.
Thanks again for the feedback! I’m looking forward to making big improvements to this.
Ah! I’ve poked the low level API with the original Logic and didn’t realize it applied to V2 as well. I’ll take a look at modifying something next time I need it.
Not that I can think of at the moment.
My hope was that’d be automatic. I expect that I’d get a float if the number has a decimal, otherwise I’d get an int. Something like python’s int() parsing which handles prefixes like 0x iirc.
Ok, awesome! That’s what I was wondering.
No problem! I was really impressed with it overall. I thought the creation, testing and publishing was all really easy. Easy enough that I can see hacking together one-off analyzers as needed.
Any luck/updates on this? Will try taking look at one or both of these other versions.
I am playing around with Teensy 4.1 with memory chips connected to it using Quad SPI, and would be nice to decode the Quad signals. Actually it is setup for two different chips with two different Chip selects and sharing the other quad SPI signals.
Thanks I have downloaded and built the SPI_FLASH version. took me a bit to update my Visual Studio, plus needed to install MFC classes…
Then the build did not complete found it needed the environment variable:
SALEAESDK to point to where your SDK is installed. In my case D:\github\AnalyzerSDK
Then it built. Took me awhile to find how to install it with the current V2 builds. Right click in background… Installed, restarted Logic…
Then started a capture. I installed both SPI and the QSPI on those pins as to see the different data:
@scott Thanks so much for sharing this, and also thanks for getting it published on our marketplace! As for multiple tracks, you could add another HLA to your capture. Would that help in your case?
@scott Thanks for clarifying that. I added your idea to our ideas page below so we can start tracking it. I agree, it can be a pain to have to add multiple HLAs across several input analyzers while having to match the settings:
Also, to get an idea of your specific need for this, can you describe what you plan to accomplish with your comment below with regards to your workflow and your test setup? I’d like to get that logged in the idea post above so we can make sure we fully understand where you’re coming from. Thanks in advance!
I’d love to output the raw bytes on separate tracks.
Thanks for making the idea to track! Generally, I’d like to have different bubble tracks for different things. One for the commands, one for the raw data (more like what the SPI LLA gives) and one for errors. That would allow one to better survey the full analysis. (Like easily finding errors.) Right now I have a HLA setting to select between those types of bubbles: Logic2-SPIFlash/SPIFlashAnalyzer.py at 0.9.0 · adafruit/Logic2-SPIFlash · GitHub
