11 replies to this topic

[crawf]

Just wondering if anyone has had experience with using I2C with the Netduino Plus? Specifically, I'm wanting to use the GainSpan GS1011 module with my Netduino Plus, but instead of talking via UART (as brilliantly shown in this post - http://forums.netdui...4-netduino-wifi), I'd rather use I2C if possible, as I'd like to fully utilise all the Plus' digital pins for my project (or at least future-proof needed extra pins). Does anyone have a good starting point for talking I2C (not necessarily with a GainSpan module) - I literally have no idea where to start. Thanks!

[crawf]

I guess that means no one then?

[carb]

Crawf,

I have not use I2C, just haven't had the need to yet.

But seeing you are using a Netduino Plus have you considered using a Wifi adapter on the ethernet to the Netduino Plus.

I have been using one from IOGear GWU627 that works very well. I takes cares of the security, WPS setup and comes with a 5 vdc 1 amp power supply or an adapter to power form USB port.

Chuck

Attached Files

•  07-01-12 21-17-41.jpg   15.55KB   11 downloads

[crawf]

Hi Carb, Thanks, I'll have a look into that - although was looking for something a little smaller. A good backup option however. Also, I've since opted to go with UART communication - it just seems to be easier and what everyone else is doing. Using I2C, every response seems to return with a value of 0 - so must be doing something wrong.

[skyjumper]

I'm a big fan of I2C, maybe I can persuade you to try again. Your problem is probably in your code. Its difficult to debug I2C when you don't know what's actually being sent on the bus. If you get a logic analyzer, you'll be able to see what you're actually sending on the bus and what the slave is returning. Another option is SPI, which the GainSpan module supports and which is also a great option. You can use a logic analyzer for this as well. I'm planning to do exactly the same thing you're doing. But I have no option to use a UART, so I'll be digging in soon.

[crawf]

I'm a big fan of I2C, maybe I can persuade you to try again. Your problem is probably in your code. Its difficult to debug I2C when you don't know what's actually being sent on the bus. If you get a logic analyzer, you'll be able to see what you're actually sending on the bus and what the slave is returning. Another option is SPI, which the GainSpan module supports and which is also a great option. You can use a logic analyzer for this as well.

I'm planning to do exactly the same thing you're doing. But I have no option to use a UART, so I'll be digging in soon.

I was a fan of I2C - until it wasnt working! Haha

I've actually since switched to a WiFly RN-XV, purely to get a prototype of my project. However, the Gainspan module is still on the cards, provided I can get I2C working.

From what I can tell, I think I'm approaching the problem for the wrong angle. Also coupled with a lack of documentation for how to get things done with I2C (plenty of info available for UART and AT commands).

Below is what I've got so far - a simple read of a register:

            using (I2CDevice Device = new I2CDevice(new I2CDevice.Configuration(0x700, 100))) {
                // can't figure out what register to ready from, so try a few!
                for (byte j = 0; j < 255; j++) {
                    byte[] data = new byte[1]; // We want to read one byte

                    // Create a new Transaction
                    I2CDevice.I2CTransaction[] xActions = new I2CDevice.I2CTransaction[] {
                        I2CDevice.CreateWriteTransaction(new byte[] { j }), // We want to read from memory address ...?
                        I2CDevice.CreateReadTransaction(data) // We want to read one byte
                    };

                    if (Device.Execute(xActions, 1000) == 0) {
                        Debug.Print("Failed to perform I2C transaction");
                    } else {
                        Debug.Print("Register value: " + xActions[0].ToString());
                    }
                }
            }

From the docs, I've determined the starting address for the module is 0x700 (at least I think that's correct!). However, I was confused by what registers I'd need to read, so I'm looping through all available.

[CW2]

Could you please provide a link to the module I2C communication documentation? I have lost my patience after two failed attempts to register at Gainspan website (why on Earth someone needs to "review your application" to download a programming manual !?). I think there could be two problems: 1) The current I2C implementation supports only 7-bit slave address (there should be an argument exception as 0x700 is out of range), 2) The combination of Write+Read operations to specify the register/memory address to read from may indicate the need of I2C repeated start condition, which has to be done via special I2C methods with internalAddress parameters.

[crawf]

Could you please provide a link to the module I2C communication documentation? I have lost my patience after two failed attempts to register at Gainspan website (why on Earth someone needs to "review your application" to download a programming manual !?).

I think there could be two problems:

1) The current I2C implementation supports only 7-bit slave address (there should be an argument exception as 0x700 is out of range),

2) The combination of Write+Read operations to specify the register/memory address to read from may indicate the need of I2C repeated start condition, which has to be done via special I2C methods with internalAddress parameters.

Hi CW2,

I'd love to help out, but unfortunately, I've had to sign an Non-Disclosure Agreement with Gainspan, and as such, I can't give out any of the documentation without voiding the NDA.

Really sorry mate (it really does suck)!

[CW2]

I've had to sign an Non-Disclosure Agreement with Gainspan, and as such, I can't give out any of the documentation without voiding the NDA.

Ok then.

So, I would try the communication over I2C with 7-bit slave address (note in .NET MF it does not include the R/W bit, contrary to most Arduino I2C code), starting with something that does not require the register address. If you manage to get a response to a simple transaction, continue with register access (refer to the documentation if the repeated start is required and choose the appropriate methods), otherwise you'd probably need a logic analyzer to see what's happening on the signal lines.

Fingers crossed.

[crawf]

Thanks CW2, I'll give it another crack! Again, sorry for not being more helpful..

[Nobby]

Hey crawf, I'm about to head to bed so I'll read this thread tomorrow. Judging by your code, the methodology is fine. I use I2C comms with a GPS unit and i've tried various approaches to see how flexible the API is. The main points you need to know: -When you perform a write operation, .Net will ALWAYS provide the device address in the transaction, you don't have to add this to the byte[](not that you are but just so you know) -When you perform any transaction, if zero actions are returned from Execute(), this means that communication to the device failed completely. This has nothing to do with register addresses -.Net handles all ACK & NACK signalling(comms interlocking). The number of ACKS & NACKS returned by the slave device determines the return value of Execute(). -You can't simply read a single byte in a transaction. The data you read from a target register needs a destination array large enough to fit it. If you don't know the size required, give one sufficiently large enough. The remaining bytes in the array are set to zero(or a value defined in the device documentation).

[crawf]

Hey Nobby, thanks for the awesome tips, they're really helpful!