Thread: Low Level Interface Protocol

Also C# source code: http://www.fusioncontrolcentre.com/MDX/Source/

Would this help any?
http://uniquelycommon.com/extern/Fus...usionBrain.zip

Its a C# project creating a DLL (like FusionBrain_WinUSB.dll) that allows for creating FusionBrain objects where you can call functions to set ports on/off & read values without needing to know the bytestream. Detection of Fusion Brains is done through a FuBrainCollection (.detectAll() ) which keeps track of all the inputs & outputs, and allows the same functionality to change them through the collection without needing to know which specific board its on (though that information is available through .outputPortLocation(int port) returning int[]{board, port})
Also, time saving of data transfers is used: calling .setOutputOn(channel) doesn't tell the board to do that until .sendRecieve() is also called, allowing for multiple channels to be toggled quickly/in sync. If one channel at a time is desired, use the .setOutputOnNow() method.

A few important notes:
* I only have a v3 board right now, v4 (& esp. v6) functionality is untested but my best guess I got a v4 board! I did encounter some problems, but I'm almost done fixing them.
* I haven't had too much experience with the FusionBrain_WinUSB.dll that my FusionBrain.DLL references, so I might not call the proper disconnect functions, etc. that should be called (if there's anything I should know, pls tell me!!)
* I've tried to keep uniformity throughout each FusionBrain3, FusionBrain4, FusionBrain6, etc. classes. Just because FusionBrain3 has a .setPWM() doesn't mean it dims, but trying to use it will turn the output on/off (50% or higher, lower). Each class does have a .isPWMCapable() to tell your program, regardless of FusionBrain version.
* The classes are almost (~98%) fully functional, but aren't complete. Ex, you can turn outputs on and off, but setting the timeout portion of the channel isn't added in yet. (time functionality added, keepAlive not) You can get the major version number from the software, but getting it (major & minor) from the board itself isn't in there...yet
* Halfway through the coding I switch from ports being, for example, 0-11 to 1-12 to keep in line with hardware labels. If a different port toggles on, this might be why (haven't had too much time to go back through yet again ) All fixed, use 1-12 notation (reasoning: new users are more likely to use that notation)

Please give any/all feedback if you try it out/look at it. I guess the idea is that these classes get added right into FusionBrain_WinUSB.dll so more people can start using the FusionBrains quicker without needing to know hardware specifics.

A previous project I using this code:
lightsequencer-retrofit-demo
Look at HardwareHandler.cs You can see how easy the FusionBrain portion becomes, most of the code is retrofitting the existing Coding4Fun project that was designed around more complicated, but less capable, hardware

A sample quick'n'dirty implementation is here:
http://uniquelycommon.com/extern/Fus...ntrolTest1.zip
(Used just to test what's going on)

On both you'll need to link to the DLL's mentioned (FusionBrain to FusionBrain_WinUSB.dll and ControlTest1 to FusionBrain.dll)

Thanks!
(This is why I've been asking so many annoying questions, sorry)

UPDATE:
ha ha, I was running through the LightSequencer and remembered the output port quirk for v3 boards. Now there is a .setOutputCorrection(true/false) function to accommodate this insertion of fun by default .setOutputOn(1) sets the hardware output at pin 1 on (and the LED at 4)

DLL updated after testing with v4 hardware (many much more commenting for easier understanding)
(same link)
I do need to make a sample implementation though... next on the busy to-do list

(Perhaps I should have made these a different thread instead of replies in this one? )

UPDATE: Fixed bug in setting PWM for v4 boards, thought it was 8 bit instead of the actual 7 bit (PPPPPPPD, P=PWM bit, D = digital bit, thought the D was also a P depending on the mode bit in the second byte)
Also rewrote the class inheritance setup, each version class is much smaller

(If anyone tries: even if the PWM mode bit is set, if the digital on bit is set the PWM mode is ignored and the port becomes a digital on. Discovered this as every 8 bit odd number would set the LED full on, whereas 8 bit even numbers would act "normal". Changing the PWM bits to 7 solved the every-other problem. This might be an interesting shortcut to switch a port to digital on without losing PWM setting data (just clear the digital on bit and back to PWM ). Just an idea for v6: if the PIC is capable of 8-bit PWM, the digital bit could be also be used for PWM. 7-bits seems to be plenty (127 degrees of freedom ) but I know the Arduino uses 8 bit. Though, on the flip side, it does seem to add some safety to the interface to seperate the digital on/off bit from the PWM bits. IDK :P )