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.