Which I2CBus implementation to use ?

Hi There, I found many I2CBus implementation to use ... which one should I use ? Any reason why ? Is it planned to include such a class into the SecretLabs.NETMF.Hardware name space ? Should it be ? Here are some links to the implementation I found : http://forums.netdui...ndpost__p__4156 http://forums.netdui...ndpost__p__6090 Mike perplexed by all this

I2C functionality is already built into NETMF. These two examples you link to are just wrappers for the I2CDevice class in the framework. You can use the built in I2CDevice or either of these wrappers, it doesnt matter. The wrapper just allow easier managment of I2CDevice instantance if you are interacting with multiple I2C devices on a single bus. My wrapper implements the singleton pattern which allows for thread safe interaction with multiple devices on the bus.

My wrapper implements the singleton pattern which allows for thread safe interaction with multiple devices on the bus.

Your implementation it is then ! Thanks for sharing !

Your implementation it is then ! Thanks for sharing !

I think Jon Skeet would argue that nested classes probably would have been the appropriate way to implement a singleton pattern. Change as you see fit and enjoy!

Some drivers have already been written for each of the different i2c shared bus implementations. I wanted to use the BMP085 barometric pressure sensor and the DS1307 real time clock. One of the drivers uses Phantom Typist's shared bus and the other uses FusionWare's. I'm too lazy to rework the drivers for one bus or the other, so I thought I'd just try to get the two shared bus implementations to cooperate. The hack is running and seems to work. In a nutshell, I changed FusionWare's I2CBus.Device from a field to a property with "get { return NetduinoPlusTesting.I2CBus.GetInstance()._slaveDevice; }". This necessitated that _slaveDevice be public, which is a bad thing. But, in the end, it seems like I can now use drivers written for either shared bus class without any modifications to individual drivers. Also thought about re-implementing one of the shared bus classes as a wrapper around the other, since that would be less offensive from the perspective of object-oriented design, but the hack in the previous paragraph seemed so much simpler.

Kind of defeats the purpose of the Single Responsibility Principle doesnt it? Just take a few minutes reworking the drivers you have to work with either of the I2C wrappers. Its an edumacational experience, you'll understand what is going on and you'll also save flash and ram space by not using two wrappers that do the same job.

Kind of defeats the purpose of the Single Responsibility Principle doesnt it?

Just take a few minutes reworking the drivers you have to work with either of the I2C wrappers. Its an edumacational experience, you'll understand what is going on and you'll also save flash and ram space by not using two wrappers that do the same job.

I agree... Just have all sorts of other educational experiences to pursue first with this project. Flash space doesn't seem to be an issue yet, so this goes on the back burner. Never having even heard of i2c before last week, I'm just glad that I got my sensors hooked up and working on the first try. My thanks to you and the others who contribute code here.