Two i2c on mkr connection carrier

Hi.

I have an arduino arduino-mkr-wifi-1010, with its arduino-mkr-connector-carrier.

My question is: can I connect 2 i2c devices to the carrier? I just connected the Grove-Laser_PM2.5_Sensor-HM3301 to TWI on the arduino-mkr-connector-carrier, and don´t know if I can connect also the Grove-VOC_and_eCO2_Gas_Sensor-SGP30. The arduino-mkr-connector-carrier only has one TWI port.

Thanks.

Thanks.

In human words, yes, I can only connect one I2C device, and I need a Hub. Connecting I2C devices to the A0, A1, ... or D0, D1, ... , or SERIAL ports does not work. Is that right?

Thanks to all :slight_smile:

ardweb:
Thanks.

In human words, yes, I can only connect one I2C device, and I need a Hub. Connecting I2C devices to the A0, A1, ... or D0, D1, ... , or SERIAL ports does not work. Is that right?

Thanks to all :slight_smile:

SAMD21 can mux pins and can have more I2C interfaces configured so it would be possible to configure it to some pair of pins, but all the other connectors on the Carrier are attached to only one pin so you would be unable to use them with one Grove cable for I2C.

you can wire a second I2C device directly to the pin header of the MKR

note: the Grove connectors om the Carrier connectors supply 5 V on Vcc pin, the signal pins of D connectors go over logic level conversion. the A pins have voltage dividers to convert 5 V input to 3.3 V. and the A pins have a capacitor which has effect on analog readings

sorry for first link only comment, but too many OPs don't come back to read the comments so I make the first comment usually very short

Note that I2C is a bus. You can connect many I2C devices to a single bus. They only need to each have a unique address (which your I2C devices do). So the only difficulty is in how to electrically connect your modules to the pins on the carrier (or the Arduino board). There's absolutely no magic to that Grove I2C Hub. It's just 4 connectors connected together on a PCB.

Juraj:
SAMD21 can mux pins and can have more I2C interfaces configured so it would be possible to configure it to some pair of pins, but all the other connectors on the Carrier are attached to only one pin so you would be unable to use them with one Grove cable for I2C.

What about the Serial Grove connector? That one is connected to pins 13 and 14 on the Arduino.

Thanks Juraj.

Ok. I started two months ago using Arduino... In fact, I have an arduino-mkr-env-shield on top of the arduino-mkr-wifi-1010.

you can wire a second I2C device directly to the pin header of the MKR

Ok. This is good. But how? I have been looking, but haven't seen any easy example. Can you post any example. Can I connect them directly to the pins, or do I need any resistances?

pert:
What about the Serial Grove connector? That one is connected to pins 13 and 14 on the Arduino.

Thanks. I just saw your comment.

I connected my I2C sensor 2.5ppm dust sensor to the serial port and got an connection error. Should that work?

My second I2C sensor is an Seeed Air Quality Sensor. I have some trouble getting it to work. When I get it working, I will try it on the Serial Port.

Per, noted that the Serial connector has both pins in connector on Carrier. that is true and I omitted it as simplification, but that doesn’t make the connector an I2C interface. you would have to configure SERCOM as I2C on this two pins

I recommend to use the ‘hub’ or a Grove Y cable. For the wiring to the header you would need a Grove to 4 pin male cable

In Europe Distrelec and Kiwi Electronics have the Seeed Studio Grove products and low shipping costs and time.
And I recommend the 5 cm Grove cables for compact prototypes

now I see that the Wire library supports a second interface. but will the library for the sensor use it?

scroll to "Create a new Wire instance"

Just to be clear, my last reply was a question "can it be used?", rather than a statement "it can be used".

I haven't had any experience with SERCOM yet. To get started, I just tried the stock example provided on that page, setting up another I2C interface on pins 0 and 1, with an I2C scanner sketch and haven't even gotten that one working yet! It's not yet clear to me whether it's possible to set up an I2C interface on pins 13 and 14. The tutorial sent me off to the datasheet for that information and what I found there wasn't very clear to me.

I suppose another option would be to do software I2C on pins 13 and 14 if hardware I2C isn't possible.

Then of course there's the question of the library. In a perfect world, it would be set up so you can just pass the object to the library so it can use any interface. Neither of the Seeed libraries are written that way. The HM3301 library should be fairly easy to modify. The other one looks a bit more complex, but you only need one of the libraries, so that isn't the end of the world. There also might be other 3rd party library alternatives that have a more flexible design.

I'll report back if I make any progress.

pert:
I'll report back if I make any progress.

Per, did you adapt to European time zone or dropped sleeping at all?

Thanks to everybody!!! You are really amazing.

I think, I will go the easy way and purchase some i2c hubs.

Last question: Is it possible to just cut a pair of i2c cables, and drill them together as an Y-cable, like the old fashion way. I just don't know...

ardweb:
Last question: Is it possible to just cut a pair of i2c cables, and drill them together as an Y-cable, like the old fashion way. I just don't know...

yes

Juraj:
Per, did you adapt to European time zone or dropped sleeping at all?

Haha, I'm a night owl. It actually works out well now because I end up keeping the same hours as the Arduino team in Europe.

I got the I2C interface working fine with pins 0 and 1, but no go on pins 13 and 14. That makes sense because table 28.4 says that PAD[0] is SDA and PAD[1] is SCL, while pins 13 and 14 are PAD[3] and PAD[2] of SERCOM5.

I also saw that table 7-5 shows only a handful pins (which don't include 13 and 14) that support I2C Hs mode, but I'm not sure that is relevant because I don't think it excludes those pins for normal I2C mode.

The part that doesn't make sense to me is that, while I can use SERCOM3 on pins 0 and 1 for I2C no problem, I can't do the same with SERCOM5 on pins 0 and 1, even though they are also PAD[0] and PAD[1] of SERCOM5. I couldn't find anything in the datasheet that indicates SERCOM5 doesn't work with I2C.

Well, at least I have some familiarity with the subject now.

pert:
I got the I2C interface working fine with pins 0 and 1, but no go on pins 13 and 14. That makes sense because table 28.4 says that PAD[0] is SDA and PAD[1] is SCL, while pins 13 and 14 are PAD[3] and PAD[2] of SERCOM5.

I also saw that table 7-5 shows only a handful pins (which don't include 13 and 14) that support I2C Hs mode, but I'm not sure that is relevant because I don't think it excludes those pins for normal I2C mode.

The part that doesn't make sense to me is that, while I can use SERCOM3 on pins 0 and 1 for I2C no problem, I can't do the same with SERCOM5 on pins 0 and 1, even though they are also PAD[0] and PAD[1] of SERCOM5. I couldn't find anything in the datasheet that indicates SERCOM5 doesn't work with I2C.

Well, at least I have some familiarity with the subject now.

try
pinPeripheral(0, PIO_SERCOM_ALT);

PIO_SERCOM, /* The pin is controlled by the associated signal of peripheral C. /
PIO_SERCOM_ALT, /
The pin is controlled by the associated signal of peripheral D. */

That did it for using SERCOM5 on pins 0 and 1. Thanks! Still no joy with pins 13 and 14, but that's not a big surprise.

pert:
That did it for using SERCOM5 on pins 0 and 1. Thanks! Still no joy with pins 13 and 14, but that's not a big surprise.

28.4 Signal Description
Signal Name TypeDescription
PAD[0]Digital I/O SDA
PAD[1]Digital I/O SCL
PAD[2]Digital I/O SDA_OUT (4-wire operation)
PAD[3]Digital I/O SCL_OUT (4-wire operation)

Thanks, yes, that's the table 28.4 I mentioned earlier. That information is the reason I said "not a big surprise".

Anyway, I think the best solution for @ardweb is to connect all the I2C devices to a single bus, but it's fun to try to find alternate solutions.