Using NI2C with C#

I have just added a sample in VB.NET of how to access NI2C. Please have a look if this can help you. Maybe you can even take this class, generate a DLL from it and use it directly from C#. However this is not fully tested and may still contain some errors. But it may serve as a steppingstone for your own implementation.

Regards,

H. Keller

Hello Mr. Keller,

I would like to know what exactly comes with the package NetDCU-SKIT-I2C.

If it is only the driver, I would like to known the availability of a C# bus I2C interface class (also like CanPort C# class for Bus CAN).

I think it is not something standard, please tell me if it would be possible to order it. (It is important to known time of availability and, of course, price)

Best regards,

Jose MATA
IFR Automotive

Currently it is only a set of two Win32 drivers. One for the Native-I2C (if available on the board) and one for simulating I2C over GPIOs. There is no C# class available. We can write such a class for you if you want. Please ask our sales department for the conditions.

Regards,

H. Keller

Hello Mr. Keller,

I purchased the Native I2C driver and a C# class interface to acces this bus.

I have a question related to how specify a subaddress.

The message headers structure are like this in the NetDCU8 device:
- byte chDevAddr, byte chFlags, ushort wLen.

But I want to comunicate by I2C to a texas instruments TPIC2810 device wich respond to the following needs:
- byte slave address, byte subaddress.
- byte data to slave

How can I specify the subaddress? Should I pass byte chFlags like byte subaddress?

Thank you very much in advance,

Best regards,

Jose MATA

Quote from "jmata"

The message headers structure are like this in the NetDCU8 device:
- byte chDevAddr, byte chFlags, ushort wLen.

But I want to comunicate by I2C to a texas instruments TPIC2810 device wich respond to the following needs:
- byte slave address, byte subaddress.
- byte data to slave

How can I specify the subaddress? Should I pass byte chFlags like byte subaddress?

This is just a problem of the used terms. If you say "Command" instead of "Subaddress", then it is easier to understand. When you look at the TPIC2810 data sheet at page 13, you find an explanation. The subaddress is just a data byte you have to send to the device, specifying what you want to do. Depending on this command byte you can send a value, read a value or just tell the device to switch something.

As address, you have to give G3 G2 G1 G0 A2 A1 A0 where G3 G2 G1 G0 is fix as 1 1 0 0 and A2 A1 A0 can be set by the appropriate pins of the device. Let's assume you have connected A2..A0 to GND, then the address is binary 1100 000. As last bit you have to append 0 for write and 1 for read. This brings us to the value of 0xC0 for writing to the device and 0xC1 for reading from the device. The possibility to modify A2..A0 allows for up to 8 of these TPIC2810 devices on one I2C bus. If each of them has a different combination of A2..A0, you can address each of these devices on its own address. C0/C1 for the first device, C2/C3 for the second device, and so on until CE/CF for the eighth device.

Now the different commands, the so called "subaddresses". This is explained on the next page, page 14. To write a value you have to send byte 0x11 and the value as second byte. Therefore from the view of the NI2C driver, you have to send two bytes of data in one message. This results in something like this, where XX is the data you want to send.

After the last command, you can check writeop[0].chFlags for errors during transmission.

The same format holds for command 0x44, just modify the writedata array. If you want to use command 0x22, change the wLen entry from 2 to 1 and prepare a writedata array with just the one byte 0x22.

To read the value, you have to send one byte 0x11 to the device as one message. Then as a second message, you have to read one byte from the device. Here you have to prepare two messages with each one byte for the NI2C, one send, one receive.

Here, readdata[1] is just a dummy value and will be filled in by the transmission. After this code, you can check readop[0].chFlags and readop[1].chFlags for any errors in the transmission. If everything is OK, you have the result , i.e. the byte that was read in readdata[1].

If you don't want your data to be overwritten in GetResult(), you can use different arrays there. However you have to make sure that they have exactly the same size as readop[] and readdata[] that you use in Schedule().

Regards,

H. Keller

Dear Mr. Keller,

First of all, thank you very much for your last answer.

As I found in the documentation, the NetDCU8’s pins for the bus I2C are J5 connector pin 10 (SDA) and 11 (SCL). They are GPIO.

But I did not find where I should connect the I2C bus SDA and SCL lines for use the Native I2C driver.

What I found is that using I2C driver (GPIO’s), the bus has a speed of 40 Khz, but with Native I2C driver is 200 Khz.

So, please, could you tell me where in the NetDCU8 should I connect the SDA and SCL lines of bus I2C?

Best Regards,

Jose MATA
IFR Automotive

Quote from "jmata"

As I found in the documentation, the NetDCU8’s pins for the bus I2C are J5 connector pin 10 (SDA) and 11 (SCL). They are GPIO.

Most of the pins of a microcontroller can support different possible functions. Therefore you can use these pins 10 and 11 for either GPIO purposes, or as dedicated I2C. Other pins can support other functions. If you use pins 10 and 11 for I2C, you have to exclude them from any access of any other drivers. Especially if you also use the DIO driver, you must set the corresponding bits of UseAsIo to zero (see DIO docu).

If you want to use NI2C, then these two pins are the only possibility to build the I2C bus. If you use the I2C over GPIO driver, then you can use any pair of GPIO pins on J5 to build an I2C bus, not only pins 10 and 11. This may be useful if you have many many I2C devices to connect and you need more than one I2C bus. If you just want to connect the above TPIC2810 device, I would recommend using NI2C and the commands given in my last posting.

Regards,

H. Keller