Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Idea: Line input
#11
(11-03-2021, 03:25 PM)robiwan Wrote: That is why it should be as an "interface" that Moode uses. Each card implements the switching as it needs to.

The nifty thing about a hardware abstraction layer (HAL) is that it makes writing applications easier because---duh---they don't have to know the details of the hardware. Of course someone has to decide and enforce the common API.

The not-so nifty thing about a HAL is that the sausage-making still has to be done; it's just hiding behind the HAL now. Someone has to develop and test the code which maps from the common API to a specific card's functions (e.g., 'implements the switching as it needs to'). Oh, and then support the code over time.

Not saying it can't be done (look at the Windows HAL and stable of drivers for example). Just wondering who's going to do the work. By virtue of its market position Microsoft can impose the burden on the card vendors. I don't see us having that kind of leverage. OTOH, I don't see the FOSS moOde team as being eager to write and support drivers on behalf of commercial vendors.

Just my two-cents worth.

Regards,
Kent
Reply
#12
I don't think its as low level as a HAL but more like a class definition or function set that allows the custom, device-specific switching code to plug into.

If I were a dev that wanted to code a device into the existing input switching sections of moOde I'd just do it directly rather than writing both an interface mechanism and the custom device specific code. Even directly coding a device is very time consuming because there are a lot of moving parts that have to be created/updated. I stopped after two devices because it became too time consuming (for me).
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#13
I hear ya. I'm not so wedded to the notion that a HAL has to lie at a very low level. (The HAL we used in LinuxCNC was at a comparatively high level.)

To me the conceptual difference between a HAL API and a class definition isn't much. They both abstract away implementation details and either way, code remains to be written and tested.

Regards,
Kent
Reply
#14
(11-03-2021, 07:00 PM)Tim Curtis Wrote: I don't think its as low level as a HAL but more like a class definition or function set that allows the custom, device-specific switching code to plug into.

If I were a dev that wanted to code a device into the existing input switching sections of moOde I'd just do it directly rather than writing both an interface mechanism and the custom device specific code. Even directly coding a device is very time consuming because there are a lot of moving parts that have to be created/updated. I stopped after two devices because it became too time consuming (for me).

The good thing about it is that the interface (and instantiation mechanism) is, ideally, only written once, and it makes it a lot easier to extend with new cards. This also allows distributing the burden of testing/maintaining, as long as the maintainer of moOde is willing to trust contributed interface implementation code Wink
Reply


Forum Jump: