I’m trying to create an I2C channel by using DeviceInformation.FindAll and then passing the deviceId to the Device.FromId.
But starting from release 0.5 of the Device module DeviceInformation.FindAll throws NotSupportedException 
What is the recommended way of creating an I2C channel in this case?
I’m using all the latest libraries available (version 0.6)
Not really, I’ve been following that (sorry, should have mentioned that) instruction, but my device is not initializing properly.
Here is what I got when calling I2cDevice.FromId(…)
Later when I try to read it always return an empty (0) results:
I’m using FEZSpider + TempHumid SI70 sensor.
so, I will start by mentioning the non-GHI view - TinyCLR is still beta, so if in doubt, go back to netmf. I’d try to prove the device, in it’s as connected form, works with a netmf app. That can help GHI know that there’s a problem with TinyCLR if it works, otherwise we start looking at connections and cables and…
My apologies, I should have done a better job stating my problem.
I’m perfectly fine with using TinyCLR alpha. In fact I specifically installed a TinyCLR just two days ago to try it out. Mainly because it works with VS 2017.
I’ve tried communicating with the device using software I2C and it works but with glitches. The problem with software I2C is that it only supports clock frequency of 100 KHz at the moment, but device requires 400 KHz (hardware mode) and this causing some interesting fluctuations in the temperature readings 
My question is regarding the fact that before version 0.5 DeviceInformation.FindAll had an implementation:
This was done intentionally and it was documented in the release notes. What I was not able to find in the release notes is a correct/recommended way of initializing the I2C channel now.
Just want to make sure I’m doing everything by the book, before claiming that there is bug in TinyCLR OS
no, I think I mainly understood your point - but the test for you is run it in netmf and prove your setup works, or not - because one real simple way to get zeros back from a call to a device is to have the device connected incorrectly, and maybe I was saying nicely that you could check that (via another piece of code) But really, I can see nothing wrong with your approach, it matches the documented partial example, except for one thing… I expect that the FromId() first parameter is not intended to be a string, but I could be wrong… It is likely coming from GHIElectronics.TinyCLR.Pins, so check out what that is and see if you need to change what you pass?
I have rewrite a driver for this module:
Code source can be reviewed, or just take package.
But I agree with same limitation of 100kHz of software I2C.Although, I doesn’t notice fluctuation of readings.
The link from Gus is the correct way to use I2C. As Brett mentioned, the ID passed to FromId is expected to come from the pins library. If you want to rule out any possible TinyCLR issues, try NETMF to get it working and then convert to TinyCLR since NETMF has no known issues around I2C and is stable.
Regarding DeviceInformation.FindAll, it was changed to throw the exception in 0.6.0 since we re-architected a lot of the internal device code and didn’t have time to update FindAll. It’ll come back in a future release.
Regarding software I2C, the clock rate really isn’t super reliable since it’s all bit-banged. We do attempt some time keeping, but I wouldn’t be surprised if even 100KHz is way off. There’s more we can do here as well. We had 400KHz throw to not give the impression that fast and accurate speeds are possible in the current release.
This is a awesome library you have there! Thanks a lot for sharing it:slight_smile:
Your version indeed works well, and the reason turns out to be quite hilarious, it is this Thread.Sleep(20); that makes a difference. I actually had a delay there as well, but mine was 10 ms, which is not turns out to be not enough. (I was so close) 
When I changed my code to have 20+ ms delay it works like a charm.
Question on the side, why did you decide to move “TakeMeasurement(s)” on it’s own thread? Is it just for usability or there was some issue with a synchronous code?
@John_Brochue and @Gus_Issa, I think it is worth mentioning @Bauland libraries somewhere in the docs, for example on the modules page.
P.S. Love a DisplayN18 driver in your libraries! 
I try some values before finding this 
It was only because original code of Gadgeteer module by GHI is done as that. I would like module are closed to original to make transition easier.
I’m confused a bit, because I was looking into GHI code for TempHumidSI70 as well, and it does not involve threads. We’re probably looking into slightly different sources
