-
Notifications
You must be signed in to change notification settings - Fork 3k
I2c ref impl #10374
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
I2c ref impl #10374
Conversation
fixing astyle ...done |
@maciejbocianski, thank you for your changes. |
Test results of (#9573):
|
00a81f2
to
76e4118
Compare
Under review |
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.
- There are inconsistencies on address' maximum lenght (9/10bits)
- The API snippet of the design doc is inconsistent with the statements made before (eg.
stop
argument toi2c_read
andi2c_write
). - Why Async has a single "transfer" while sync has "read" and "write" ?
- What is the other of read/write operations in Async ?
- How the device is expected to process an abort of the transfer ?
- Should it send a stop if one was requested ?
- Are symbols atomic ? That is to say, should the transfer stop in the middle of a transmission when abort is called or should it gracefully stop after the current symbol ?
- Is an abort considered an error and should it be reported as such in the event ?
- Is the event callback invoked at all in case of abort ?
- Should it send a stop if one was requested ?
There are also typos here and there but they're minor issues in regards to the comment above & in the code.
I have not reviewed (yet) the implementations as I don't know (yet) the platform, my feedback on these would not be very deep. And the API should probably be fixed before we give attention to the details of the implementations.
I2C *I2C::_owner = NULL; | ||
SingletonPtr<PlatformMutex> I2C::_mutex; | ||
|
||
I2C::I2C(PinName sda, PinName scl) : |
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.
This implementation does not seem to deal with multiple i2c peripheral used in parallel very well.
- Only 1 I2C can be used at a time.
- There is no mechanism that I can see that prevent an i²c peripheral to be instantiated twice.
- The
I2C
class seem to be oriented to have1 instance per bus
instead of1 instance per slave
likeSPI
class does.
This is probably out of the scope of this PR as it'd create breaking change on the C++ API level but it is still worth nothing that this is inconsistent and should be fixed.
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 agree the improvement of I2C
and I2CSlave
drivers should be in separate PR. This PR should include only adaptation to HAL API changes
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.
Yes, adding extra functionality to the driver is out of scope
|
||
Currently the `DMAUsage` argument of the `i2c_transfer_asynch` function is unimplemented, the argument is unused by all `I2C` implementations. There is no real demand for it so can be removed from the API. | ||
|
||
- **Change** the `stop` parameter from the `i2c_transfer_async` from an `uint32_t` to a `bool`. |
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.
Why isn't this argument removed Since it is also removed from the sync API ?
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 stop
stays for both sync and async API
* @param data The buffer for sending | ||
* @param length Number of bytes to write | ||
* @param stop Stop to be generated after the transfer is done | ||
* @param stop If true, stop will be generated after the transfer is done |
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.
Shouldn't this be removed from the parameter list as per the design doc ?
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.
stop
stays
Test run: FAILEDSummary: 5 of 7 test jobs failed Failed test jobs:
|
86d4949
to
7b639bd
Compare
@ithinuel Could you please re-review? |
@ithinuel @maciejbocianski Any update? Is there anyone else who could review? |
Update for both doc and reference implementation will be available within this week |
|
@ithinuel could you re-review this please |
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 am happy about the changes
@ithinuel
|
d775f47
to
86c5f6c
Compare
39c53c0
to
78f6426
Compare
rebased |
CI started |
Test run: FAILEDSummary: 6 of 7 test jobs failed Failed test jobs:
|
Please review build failures, related |
…low I2C-less builds
I2CName should stay when I2C is disabled, becouse it's required by PeripheralPins.c
Fixes for specific errors were provided |
CI restarted |
Test run: FAILEDSummary: 3 of 7 test jobs failed Failed test jobs:
|
117cfc1
to
28d8766
Compare
restarted |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Can someone please review ARMmbed/mbed-os-5-docs#807 to make sure it's up to date? |
Description
This PR is a continuation of the work done in #8682.
It contains all changes from #8682 plus:
This PR contains reference implementations of the I2C HAL RFC changes for the FRDM-K64F and NUCLEO_F070RB boards.
Pull request type
Reviewers
@ARMmbed/mbed-os-hal
Release Notes