Release HLA's that depend on LLA's that are not part of the install?

Thanks again for all of the feedback,

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.

Hey @KurtE,

Another follow on, not sure if best to do direct on forum or by message?

Not sure best way to handle…

Our forum works. Apologies I didn’t get to review this with Mark today. I’ll let you know our update once I’ve had a chance to review this with him.

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.

  1. 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?
  2. 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.
  3. 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… :wink:

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…

hope this helps some.

Sounds like fun

Kurt

1 Like

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.