I need some input here. For the pro version of my BIOS I want to move away from requiring the use of Skewworks IModule/IMainboard.
On the mainboard side that’s easy, they all have .MountStorageDevice. Creating and instancing module is easy too with reflection.
Where the issue comes in is using modules. Without the benefit of my ModuleType things become trickier. I can load many module on any mainboard from any manufacturer. But once they’re loaded the assumption is the user will want to deal with them. I could use reflection to offer up the methods with parameters. I could create a wrapper for a bunch of modules. Some other option probably exists too.
The point of FireBIOS is mostly for commercial users. Say your mainboard is discontinued, or your module, or you use different configurations for different applications and share core functionality.
Assume you can run any app you want straight from storage without worrying about Mainboard/Module (because you can) and also can update in field (again, you can). What would be your preferred way of going about things? Do you want FireBIOS to tell you modules and methods? Do you want a custom interface? The ability to write your own interface?
What does the community want? Ask and you will receive.
EDIT: This is available in headed and headless configurations. Events exist for just about everything so when I say any Mainboard/Module, I mean any. The Cerberus can handle FireBIOS.
Overview
The existing offering on NuGet ( NuGet Gallery | SKW-NETMF-SGB 1.0.3) allows you to load Gadgeteer Modules to a Gadgeteer Mainboard at run time and then launch an application. This application can be a native NETMF app or one using the Skewworks.NETMF.Applications interface.
All of these modules get thrown into a globally available manager so you can access them in your code.
The use for me is testing. I am constantly swapping screens and other components to test GUI packages or other apps. Rather than having to redeploy my app everytime, now I simply edit the XML file and everything runs.
The current BIOS also has an updater built in that allows you to update programs, drivers and firmware.
[title]What are the draw backs?[/title]
Right now the system uses my interfaces so you have to create a wrapper for every module. The benefit, of course, is it could be tooled to work with custom boards/modules and even ones that are not actually Gadgeteer. As long as it has a wrapper, it’s set to go.
[title]What is the future?[/title]
That’s what I’m looking to figure out here. Is it useful to anyone else?
Does this help companies that have had to deal with boards/modules being discontinued?
Should I move requiring Gadgeteer (which would cut down on driver requirements) or further way to allow even more expandability at the cost of it being a bit more technical to setup?
EDIT Attached are two images of the same program running on different mainboards with different screens thanks to the BIOS.
@ njbuch - Really no magic to it. The current version uses all my NuGet packages.
My HAL package defines interfaces for boards and many types of modules (display, network, USB, etc).
If you consume that Interface any compiled PE file you create can then be loaded by the system and exposed. The system itself is pretty stupid. All it knows is the contract. The wrapper you create handles any actual work which makes it swappable.
I already have drivers for all GHI LCDs, Ethernet, music, tunes, DFRobot RTC and others. I just call Assmebly.Load and type cast it to the appropriate interface. Presto.
Apps are the same. All standard NETMF apps have a signature and a Main method. I just load it and call it.
I think a good 80% of the code is actually in codeshare between different projects.
