Fix Read/Write in System.Device.I2c

[AdrianSoundy]

Description

Fixes issues when a null parameter is passed into nativeTransmit() method.
As the parameter is a SpanByte structure we don't get a null parameter but a SpanByte structure with a null array

Also found an issue with the I2cTransferResult return type. If Windows.Devices.I2c assembly not loaded then it couldn't find type.
Added new I2cTransferResult for System.Device.I2C and renamed variable for one used by Windows.Devices.I2c
m_I2cTransferResult -> m_I2cTransferResult_old.

The Windows.Devices.I2c I2cTransferResult can be removed once no longer used.

Motivation and Context

• Fixes System.Device.I2c hangs at device.write(buffer) Home#659

How Has This Been Tested?

Tested on ESP32 only with nf_ssd1306 supplied test program for writes
and a BMP280 test program for reads

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[nfbot]

Hi @AdrianSoundy,

I'm nanoFramework bot.
Thank you for your contribution!

A human will be reviewing it shortly. 😉

[nfbot]

@AdrianSoundy there are issues with the code style on the source files.
A PR was submitted with the code style fixes. Please review and merge the changes. See https://github.com/AdrianSoundy/nf-interpreter/pull/15.

Make sure you are using the project code style. Check the details here.

[josesimoes]

Notes for future reference.

The root cause for this "misbehaviour" is that SpanByte it's a struct (value type) therefore can't be assigned a null.
In this case when we were checking with "is the object null?" is, in reality, if it was assigned (which it wasn't obviously).

To be syntactically correct we would have to:

1. allow nullable types
2. declare SpanByte as nullable
3. check for SpanByte.HasValue

The fix in this PR works because the _array field is null on a "new" SpanByte which is what's actually being passed in the stack at Arg1 position, after the call to ldnull to load a pseudo null SpanByte.

cc @Ellerbach @krwq

[Ellerbach]

The fix in this PR works because the _array field is null on a "new" SpanByte

Yes, that's the expected behavior. The way to check if there is something is on _length, if _length == 0 then the array is empty
So for the array is empty, then don't try to get it out as most likely (but not necessary) the _array is null

[josesimoes]

With no further comments, let's have this merged.
Thanks for the quick fix!