Main Site Documentation

I2C - Sratching my head

#1

Hello Guys!

I’ve done a fair bit with I2C before however not before with Gadgeteer … basically I have a lovely sensor that is not talking to my mainboard.

I just need a sanity check in case I missing something :slight_smile:

Module building
It’s I2C so I’ve done type “I”, of course :slight_smile:
As with type I, pin 3 is GPIO and not shared where Pin 8 (SDA - data) is shared as is Pin 9 (SCL - clock)
Also included “Gadgeteer.DaisyLink” assembly reference for 2.4.2 builds.

Electronics
Should be all OK and I’ve check with my multi-meter on my breadboard … see picture.
VCC is getting 3.3V, Ground is grounded :slight_smile: Chip selected is tied high for the right address.
Both SDA and SCL are pulled high with resistors.
Also I’ve continuity from the breakout board pin all the way to the Gadgeteer pin.

Code
Originally tried to have all the code in the module, however as it was not working brought it into the program for quicker testing. I guess that makes the module part redundant :slight_smile:

GT.Socket socket = GT.Socket.GetSocket(
                    2,      // socked connected
                    true,   // throw if socket invalid
                    null,   // not part of a module
                    null);  // socket label

                ushort sensorAddress = 0x1D;

                i2c = new GTI.I2CBus(
                    socket,           // socket
                    sensorAddress,    // ADXL354 device ID
                    100,              // 100 Hz
                    null);            // not part of a module


                byte[] writebuff = new byte[1];  // write buffer
                byte[] readbuff = new byte[1];   // read buffer

                writebuff[0] = 0;    // want register 0 which is device ID

                int bytesTransfered = i2c.WriteRead(
                    writebuff,  // write register I want
                    readbuff,   // read data containing device ID
                    1000);

All looks relatively simple however no joy :frowning:

Question: Have I missed something obvious?

Thanks for your time!

David

#2

Thanks for the code quote tip … done :slight_smile:

Ordinarily did try without the pull-ups however no joy.

Haha, I thought you needed that Daisylink resource so it included the I2C. I guess it wasn’t doing any harm, thank you for the info!
Good eye too! Yes 100 kHz not 100Hz!

David

#3

Thanks Andre, good suggestion … I’ll try to isolate whether it’s the write or read causing the monkey business!

Thanks for your time!

David

#4

Some devices require that you use the writeread method, as the bus is behaving differently compared to a write then a read…

Anyway, is your address correct? You need to specify the address without the read/write bit, so you might have to shift the address one bit right…

#5

Try address 0x53

#6

Hi,
how did you connect the power supply for your I2C device?. Did you connect GND from the I2C device to GND of the mainboard? Which mainboard?

#7

Hi Gents,

Thanks for the great replies, give me confidence it will work … hopefully soon! :slight_smile:

Bit of extra background, I’m using an ADXL345 chip ( http://www.analog.com/static/imported-files/data_sheets/ADXL345.pdf ) mounted on a breakout board by LoveElectronics.

The SDO (alternative address) is high so the address of the ADXL should be 0x1D (page 18 of above link). Also got some handy code from LoveElectronics showing it should be that.

My mainboard is the Argon R1, again from LoveElectronics.

Cheers GMod, interesting that the WriteRead and Write then Read behave a little differently. This is definitely worth a try, thanks for the support!!!

Cheers Architect, I see that’s the address when the SDO is low … I’ll give it a go all the same just to be sure! Worth a check :slight_smile:

The mainboard is the ArgonR1. What I have is a module that then exposes the Gadgeteer pins so you can wire them into a breadboard. Handy! All the power and ground comes from the mainboard. I’ve double checked with a multi-meter and all the power (using 3.3V) are good as is the ground.

Very much appreciated all the support from everyone!

David

#8

If it’s the ADXL345, there’s a few code snippets in CodeShare already, for instance this one - they might help.

#9

May be that your board does not support GTI = Gadgeteer.Interfaces. I am not shure but I think that this is part of the GHI premium software boards. May be that you have to use software I2C.

#10

I2C is generic and supported by all boards…

#11

Try: ushort sensorAddress = 0x3A

Edit: Wrong advice

#12

Cheers RorschachUK … I’ll double check my code against it!!!

#13

I think that is the default address plus the extra write bit set low.

Perhaps my misunderstanding however, I thought with the .NET MF code you would give the normal address to the I2CBus constructor and then it would manage the extra read/write bit flag?

i2c = new GTI.I2CBus(
          socket,           // socket
          sensorAddress,    // ADXL354 device ID
          100,              // 100 KHz
          null);            // not part of a module


byte[] writebuff = new byte[1];  // write buffer
byte[] readbuff = new byte[1];   // read buff
                
writebuff[0] = 0;    // want register 0 which is device ID

int bytesWritten = i2c.Write(writebuff, timeOut);    // request device id on write
int bytesRead = i2c.Read(readbuff, timeOut);         // get the device id on read
#14

@ DavidYoung - Yes, I think you are right. 0x1D should be correct. The adress must be shift one bit right from 0x3A to 0x1D

#15

Hi,
did you connect SD0?.
https://www.loveelectronics.co.uk/Tutorials/10/accelerometers-and-how-to-use-them

“Ensuring that CS has been connected to VCC, and SDO has also been tied to VCC. Not connecting CS to VCC will mean I2C is not enabled, and the device will not respond. Not connecting SDO to VCC will mean the ADXL345 does not know which address it is at, and will not respond. Check all your connections and try again.”

#16

I2C in netmf ALWAYS uses the 7-bit address when setting up the I2C device.

#17

Thanks for all the help guys!

Bigger problems now … my lovely laptop hanged whilst uploading a program from Visual Studio.

Now the ArgonR1 mainboard. Unfortunately it isn’t even responding to MFDeloy.exe

Ummm, I fear the worst :frowning:

#18

First thing, don’t panic. Unlikely to have borked the entire board just uploading code and it failed to do so.

I would boot into bootloader mode, and erase the firmware and reapply it. I don’t know the R1 so I can’t tell you how to do that, but that’s my first tip, reapply the firmware from scratch should get you back up and ping-able from mfdeploy.

#19

Timely thread as I was learning a bit about I2C interfaces by coding up a TMP100 chip, this thread helped me get the changing of functions via writing to the register, Thanks.

#20

Thanks Brett, great to wake up and to find it might be OK … my wallet and I are much happier! :slight_smile:
I’ll contact Love Electronics and see what they recommend!