Main Site Documentation

Software I2C(SDK Version 1.0.16)


Lets try again… :slight_smile:

Seems that SoftwareI2CBus.I2CDevice does not inherit from Hardware.I2CDevice? Or am I missing something? This makes it hard to develop drivers that work on either Hardware I2C or Software I2C…


I would make two wrappers for each I2C implementation confirming to a common interface. Then in the driver I would use that interface and instantiate a proper wrapper based on my driver constructor parameter.


It would be nice if NETMF made better use of interfaces. A lot of these type of problems exist because of hardware specific implementations that should have been built around a common interface.


I am sure NETMF team is more than capable doing that. It is part of the “think small” thingy.


I guess software I2C was only added for gadgeteer purposes so we went the simple route. We are pressed on time anyways.

We can make this better in NETMF 4.2


Interfaces are a compiler “trick”. If done properly they shouldn’t really effect the size of the build. I think it has more to do with the fact that NETMF has historically been used by more “hardware” guys than “software” guys.


It is still adds to the size of an assembly. The more interfaces the bigger the size - less space for user apps on smaller devices.


@ Architect: But it adds less space than another wrapper… :slight_smile:

OK, I adapted the managed SoftwareI2C code from code site to have full compatibility with I2C transactions. This I did before I knew that native I2C was on the cards. It worked but was really slow.

Now i ripped out the core of the software I2C and replaced it with the new native I2C code. Everything workd REALLY fast now, but the WriteRead doesn’t seem to work. I write the ram address to the device, 4, then read 26 bytes back from the device. But it always starts reading at ram address 0.

I will analize the bus when I can, but I think that the WriteRead is a full write with stop followed by a full read. IE:



In stead of:




This was made fro gadgeteer which doesn’t need restart. We will look into adding this in future.



If it doesn’t need restart then what does the WriteRead command do? Why not just use a Write followed by a Read?

With the hardware I2C, it uses restarts between each transaction the moment you have an array of transactions, so this is used more that one would think…


We will try to improve in future. We did try memory based I2C devices and they worked fine without the repeat. Maybe your device doesn’t like this. Did you scope the I2C lines to verify this is the case?


Hi Mike,

I have not had a chance to analyze this further. Will try tonight, but I don’t have much free time in the evenings.

I did see that if I do a normal Write then a Read then I get the same problem. Looks like the chip clears it’s internal address on a Stop condition.

It’s manual doesn’t explicitly state that a restart must be used, but in their example they use a restart and no other way.

At this point I just read out all 128 registers every time I need to access something that isn’t at address 0, so I’m up and running, but it isn’t ideal… :slight_smile:

Will try to start a separate thread tonight on what I’m using it for… :slight_smile: