Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Electron Pinout PDF Clarification #310

Closed
kennethlimcp opened this issue Mar 11, 2016 · 14 comments · Fixed by particle-iot-archived/docs-old#312
Closed

Electron Pinout PDF Clarification #310

kennethlimcp opened this issue Mar 11, 2016 · 14 comments · Fixed by particle-iot-archived/docs-old#312
Assignees

Comments

@kennethlimcp
Copy link
Contributor

From the community: http://community.particle.io/t/electron-i2c-bus/20941/5

In the docs: https://docs.particle.io/datasheets/electron-datasheet/#pinout-diagram, the PDF has SCL/SDA wrongly labeled
https://docs.particle.io/assets/images/electron/illustrations/electron_pinout.pdf

@mohitbhoite
Copy link
Contributor

@kennethlimcp can you elaborate on the error? Currently the PDF says:
D1 - SCL
D0 - SDA
C5 - SCL
C4 - SDA
which is correct

@kennethlimcp
Copy link
Contributor Author

@mohitbhoite , not sure which PDF you are referring to but the latest one i get from master shows this:

screen shot 2016-03-12 at 08 20 57

They are offset by one pin...

AH...i think i know why now.... It's hard to tell whether to read the top or bottom label for that particular pin.... We are looking at D1 for SDA

@technobly
Copy link
Member

Confirmed the PDF is correct (and I'm still unclear what the PDF was being compared to that was "correctly" labeled as stated in the community post). It is impossible to know when looking only at these pins if the pin is above or below the label. You can look at B0 and C0 for a reference, and also D6 and D7 should be very clear. From these keys (and the labels on the sides of the headers) it should be fairly clear how to read the pins. That said, I would like to suggest an additional row of pin labels in the PDF pinout right next to the the pins on the pinout diagram. That'd be helpful, yeah?

incorrect_electron_pdf_ issue__310 _spark_docs

For reference:
screen shot 2016-03-11 at 9 12 05 pm

@technobly technobly added enhancement and removed bug labels Mar 12, 2016
@technobly technobly changed the title Incorrect electron pdf Electron Pinout PDF Clarification Mar 12, 2016
@ScruffR
Copy link
Contributor

ScruffR commented Mar 12, 2016

One thing I'm not sure about is why there are two set of pins when there is only one I2C bus and I can't find any indication in the docs to explicitly select which set (as is done for SPI via SPI1 or SPI2 and documented) - sure the reason is the same as for SPI3 if one set is occupied for other use (e.g. CAN2 for D1) you don't want to loose I2C and move to C4/C5. But how?
If they are wired parallel internally, would external circuitry on the "other" set not interfere?

Might be a dumb question, but I sometimes I'm a bit slow 😊

BTW: The reference docs only mention D0/D1 and not at all C4/C5 - maybe this is what the OP meant with the "correct info".
He might think the the tags next to C4/C5 are a copy-past artefact rather than getting confused by pin lables above/below.

@kennethlimcp
Copy link
Contributor Author

@technobly it's probably from this diagram - https://docs.particle.io/reference/firmware/electron/#wire-i2c-

@technobly
Copy link
Member

@ScruffR there is an alternate location on the Electron, just in case you need it. Hmm, I see the documentation is missing!! GAH. Essentially replace all of your Wire calls with Wire1. I'll update the docs, and get rid of that Core image for Electron docs... thanks @kennethlimcp

@technobly
Copy link
Member

@ScruffR updated I2C docs: 3d87c8e

@leo3linbeck
Copy link

So, a quick follow-on question:

Is it OK to use both Wire and Wire1 on the Electron? I have two sensors hardwired with the same I2C address (ugh) but I'm hoping that I can use one on Wire and one on Wire1. Does that make sense? Is that doable?

Cheers,
L3

@ScruffR
Copy link
Contributor

ScruffR commented Mar 12, 2016

@technobly, now it makes sense 👍
@leo3linbeck, I'd say not since there is actually only _one_ I2C interface which can be mapped to either the one or the other sets of pins.

@leo3linbeck
Copy link

@ScruffR,

I was afraid you'd say that.... I'm going to experiment and if I find anything interesting, I'll report back. Cheers,

L3

@ScruffR
Copy link
Contributor

ScruffR commented Mar 12, 2016

What sensors are you using?
Could you open a thread on community.particle.io to continue there?

@leo3linbeck
Copy link

OK, I'm getting confused, so I'm returning to the font of all Particle wisdom.

Here's my setup:

Two TCS34725 color sensors: SensorA and SensorB. They have identical I2C addresses.
I've connected SensorA to D0 and D1, and SensorB to C4 and C5 on an Electron.

I don't need to use SensorA and SensorB at the same time.

Seems like I should be able to call Wire.begin() on initialize SensorA, take some readings, call Wire.end() to release the pins, and then call Wire1.begin() to initialize SensorB, take some readings, call Wire1.end() to release the pins, etc etc etc.

But when I actually try to do this, it doesn't work. It appears both sensors stay active, and it actually takes the higher of the two sensors, which is kinda weird but that's what it's doing.

Seems like because SensorA and SensorB are on separate pins, I should be able to flip back and forth between the two interfaces. But maybe even though the pins are released, the sensor on the released pins is still connected.

Anyway, I hope this makes sense and that there is some way to switch back and forth between I2C pin pairs. Any help would be greatly appreciated.

Cheers,
L3

@leo3linbeck
Copy link

Oh, good idea. I'll move over to community.particle.io. Thx, L3

@mohitbhoite mohitbhoite self-assigned this Mar 14, 2016
@mohitbhoite
Copy link
Contributor

Updated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants