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 I2C last_abort_reason #1370

Draft
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

peterharperuk
Copy link
Contributor

Fixes #1049

andygpz11
andygpz11 previously approved these changes May 17, 2023
Copy link
Contributor

@andygpz11 andygpz11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me.

@peterharperuk
Copy link
Contributor Author

Fixed build issue

@kilograham kilograham self-assigned this May 26, 2023
@kilograham kilograham marked this pull request as draft May 26, 2023 13:38
@kilograham
Copy link
Contributor

assigning to myself; i think i'd rather return the abort reason in the top half of a 64 bit rc (and do some API massaging)

@kilograham kilograham modified the milestones: 1.5.1, 1.6.0 May 26, 2023
@kilograham kilograham changed the title Add last_abort_reason Add I2C last_abort_reason May 19, 2024
@kilograham kilograham modified the milestones: 1.6.1, 1.6.0 May 19, 2024
@peterharperuk
Copy link
Contributor Author

assigning to myself; i think i'd rather return the abort reason in the top half of a 64 bit rc (and do some API massaging)

I don't think you liked this change? I could add a variant of the functions to return int64_t if that sounds like what you wanted?

@kilograham
Copy link
Contributor

yeah, i guess returning a struct with two elements in a replacement APIs and picking the result out for the existing APIs is good
(Note a two uint32_t struct will be returned correctly in r0/r1 i believe)

@kilograham kilograham modified the milestones: 1.6.0, 1.7.0 Jul 31, 2024
@@ -246,6 +251,7 @@ static inline i2c_inst_t *i2c_get_instance(uint num) {
*
* \return Number of bytes written, or PICO_ERROR_GENERIC if address not acknowledged, no device present, or PICO_ERROR_TIMEOUT if a timeout occurred.
*/
i2c_result_t i2c_write_result_blocking_until(i2c_inst_t *i2c, uint8_t addr, const uint8_t *src, size_t len, bool nostop, absolute_time_t until);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this (and the other new _result_ functions) need to be added to the header file after the old functions, in order not to invalidate the documented doxygen \return parameter?

@@ -130,7 +130,7 @@ void i2c_set_slave_mode(i2c_inst_t *i2c, bool slave, uint8_t addr) {
i2c->hw->enable = 1;
}

static int i2c_write_blocking_internal(i2c_inst_t *i2c, uint8_t addr, const uint8_t *src, size_t len, bool nostop,
static i2c_result_t i2c_write_blocking_internal(i2c_inst_t *i2c, uint8_t addr, const uint8_t *src, size_t len, bool nostop,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency with function-names and return-types, I wonder if i2c_write_blocking_internal ought to be renamed to i2c_write_result_blocking_internal ? 🤔 (It's an internal-only function name, so I think we're free to rename it?)

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.

4 participants