-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Minor change of SPI interface [API breaking] #6187
Comments
Work on this is going on at the HAL layer, once low level API's are updated we will update the driver as well. Refer #7671 for updated API's [Mirrored to Jira] |
Internal Jira reference: https://jira.arm.com/browse/IOTCORE-144 |
HAL layer was updated. |
Note: This is just a template, so feel free to use/remove the unnecessary things
Description
Question
using SPI the types do not make much sense.
The idea is that things are bytes that are written, I am not 100% sure if
char
is guaranteed to be unsigned. At least as ofC11
this is implementation specific.So should there not be either be made usage of
uint8_t
(as defined in <cinttypes>
or<cstdint>
) or define a custombyte_t
.virtual int write(const char *tx_buffer, int tx_length, char *rx_buffer, int rx_length);
The API of
virtual int write(int value);
is not very idiomatic either, the argument should also be anuint8_t
since that is what is actually transfered, the return value is a mingled version of an error code and a return code.proposal (this is an API breaking change):
virtual int write(const uint8_t *tx_buffer, size_t tx_length, uint8_t *rx_buffer, size_t rx_length);
virtual int write(uint8_t value, uint8_t *ret);
I'd like to know what you think about this or what was the reasoning to use the above?
The text was updated successfully, but these errors were encountered: