Now, the only thing that is left is the touch pads. I would really, really, [em]really [/em]like to see them abstracted somehow. This is the only thing that is not compatible with vanilla-NETMF. Such compatibiity would be really great.
Can you model them as simple buttons? I know they have an analog threshold component, but most folks will use them as simple pushbuttons - either pressed or not-pressed.
I cannot fake it, because it requires PulseFeedback class, which sits in GHI.Hardware.dll, which cannot be loaded into emulator (at least Iām not aware of how that could be done).
It has to be compiled away. Either removed completely, or with #if directives. Gus will veto the first option, and Iām not sure the second option can be done silently in the backgroundā¦
What happens if you load PulseFeedback and the supporting assembly into the project, but never call it? If no constructors are called and there is no static initialization that relies on firmware, then it should sit there inert and you can use your same isInEmulator trick to call an alternate implementation.
[Edit: Just looked at the BrainPad source and it does initialize a static PulseFeedback. That would need to be made a lazy initialization. Move the initialization into a EnsureInitialized() method and call that method in every static member function. That function can do the correct initialization depending on whether you are in the emulator or not.]
The only solution that comes to mind is fairly complex : remove references to PulseFeedback in the BrainPad.cs file and move them into an interface-defined wrapper class. Create two assemblies with separate implementations of the wrapper definition - one that uses PulseFeedback and one that uses a non-PulseFeedback emulator class. At runtime, use the BrainPad class and isInEmulator to dynamically load the correct class. Use dynamic loading to avoid the static class constructors being called when in the emulator. GHI.Hardware wonāt be initialized until it is dynamically loaded, which will never happen in the emulator.
[Edit: GHI.Hardware needs to be in the deployment manifest, but not referenced in the main program. Itās not immediately clear to me if thatās possible without stepping outside of the normal VS workflow - it may complicate things for the end user in an unacceptable way. Mechanically, this approach will work, but it may not be practical]
@ mflume - Iāve stopped working on it because I was unable to find any easy solution for touch pads, which canāt really be emulated. Without them, emulator is not complete and I thus have no hope GHI would include it somehow in their SDK or teaching materials. Also, Iām not good at legal stuff, and so I did not release it publicly because I did not know how to decorate the driver code that I borrowed from GHI. But I could probably send you the whole project privatelyā¦
@ Simon from Vilnius - touch pads were removed from the new brainpads. More details on why this happened this in few days. Everything else is near identical. Your emulator is most welcome. We would love to add it to the brain pad support page if you are willing to share.
@ Gus - Alright then this changes things. Combined with the vsix project somebody uploaded a few days ago, we could make quite a solid BrainPad support packageā¦
EDIT: Iāll just wait for those few days before doing anything, then.