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
Add SCL and SDA defs for I2C[0-2]; redefine I2C_[SCL,SDA] to I2C2 #4102
Conversation
@bridadan |
@0xc0170 Could we tag the NXP maintainers in this one? |
@wdwalker do you plan on adding documentation? If not, could you edit the status and todo sections of the top comment to reflect the status and remaining todos of this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I like the small diff.
/morph test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
// Not connected | ||
NC = (int)0xFFFFFFFF | ||
NC = (int)0xFFFFFFFF, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this should probably be declared at the end of the enum. If someone came along and added a new pin, the enum may overflow (since enums increment from the last value). I'm not entirely sure what happens at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I just looked it up, the enum will just upgrade to uint64_t. It's up to you if you want it at the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving the NC to the bottom and removing the ,
would result in a smaller diff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing I was attempting to do here was use NC to indicate I2C0 was not connected on the LPC1768 and allow any error-checking code to kick in. In order to do that, NC needs to be ahead of these lines:
I2C_SCL0 = NC,
I2C_SDA0 = NC,
Alternatively, I could just omit these lines and leave NC at the bottom of the file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW - at this point in this particular file, it seems as though all auto-increment for the enum is pretty much done with and we're in a section where the rest of the enum items are forced to have a specific value.
clarification: the tag means that we are waiting on the continuous integration to finish. |
@bridadan morph test restart needed |
/morph test |
Result: SUCCESSYour command has finished executing! Here's what you wrote!
OutputAll builds and test passed! |
Hi there - this is only my second PR, so I'm not fully clear on the process. With the exception of the "needs CI" label, it looks like all is good (including the CI checks). What needs to be done to close this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure this is a breaking change, please see below
Please ignore 😄
I2C_SCL2 = p27, // pin used by application board | ||
I2C_SDA2 = p28, // pin used by application board | ||
I2C_SCL = I2C_SCL2, | ||
I2C_SDA = I2C_SDA2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure this is going to be a breaking change. I2C_SCL
used to follow this map I2C_SCL->D15->P0_28
. After these changes, I2C_SCL
will follow this map: I2C_SCL->I2C_SCL2->p27->P0_11
. I2C_SDA
is also following a different mapping. This will break any current application that use the I2C_SCL
and I2C_SDA
pin names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and I was completely wrong! I should have read your in-depth and very comprehensive analysis in #4099.
I think this change is perfectly valid and a welcome improvement. The current assignments appear to be bogus and are most likely a copy-paste error from the ARCH_PRO platform, which uses the LPC1768 MCU.
So, LGTM |
Ports for Upcoming Targets Fixes and Changes 4008: [NUC472/M453] Support Bootloader and FlashIAP ARMmbed/mbed-os#4008 4102: Add SCL and SDA defs for I2C[0-2]; redefine I2C_[SCL,SDA] to I2C2 ARMmbed/mbed-os#4102 4118: STM32F4 Internal ADC channels rework ARMmbed/mbed-os#4118 4126: STM32F4 : remove SERIAL_TX and SERIAL_RX from available pins ARMmbed/mbed-os#4126 4148: Revert "STM32F4 Internal ADC channels rework" ARMmbed/mbed-os#4148 4152: STM32F4 Internal ADC channels rework ARMmbed/mbed-os#4152 4074: [Silicon Labs] Update pinout ARMmbed/mbed-os#4074 4133: U-BLOX_C030: Default XTAL is now 12MHz onboard. Option to use Debug 8MHz ARMmbed/mbed-os#4133 4142: EFM32: Fixed `pwmout_all_inactive` being inversed ARMmbed/mbed-os#4142 4016: [NRF5]: fix rtc overflow-while-set-timestamp issue ARMmbed/mbed-os#4016 4031: STM32 increase IAR heap size for big RAM targets ARMmbed/mbed-os#4031 4137: MCUXpresso: Update ARM linker files to eliminate reserving RAM for stack & heap ARMmbed/mbed-os#4137 4176: STM32L4 Internal ADC channels rework ARMmbed/mbed-os#4176 4154: STM32F7 Internal ADC channels rework ARMmbed/mbed-os#4154 4174: [NRF52840]: fix rtc overflow-while-set-timestamp issue ARMmbed/mbed-os#4174 4180: [UBLOX_C030] create target hierarchy for the specific versions of the C030 board ARMmbed/mbed-os#4180 4153: STM32F2: Internal ADC channels rework ARMmbed/mbed-os#4153
Description
See discussion in issue #4099. I've only tested this by compiling an I2C app with an LPC1768 target and then running the result. I have yet to be able to successfully run 'mbed test' in my environment (against stable, head, etc.), so I'm not able to demonstrate the results of that.
Status
READY/IN DEVELOPMENT/HOLD
Todos