It's not clear when can::ErrorKind::Acknowledge should be returned
#387
Comments
Closed
|
cc: @timokroeger |
|
I fully agree with jonas here. |
|
We discussed in the WG meeting that we could keep the variant but improve its documentation. |
8 tasks
bors bot
added a commit
that referenced
this issue
Sep 26, 2022
394: Split nb and can traits to separate crates. r=eldruin a=Dirbaio Following up from #177 (comment), this PR splits `nb` and `can` traits to separate crates. I propose keeping these crates (and `embedded-hal-async`) separate forever. (instead of merging EHA into EH when stable as we originally planned when we created EHA). Reasons for splitting `nb`: - its future is unclear. Some people who would like to see `nb` deprecated. By splitting, if we do deprecate it, we won't get stuck with it in the main `embedded-hal` crate forever. - It makes the module paths in the main crate cleaner. - Traits tied to a particular "execution model" in their own crates, which make the overall structure easier to understand IMO. Reasons for splitting `can`: - It has some open concerns: #381 #387 - Even if we do solve these, it's nice to have separate crates for the "more specialized" traits so that they can be major-bumped in the future if more concerns arise, without having to major-bump the main `embedded-hal` crate. TODO: - [x] Name it `embedded-can`, not `embedded-hal-can`. - [x] Move/remove docs/examples from the main crate that mention `nb`. - [x] Mention the subcrates from the main crate's docs. - [x] Add CI - [x] move `embedded-hal` to a subdir as well - [x] What should the nb, can crate versions be? 1.0? (no opinion on this from me). - [x] can: 0.4 - [x] nb: 1.0 Co-authored-by: Dario Nieuwenhuis <[email protected]>
bors bot
added a commit
that referenced
this issue
Sep 26, 2022
394: Split nb and can traits to separate crates. r=eldruin a=Dirbaio Following up from #177 (comment), this PR splits `nb` and `can` traits to separate crates. I propose keeping these crates (and `embedded-hal-async`) separate forever. (instead of merging EHA into EH when stable as we originally planned when we created EHA). Reasons for splitting `nb`: - its future is unclear. Some people who would like to see `nb` deprecated. By splitting, if we do deprecate it, we won't get stuck with it in the main `embedded-hal` crate forever. - It makes the module paths in the main crate cleaner. - Traits tied to a particular "execution model" in their own crates, which make the overall structure easier to understand IMO. Reasons for splitting `can`: - It has some open concerns: #381 #387 - Even if we do solve these, it's nice to have separate crates for the "more specialized" traits so that they can be major-bumped in the future if more concerns arise, without having to major-bump the main `embedded-hal` crate. TODO: - [x] Name it `embedded-can`, not `embedded-hal-can`. - [x] Move/remove docs/examples from the main crate that mention `nb`. - [x] Mention the subcrates from the main crate's docs. - [x] Add CI - [x] move `embedded-hal` to a subdir as well - [x] What should the nb, can crate versions be? 1.0? (no opinion on this from me). - [x] can: 0.4 - [x] nb: 1.0 Co-authored-by: Dario Nieuwenhuis <[email protected]> Co-authored-by: Diego Barrios Romero <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Its docs say "An ACK error shall be detected by a transmitter whenever it does not monitor a dominant bit during the ACK slot.", but
Can::transmitonly enqueues a frame for transmission, so it's impossible to detect this condition for the frame passed there.Can::transmitcould check if any previous frame caused an ACK error and return an error, but then its return value indicates whether a different frame was transmitted successfully.The text was updated successfully, but these errors were encountered: