Thankd @timreyes
Yes I remember debugging the Dynamixel stuff earlier on the old IDE (real old).
As you can see in my previous post, I fixed the fault and save/restore setting…
Now to see if I can hack up partial HLA and talk to it…
Need to look at docs to see what constraints…
Opps, looks like I started from Master branch… Probably need to work from alpha…
Will see how hard to migrate over…
put up new branch: alpha_spiex
This one at least talks to the spi transaction framer. So I know that it talks somee to HLA
Ah! Clever. 
Let me play around with that and see how it goes. Thanks.
I started playing around with maybe an ILI9341 example HLA using my SPIEx code…
It is coming along sort of, but python is not a language I have done anything in, other than try to get rid of Ros Python code a few years ago 
So I am stumbling along:
As you can see in picture it is showing that the command is the CASET, which the table shows 2 bytes for entries.
And it then shows the range for columns is 0 319…
But I am not sure if I should be displaying 319…
I have hacked in there:
elif self.last_from == 2: # mosi 2 bytes
if self.data_packet_count == 0:
self.frame_start_time = frame.start_time
self.data_packet_count = 1
self.data_packet_value = mosi[0]
else:
self.data_packet_count = 0
self.data_packet_value = (self.data_packet_value * 256) + mosi[0]
frame_data["command"] = self.data_packet_value
frame_type = "result_packet"
But if I click on the 3 dot it shows that I should be outputting HEX… so question is do I
need to encode the values: to a hex string, and where do I in the Python code get what the
user wants the output format to be?
Also side comments. I started the python code in one directory… Can I move it to another directory? If so How do I update the list?
Also side question, If I look at some published HLAs, they may mention to customize it, clone the project… And then click the local button… Not sure how to do that…
Back to playing
Quick update:
The extended SPI code is currently up in my fork/branch
Wondering at times if it should just be incorporated into SPI…
The ILI9341 experiment code is up at:
If you mean “How do I manage user options” you may be interested in User settings for measurement extensions - #8 by timreyes - I have the same issue. My “Burst Stats” extension has two “user” parameters at the top of the Python source.
Thanks, I was able to roll my own as you can see in:
Edit: where you can see my: option default, which is sort of a kludge, but for caset ans paset it shows in decimal, but others show in hex…
I guess my question in this case was if you look at the context menu for the Extension you see:
And was wondering if this setting was available to the python extension
Ah, Monday morning pre-coffee: I’d forgotten you were working with a LLA. The options issue is an HLA problem. Sorry for butting in. I haven’t ventured into LLA land so can’t help :-(.
Not a problem… Actually was wondering that on the HLA…
Luckily with the LLA, that is built in and I was only adding an extra signal to keep track of, which appears to be working.
Hey @KurtE - I wanted to cover your questions below:
Also side comments. I started the python code in one directory… Can I move it to another directory? If so How do I update the list?
You’ll need to uninstall the extestion > move the source code > reload the extension into the Logic 2 app. Sadly, we don’t have a way of quickly setting a new directory location for local extensions.
Also side question, If I look at some published HLAs, they may mention to customize it, clone the project… And then click the local button… Not sure how to do that…
Clicking the local button simply opens the folder location for the source files of that particular extension.
I guess my question in this case was if you look at the context menu for the Extension you see:
And was wondering if this setting was available to the python extension
At first glance, I don’t think the display radix setting is accessible via an HLA. Let me check with the software team and get back to you on this.
Thanks @timreyes
Sorry, it may be obvious, but unclear to me on where the local button is for extensions that I install but are not mine.
For example earlier I had downloaded the LSS protocol one. I don’t see a local button, to view or edit the sources.
I can click on the repository button, and get to the github project.
Oops, sorry it’s a bit confusing. The local button is only available for extensions that are “local” to the PC and that have been manually installed (i.e. not downloaded via the extensions marketplace).
If you wanted to modify the behavior of an existing extension in the marketplace, you’ll need to navigate to their repo, clone/download it, then install the extensions manually per the instructions below:
The answer is “sort-of” unfortunately.
It is not used in the display strings for bubbles. We want to change that, and also make the display string formatting far more powerful with helper functions, but that will need to wait till a big HLA upgrade.
In the data table, the radix does matter. But, what happens depends on the data type of the column. We really need to get this into our HLA documentation.
There are a handful of FrameV2 column types: Boolean, integer, double, string, and bytes. The display radix affects integers and bytes. We assume that it doesn’t make much sense to change the display format of the other types.
The biggest complaint we have about this is what we show when we display bytes columns using the decimal display radix, because it’s particularly confusing.
Here are some examples:
Binary:
Decimal:
Hex:
Ascii:
As you can see, in the decimal view, we convert each byte of the bytes column to a single decimal number, and delimit each byte with a space.
For the Hex display, we include leading zeros for integers, which are 64 bit.
in Ascii mode, we don’t try to convert integers to ascii, but we do convert bytes columns.
(bytes is the name of the type in Python)
The reasons for these weird conventions are a mix of very complex technical limitations on the indexing system, combined with an inability to make everyone happy. Feedback is very welcome on each display combination.
In a future version of HLAs, we would love to add an optional display schema, so the extension author can specify for example how many bits should be shown in binary mode, so things like 12 bit or 7 bit numbers can be rendered quite clearly.
Under the hood, we’ve built our own search index, which is significantly faster than all the other database indexes we’ve tested with our application, due to the very unique nature of our search. However that has also produced a high cost when it comes to exactly how we can display columns to the user and still index their values.
Thanks @markgarrison , when I was playing with the two Low level analyzers, I ended up adding for example 16 bit values as byte arrays as I noticed you were doing as well with for example MOSI and MISO.
At this point trying to decide what to do with both updated Low level analyzers. USB and the SPI with extra channel…
We recently updated our SampleAnalyzer to include github actions, which builds every commit, and it also automatically creates github releases for each tagged commit.
We made a lot of other improvements too. I suggest you update your custom LLAs using the instructions in that repo, so that you can easily publish releases!
Thanks @markgarrison,
That is a really good update in the readme for the sample analyzer.
For sure I will update my older Dynamixel Servo one over to the newer stuff, although it might also be a good one to convert over to being an HLA on top of the Serial Analyzer. Although Python is not my Native programming language 
But wondering in the two new cases I mentioned here. Currently I have:
SPIE= based off of your current SPI analyzer, but added an ability to specify the DC pin, which I encode in the highest bit of mData2
Frame result_frame;
result_frame.mStartingSampleInclusive = first_sample;
result_frame.mEndingSampleInclusive = mClock->GetSampleNumber();
result_frame.mData1 = mosi_word;
result_frame.mData2 = miso_word;
result_frame.mFlags = 0;
if (dc_word) {
//result_frame.mFlags = SPI_DC_FLAG;
result_frame.mData2 |= 0x8000000000000000ull;
}
mResults->AddFrame( result_frame );
It is/was unclear if I can use a bit in the mFlags instead. I tried earlier to use bits of this, with the Dynamixel code and had issues…
Currently I have this code in simple in a different branch of the SPI analyzer: GitHub - KurtE/spi-analyzer at SPIEx
Question is should I simply fork this off as own project? My guess is yes as guessing unlikely this capability will be merged into the main SPI analyzer.
The other one, (different thread), is I want the ability to better filter USB analyzer, data. But so far you have not added FrameV2 support to this analyzer. So I started a created an alpha branch: GitHub - KurtE/usb-analyzer at alpha
Which has some of it working. While doing some of this, I could see many ways to try to encode the FrameV2 data, so created an issue against it:
Questions is it better to have the AddFrameV2 to have each frame name added to have data names, with more specific data name: like if I have a “PID” item, should it have data name like: “pid”, or something more generic, like: value or data… I am thinking more of the later is to reduce how many columns show up… But would be good to get your insights. Also should I again create new project with this or is this something you would like to migrate into your official analyzer.
Thanks again
Hi @KurtE, great questions!
First, mFlags should work. Our SPI analyzer already uses the flags SPI_ERROR_FLAG (1 << 0 ) and #define DISPLAY_AS_ERROR_FLAG ( 1 << 7 )
(however DISPLAY_AS_ERROR_FLAG is ignored, that was a nice idea back when we wrote the API, but never used it)
You should be able to use flags in between like 1 << 1 through 1 << 6 without issue.
Our software does not do anything special with mFlags, it should work just as well as mData1. If you delete the usage of SPI_ERROR_FLAG and DISPLAY_AS_ERROR_FLAG from the SPI source, you could store any value you like in mFlags.
Second, new analyzers based on our existing analyzers won’t be merged back in. I can’t recall if you can change the name of a github fork, but if you can’t, you can always create a new repository but add all the commits from the original repository.
We are interested in pull requests for things like bug fixes, adding missing functionality that the official protocol specification includes, adding support for new versions of the protocol (where these are backwards compatible) and things like improving clarity, etc. However, for different protocols, even ones that are supersets of existing protocols, we would like to encourage developers to keep these separate, re-name them to match the protocol or application, and maintain github releases using the example we provide in the SampleAnalyzer.
Longer term, we really want to get marketplace support for C++ analyzers.
Lastly, nice work on the USB analyzer FrameV2 support! Another member of our team ran into similar trouble when dealing with the precise Framev2 output organization when working on the USB analyzer on the side last year. I’ve forwarded your issue over to him to see if he could share some of his thoughts.
Also, it’s worth mentioning, if you haven’t found it, that you can hide columns by right-clicking any column label. It’s a manual process, but quite necessary for problems like this. Suggestions welcome.
My USB PD protocol decoder also suffers from a large number of columns.
Thanks @markgarrison
Updated to use flags, so should be able to still do 64 bit spi…
renamed for form to spiex-analyzer although it still links to you spi-anyzer. I also migrated the code then back to master branch.
Updated the Dynamixel LLA to new build instructions, which appears to wok.
Next up play some more with USB