Using Microsoft IoT Library

I’m using a I2C Vl53L1X laser ranging device with SC13048 (FEZ Flea carrier board). I’m trying to use the MS library Iot.Device.Vl53L1X . Below is the code snippet…

using GHIElectronics.TinyCLR.Devices.Gpio;
using GHIElectronics.TinyCLR.Devices.I2c;
using GHIElectronics.TinyCLR.Pins;
using Iot.Device.Vl53L1X;

var settings = new I2cConnectionSettings(0x29, 100_000); //The slave's address and the bus speed.
var controller = I2cController.FromName(SC13048.I2cBus.I2c2);
var laserI2C = controller.GetDevice(settings);

var laser = new Vl53L1X(laserI2C);

cannot convert from 'GHIElectronics.TinyCLR.Devices.I2c.I2cDevice' to 'System.Device.I2c.I2cDevice'

laserI2C is GHIElectronics.TinyCLR.Devices.I2c.I2cDevice
Vl53L1X is the Microsoft Class

The Vl53L1X Sensor class is expecting the Microsoft I2C device but I’m working with the GHI I2C device.

Clearly there is some miss-match. I just can’t seem to make the I2CDevices play nice together.

Any ideas on how to use Vl53L1X class with I2C in TinyCLR?

Hi, these two I2C drivers come from different platforms, so the compiler can’t convert directly.

There are two ways you can do:

  • The original source of VI53L1X from Microsoft is here: iot/src/devices/Vl53L1X at main · dotnet/iot · GitHub. Download only their source code files (.cs files), add them to your project, or make new dll project and add reference to this dll, depends on how you want to organize your project source. There will be some errors because Microsoft use some API that TinyCLR doesn’t have as TinyCLR supports smaller devices, just replace them by the one TinyCLR has.

  • Use our Endpoint Endpoint – GHI Electronics. This is fully compatible with Microsoft IoT drivers, just use their nugets without changing.

Using option 1: it takes about 30min to 1 hour to convert, but you will have fun and you can discover something more about C# on embedded device (if you are new).
Using option 2: No need to convert code but if you don’t have Endpoint you have to order from GHI.

I recommend option 1, but if you plan to use Microsoft IoT drives without changing then option 2 is there.

Advance and disadvantage of SITCore and Endpoint can be found here: Compute Modules – GHI Electronics

We can help to convert with option 1 - just post here when you feel alone.

OK. Great! Thank you for both potential solutions.

This project is in the early development(proof of concept) phase for a commercial application. The goal is to use your SC13048 SoC so option 1 is the way to go. I used your G80 in a commercial application(banking) some years ago and it worked out great.

I looked through the cs files from the link you sent and it looks straight forward enough. I can see the library references being a potential problem but I’ll cross that bridge when I attempt to compile.

Before I started to muck with this, I did a quick test deployment with the code that was still opened and worked last night and I couldn’t deploy the code to the Flea board any more.

I got this error:

  • Link failure: some assembly references cannot be resolved!!

I started a fresh project and shaved down the code to one line while still getting the error. Then I started another fresh project with the skinny code and got the same error on deployment.

using GHIElectronics.TinyCLR.Native;
using GHIElectronics.TinyCLR.Devices.Gpio;
using GHIElectronics.TinyCLR.Devices.I2c;

var settings = new I2cConnectionSettings(0x29, 100000);

Attempt to deploy…

Loading Deployment Assemblies.

Attaching deployed file.

   Assembly: mscorlib (  Attaching deployed file.

   Assembly: GHIElectronics.TinyCLR.Devices.I2c (  Resolving.

Link failure: some assembly references cannot be resolved!!

Assembly: GHIElectronics.TinyCLR.Devices.I2c ( needs assembly 'GHIElectronics.TinyCLR.Devices.Gpio' (

Assembly: GHIElectronics.TinyCLR.Devices.I2c ( needs assembly 'GHIElectronics.TinyCLR.Native' (

Error: a3000000

All of the NuGet packages are there:

<?xml version="1.0" encoding="utf-8"?>
  <package id="GHIElectronics.TinyCLR.Core" version="" targetFramework="net48" />
  <package id="GHIElectronics.TinyCLR.Devices.Gpio" version="" targetFramework="net48" />
  <package id="GHIElectronics.TinyCLR.Devices.I2c" version="" targetFramework="net48" />
  <package id="GHIElectronics.TinyCLR.Native" version="" targetFramework="net48" />

Just to check my environment, I deployed “flash an LED” code to the Flea and it worked fine. I brought back the I2C code and got the same error. What am I missing???

Check the level of the firmware on the device.I believe this error means there is a mismatch.

I guess you have old firmware, GHIElectronics.TinyCLR.Devices.Gpio and GHIElectronics.TinyCLR.Native are old version, but GHIElectronics.TinyCLR.Devices.I2c is which is latest.

You need to make sure firmware is, GHIElectronics.TinyCLR.Devices.Gpio and GHIElectronics.TinyCLR.Native also need to be as well.

After all of them are updated to, if they still don’t work, try erase all → update firmware → deploy application again.

According to the NuGet Package Manager and packages.config, GHIElectronics.TinyCLR.Native and GHIElectronics.TinyCLR.Devices.Gpio are both v2.2.2.1.

I should have motioned in my original post that the firmware is also v2.2.2.1

I just checked it again with Config and the firmware is still v2.2.2.1

I tried erase all → then update firmware → then redeployed the one-line test app. Looks good. Redeployed the original app. Looks good…((exhale)). It works!

When I setup the environment for this project a few days ago, I updated the firmware and all libraries to the same version( (as per the Getting Started guide) .

I never would have guessed to reflash the firmware since the issue clearly seemed to be on the IDE/compile/deploy side. I thought I was back in DLL Hell for sure…a few more hours last night and I’d be watching it get light outside while trying to match GUIDs.

I guess going forward if everything looks right and nothing else works then reboot, recompile … and reflash. (…or just remember Error: a3000000!)

@Mike - Yes, it seems that Error: a3000000 is an indication of a firmware mismatch. When I Googled it last night, the search results were all relating to Visual Studio development of embedded applications(NetMF, nanoFramework, NetDuino, BartmanAbyss, etc). No matches for TinyCLR. After this post, there will be. :nerd_face:

In retrospect…I’m guessing this may have been caused by me referencing the Microsoft .NET I2C library and the GHI TinyCLR I2C library in the same project and/or in sequential projects/deployments in the same device. Par for the course in dev work I suppose.

Thanks for the help…

is it working now or still not yet?

Yes, it deploys fine now.

I guess I didn’t make that real clear in my previous post so I updated it.

What had me chasing my tail was when I deployed test code(blinking LED to test that the device was OK) which didn’t reference the I2C library, the deployment worked fine. When I refenced the I2C library in code and deployed, it didn’t work. This is what led me to the conclusion in the last paragraph of my previous post.