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)
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:
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?
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?