Another follow on, not sure if best to do direct on forum or by message?
Not sure best way to handle…
Suppose I have the updated SPI analyzer with the DC pin:
Now suppose I have a HLA that works with it. In this case an HLA for displaying commands/data
associated with the ILI9341 display.
Should I mark that one as released… As it requires you to install something else to make it work?
Thanks
Kurt
P.S - this will also be true of one(s) for USB, but unclear if I will ever make a complete LLA that exposes everything to HLA, or what I have now that at least allows me to export all of the data messages.
Thanks @KurtE, that’s a great question and something we’ve been thinking about since we launched the marketplace.
The same problem applies to HLAs that depend on other HLAs, once we add support for that.
Today, in order to use a HLA, the user must first manually add the HLA and set all the settings. Some of those settings.
Then, the user needs to manually add the HLA, select which LLA that wish to use, then set more settings.
We would like to streamline that as much as possible.
For example, if your HLA always uses the SPI LLA, then it seems like your HLA should probably just specify that, and the software should just create it automatically when adding the HLA.
However, this is where things get tricky. Here are the questions we’ve been asking internally. I’d love to know if you have opinions on them.
What about HLAs that are designed to work with multiple LLAs, or don’t really care what LLA was used. Should the HLA expose a specific list of supported LLAs, or just not specify this?
What about LLA settings? Some HLAs will only work with specific LLA settings, and the HLA could set these setting for you. What about settings like baud rate? In some cases, the user might still need to specify some settings. Additionally, the HLA might need to know about the LLA settings, or change the LLA settings based on the HLA settings.
How much of this should be user configurable, how much of this should be specified by the HLA author, and, most importantly, how do we manage to keep this simple, intuitive, and powerful all at the same time?
I think this really comes down to how HLAs are used. I’d love to hear your ideal solution for the HLAs you’ve developed.
Some internal examples:
The USB PD HLA requires the manchester LLA to be set with specific settings. The only setting that needs to be entered by the user is the input channel.
The “Text Messages” supports 3 different LLAs. it could support more LLAs too, if they happen to produce the right keys. It does not care what settings the LLA was set with.
As I mentioned could not tell if I should be asking this on forum or PM like this? It was the forum editor suggesting PM as I responded 3 times…
Lots of interesting questions and options mentioned.
Probably an interesting thread to ask others as well. I am still sort of a novice with HLAs as well I am sortof a novice with Python… More of a C/C++ guy for more years than I wish to admit to.
It would be great if an HLA knows that it is associated with a specific LLA, and automatically add it as well if there is not a compatible LLA already active. And maybe somehow have the joint adding, bring up both sets of dialogs for configuring.
Not sure how hard it would be to bring up a composite settings dialog, as for example the LLA will need you to choose which channels are used and maybe other things like, in the case of SPI, which modes (or as you have them split up)… But then the HLA may have other settings as well, like for example if I try to convert my Dynamixel (Robotis Servos) from an LLA to an HLA that depends on Serial (which would be a good thing), it would still have configuration options, like, what Servo Command sets to use for Protocol 1 and/or Protocol 2 servos.
And if an HLA only works with the LLA in some specific configuration, it would be nice if it might preset the LLAs settings to this. For example if my USB HLA code only works in packet mode, than preset that.
Obviously could get complicated if you had multiple HLAs and each one wanted different settings.
So yes it would be interesting if HLA could specify which LLA’s they support and if 1 then one of them is not already running, maybe bring up the add for it and walk the user through both settings. It would be good if the HLA could determine some of the settings of the LLA like in usb mode which format. and either ask user if ok to change…
ChoiceSettings could be augmented with default and override handling that allows a calling HLA to provide configuration values for called HLA/LLAs. The option processing for the calling HLA picks up any options that haven’t been handled by called analyzers and the combined set of undetermined, or not fully determined (the case for caller provided defaults) are then presented to the user.
That allows a calling HLA to specify stuff it is interested in for called analyzers but allows the user access to other stuff. It also lowers the burden for the calling analyzer on managing changes in the called analyzer - the caller only cares about stuff that affects its own functioning.
A PreferredHosts API could be added that allows a HLA to specify analyzers it likes to work with, either as explicit analyzers, or by specifying classes of analyzer. I’m not sure how the “classes” would look, but it would probably be a classes field provided in the extension.json file.
What I’d like to see is for Logic 2 to use the Release from Github for the marketplace downloads, rather than downloading the repo as a zip. We can then use Github Actions to build & package up a nice release zip that includes both a HLA and LLA. This makes sense since the SDK’s LLA template SimpleAnalyzer uses Github Actions already, so only needs minor tweaking to package up a corresponding HLA.
I was at least hoping that Logic 2 would download the latest Release, so users would have the LLA already downloaded for them, and would just have to hunt it down and install it manually (like all other LLA’s). Alas, they just get a zip file of the repo’s source code instead.
This does only work for the simple case of matching LLA’s and HLA’s, so a more complete solution would be extending the existing extension.json that HLA’s use to both support LLA’s and to be able to specify combo’s of LLA and HLA in some way.
We’ve talked a lot internally about supporting LLAs in the marketplace, using github actions to perform the cross-platform build. It’s something we would love to support.
We also really need to make improvements to how analyzers are chained together, and how they are configured. Thanks for sharing your HLA + LLA combo, it’s a great example for us.
We definitely want a simple way for users to easily share and use other shared combinations of custom HLAs and LLAs from the marketplace.
It’s just a matter of when. Unfortunately, we’re a tiny team (3 folks on software) so we can really only work on one thing at a time. However I’m very excited to get back to this.
