DaisyLink performance

Archive
1

Uodate: I was mistaken. Daisylink is in fact using native SoftwareI2C and not the managed implementation!

I have been looking at the DaisyLink protocol quite in-depth lately and one of the issues I see regarding performance is that the Hydra and Cerberus (probably others as well) do not provide a native implementation of the Software I2C for the DaisyLink protocol. This is unfortunate because the GHI firmware does provide a native SoftwareI2C implementation which could probably be leveraged to provide this implementation to the DaisyLink module.

So my question to GHI is, do you for see that you will provide an implementation of the SocketInterfaces.NativeI2CWriteReadDelegate on the Socket class? This would undoubtedly give better performance than relying on the current managed implementation, though

I do not know if any of the other Gadgeteer users are experiencing DaisyLink latency due to the reliance on the managed implementation, so the win might be very small, but I thought I would ask especially since 98% of the code is already there and probably only requires a few minor tweaks.

2

You already know my views…speed is King

3

I always thought that NativeI2C actually is hardware I2C. it is used if DaisyLink is connected go I2C pins, but I may be wrong.

4

I does not look like it. DaisyLink uses the SoftwareI2C class from Microsoft, this class, in fact the internal DaisyLink class derives from SoftwareI2C. The SoftwareI2C class will either use a local managed I2C implementation or if the mainboard provides an alternate implementation it will use that.

To provide the alternate implementation the mainboard class needs to provide a delegate of type [em]GT.Socket.SocketInterfaces.NativeI2CWriteReadDelegate[/em] and assign it to the [em]Socket.NativeI2CWriteRead[/em] when registering the mainboard sockets. Looking at the Cerb and the Hydra, the mainboards both set the delegate instance to null, in which case DaisyLink falls back to the managed implementation.

Too be honest, I have not really stepped through all this with the debugger, but just reading through the code this is how it all seems to fit together.

5

I see. Its been awhile since I looked at it. I agree with you about benefits using Native vs Software when it is available.

6

All our products use native implementation. We would not do it half way :slight_smile: Which is why we have native I2C implementation in premium and OSHW. So yeah, it is fast.

I think we did not set it properly on one of the board at some point but that was fixed long time ago.So, if you see something running managed I2C then this is an error and please let us know.

7

@ Gus - It seems we cannot trust the source on codeplex. The codeplex code of the Cerberus main board has the following (Similarly for the Hydra)


public FEZCerberus()
{
    // uncomment the following if you support NativeI2CWriteRead for faster DaisyLink performance
    // otherwise, the DaisyLink I2C interface will be supported in Gadgeteer.dll in managed code.
    GT.Socket.SocketInterfaces.NativeI2CWriteReadDelegate nativeI2C = null; // new GT.Socket.SocketInterfaces.NativeI2CWriteReadDelegate(NativeI2CWriteRead);  
    ...

    socket.NativeI2CWriteRead = nativeI2C;
}

Here the nativeI2C local variable is being set to null and assigned as such to the X/Y sockets.

The good news is that this is not the code that is actually running. After your response, I checked with reflector and I get the following


public FEZCerberus()
{
    this.debugled = new OutputPort(0x24, false);
    Socket.SocketInterfaces.NativeI2CWriteReadDelegate nativeI2C = new Socket.SocketInterfaces.NativeI2CWriteReadDelegate(this, (IntPtr) this.NativeI2CWriteRead);

That is great. Sorry for the confusion, it would be helpful if the codeplex code was more up to date. Whenever I want to understand something I first turn to the source code and I guess others might do the same. Not an excuse, I should have double checked, I have learned my lesson :slight_smile: