Skip to content

boards: disco_l475_iot1: fix arduino_i2c assignment #88560

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

glenn-andrews
Copy link
Collaborator

@glenn-andrews glenn-andrews commented Apr 13, 2025

0f05f58 assigned the arduino_i2c to the incorrect pins for the Arduino UNO connector. This assigns them back.

Fixes #88558

zephyrproject-rtos@0f05f58 assigned the `arduino_i2c` to the incorrect pins for the Arduino UNO connector. This assigns them back.

signed-off-by: Glenn Andrews <[email protected]>
@glenn-andrews glenn-andrews requested a review from kartben April 13, 2025 13:49
@glenn-andrews glenn-andrews added bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 labels Apr 13, 2025
@github-actions github-actions bot added the size: XS A PR changing only a single line of code label Apr 13, 2025
@glenn-andrews glenn-andrews added the backport v3.7-branch Request backport to the v3.7-branch label Apr 15, 2025
@kartben
Copy link
Collaborator

kartben commented Apr 15, 2025

Sorry that I broke this, and probably better to revert at this point.

FWIW I was actually using a shield (https://www.mikroe.com/arduino-uno-click-shield) with effectivley a Uno R1 form factor (it doesn't even have D18/D19) and for which I2C is expected to be on A4/A5.
It almost feels as if we need to add a dt binding for Arduino Uno R1 headers in addition to R3 that we have right now to avoid these kind of issues in the future, and possibly that shield I MikroE shield should not "pretend" it's Uno R3 compatible (or the issue is STM32 specific and it should not have D18 D19 expose something different than A4/A5 if the expectation for R3 is that they're effectively the same)

image

@erwango might be able to comment or pull in folks that know

@glenn-andrews
Copy link
Collaborator Author

I think you're right in adding an Arduino UNO R1 binding as well as the existing R3 binding

@glenn-andrews
Copy link
Collaborator Author

And this looks like the updated R3 click shield ;)

https://www.mikroe.com/click-shield-for-arduino-uno

@mathieuchopstm
Copy link
Collaborator

Sorry that I broke this, and probably better to revert at this point.

FWIW I was actually using a shield (https://www.mikroe.com/arduino-uno-click-shield) with effectivley a Uno R1 form factor (it doesn't even have D18/D19) and for which I2C is expected to be on A4/A5. It almost feels as if we need to add a dt binding for Arduino Uno R1 headers in addition to R3 that we have right now to avoid these kind of issues in the future, and possibly that shield I MikroE shield should not "pretend" it's Uno R3 compatible (or the issue is STM32 specific and it should not have D18 D19 expose something different than A4/A5 if the expectation for R3 is that they're effectively the same)

I would argue the answer to the question is on this very diagram, which only lists I²C as available on pins D18/D19. On the other hand, the Arduino Uno R3 datasheet does specify that D18/D19 are duplicated A4/A5, at page 11.

I don't know if there are official guidelines from Arduino about which pins shields should be used for what purpose, but I would remark that all official Arduino shields listed as compatible with Uno R3 use D18/D19 for this purpose - see schematics.

To answer your second question, I would argue that the question should really be "why are D18/D19 shorted to A4/A5 on Arduino R3?", the answer to which becomes obvious when looking at the ATmega328p's pinout 🙂
image
(To answer more seriously: as far as I know (i.e., this is not an official statement from ST), D18/D19 and A4/A5 are routed to different pins (when possible) because this allows using more peripherals at the same time)

TL;DR: in my opinion, this is a shield issue for using A4/A5 rather than D18/D19.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport v3.7-branch Request backport to the v3.7-branch bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32 size: XS A PR changing only a single line of code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

disco_l475_iot1/arduino_r3_connector.dtsi arduino_i2c should be i2c1
4 participants