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

Add SCL and SDA defs for I2C[0-2]; redefine I2C_[SCL,SDA] to I2C2 #4102

Merged
merged 1 commit into from Apr 10, 2017
Merged

Add SCL and SDA defs for I2C[0-2]; redefine I2C_[SCL,SDA] to I2C2 #4102

merged 1 commit into from Apr 10, 2017

Conversation

wdwalker
Copy link
Contributor

@wdwalker wdwalker commented Mar 31, 2017

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

  • Tests

@theotherjimmy
Copy link
Contributor

theotherjimmy commented Mar 31, 2017

@bridadan Is this a /morph test candidate? or do we need a different command? asked offline. just running morph test is good enough.

@theotherjimmy
Copy link
Contributor

@0xc0170 Could we tag the NXP maintainers in this one?

@theotherjimmy
Copy link
Contributor

theotherjimmy commented Mar 31, 2017

@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?

Copy link
Contributor

@theotherjimmy theotherjimmy left a 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.

@theotherjimmy
Copy link
Contributor

/morph test

Copy link
Contributor

@geky geky left a 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,
Copy link
Contributor

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.

Copy link
Contributor

@geky geky Mar 31, 2017

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@wdwalker wdwalker Mar 31, 2017

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.

Copy link
Contributor Author

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.

@theotherjimmy
Copy link
Contributor

clarification: the tag means that we are waiting on the continuous integration to finish.

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 3, 2017

cc @mmahadevan108

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 3, 2017

@bridadan morph test restart needed

@bridadan
Copy link
Contributor

bridadan commented Apr 3, 2017

/morph test

@mbed-bot
Copy link

mbed-bot commented Apr 3, 2017

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1814

All builds and test passed!

@wdwalker
Copy link
Contributor Author

wdwalker commented Apr 7, 2017

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?

Copy link
Contributor

@bridadan bridadan left a 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,
Copy link
Contributor

@bridadan bridadan Apr 7, 2017

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.

Copy link
Contributor

@bridadan bridadan left a 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.

@theotherjimmy
Copy link
Contributor

So, LGTM

@sg- sg- merged commit 833a201 into ARMmbed:master Apr 10, 2017
aisair pushed a commit to aisair/mbed that referenced this pull request Apr 30, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants