UART: Add wrapper around RIOT's UART-interface #39

kbarning · 2023-02-09T14:15:35Z

Here is my attempt to create a wrapper for RIOT's UART-interface :)

chrysn · 2023-02-11T10:13:03Z

Thanks for the PR. I've cleared it for a first CI run, but haven't yet had time to look at it. Given this needs a uart_t at construction, it might be good to look at #37 in parallel.

chrysn

Thanks for adding this. It looks good over-all, and very comprehensive. I have several details and questions annotated across the source. Quite a few of them might easily be explained by inspiration from existing code; I'd still hope to not continue on the bad examples I've set in the past.

src/uart.rs

kbarning · 2023-02-15T17:26:52Z

Thanks for adding this. It looks good over-all, and very comprehensive. I have several details and questions annotated across the source. Quite a few of them might easily be explained by inspiration from existing code; I'd still hope to not continue on the bad examples I've set in the past.

First of all, thank you for this comprehensive review. I will try to resolve your issues in the next few days :)

src/uart.rs

chrysn · 2023-02-19T18:52:06Z

CI tests are failing because RIOT's version of the riot-sys crate wasn't updated to the latest nightly yet -- but that's on the RIOT repository side of things.

chrysn · 2023-03-04T20:29:59Z

When all open issues are addressed (I think it's only the matter of safety and scoping), as with the DAC PR, I'll want to have a test around to ensure that the code is actually built during CI. Let me know whether you want to give that a try in the style of c9cf3f2, otherwise I'll do it as part of the final review.

chrysn

I think this is approaching completion.

Given the many fixes and merges, please rebase onto current master and squash into one or some logically structured commits.

Would you add some small runnable test?

src/uart.rs

Teufelchen1 · 2024-11-14T09:07:34Z

@kbarning hey! I accidentally started a competing PR, I overlooked your work. Do you intend of picking this PR up again?

kbarning · 2024-11-20T11:37:23Z

@kbarning hey! I accidentally started a competing PR, I overlooked your work. Do you intend of picking this PR up again?

Hey, I'm still waiting for an answer from @chrysn. I've implemented everything that he suggested to me so far, but I'm still waiting for approval.

chrysn · 2024-11-20T13:10:30Z

Sorry for having let this sit unduly long, especially after you've brought it all this way – and not having remembered that this is sitting when Teufelchen started up his PR didn't help make the situation better, yet here we are.

Before I start looking through both PRs to see whether there's one that clearly outperforms (on usability, safe usability, features or clarity), would the two of you like to have a look over each other's PRs and/or a short exchange on whether there is one you both prefer or aspects missing from both?

Teufelchen1 · 2024-11-27T11:38:13Z

Okay, I gave it a thought and I believe this PR is better, in the sense that it is much more mature (documentation, api completeness, etc.).

What is missing compared to my draft is the implementation of embedded_io::Write / embedded_io::ErrorKind that chrysn wished for - But that can be retro fitted easily. I recommend doing that in a follow up PR (maybe I can do that), so this work here can finally get merged.

This PR needs a rebase. I did a shitty one locally to test this PR, it was annoying but not too bad. The code still works as intended.

@kbarning I can imagine you want this done sooner than later, please rebase and squash. I'll poke @chrysn to review it in a timely manner :)

(I can also offer to rebase & squash for you, if you like)

chrysn

Final round of comments while going through this again after the duplicate PR situation is being resolved.

Most of them should be easy to apply. The soundness one will need another round of review, but given that there was a lifetime in the type in earlier iterations, it should be managable.

tests/uart/Cargo.toml

src/uart.rs

chrysn · 2024-11-30T14:24:06Z

src/uart.rs

+    /// static mut CB: fn(u8) = |new_data| {
+    ///     //do something here with the received data
+    /// };
+    /// let mut uart = UartDevice::new_with_static_cb(0, 115200, unsafe { &mut CB })


The better example would be to use static_cell or maybe crate::mutex::Mutex, or even println!("Received {:02x}", new_data);, but unless you feel super motivate to update this, we can leave that as is for now.

I have added the println! in the examples :)

Then could almost just be fn cb(new_data: &[u8) { println!(...) }, no need for a mut static that'll need unsafe and makes the linter scream.

Almost, because we don't get a &mut cb, which hints at that user_callback should be F and not &'scope mut F … which again we can't do because we don't have a size limit.

We may need to iterate over that later on, but that'll work better when we see actual use cases. So let's have this in for now. I've just updated the example to not use static muts any more.

src/uart.rs

tests/uart/Cargo.toml

kbarning · 2024-11-30T15:58:28Z

Final round of comments while going through this again after the duplicate PR situation is being resolved.

Most of them should be easy to apply. The soundness one will need another round of review, but given that there was a lifetime in the type in earlier iterations, it should be managable.

I will have a look in the following days :)

Co-authored-by: chrysn <chrysn@fsfe.org>

kbarning · 2024-12-07T03:25:14Z

Okay, I gave it a thought and I believe this PR is better, in the sense that it is much more mature (documentation, api completeness, etc.).

What is missing compared to my draft is the implementation of embedded_io::Write / embedded_io::ErrorKind that chrysn wished for - But that can be retro fitted easily. I recommend doing that in a follow up PR (maybe I can do that), so this work here can finally get merged.

This PR needs a rebase. I did a shitty one locally to test this PR, it was annoying but not too bad. The code still works as intended.

@kbarning I can imagine you want this done sooner than later, please rebase and squash. I'll poke @chrysn to review it in a timely manner :)

(I can also offer to rebase & squash for you, if you like)

I have rebased my branch. The squashing is done directly via this PR right? (at least I think so, if not I think @chrysn can enable it). It would be great if you can add the embedded_io stuff @Teufelchen1 because I hardly have any time at the moment 😞.

Teufelchen1 · 2024-12-09T09:25:35Z

Yes, squashing can be done via GitHub UI by chrysn (I do not have permissions).
Yes, I will add the embedded_io stuff in a followup PR, once this is merged :)

chrysn · 2024-12-09T09:37:25Z

I wouldn't insist on squashing in general; if you prefer things squashed to a single commit, that can be done at merge time. (My general approach is that I like to have history visible in the tree, and merges from master into the feature branches, because people can always get a view as-if-squashed from git using --first-parent. For many of the items in here such as the fixes, it makes sense to apply them, and if doing that is excessive, let's rather squash it all -- also because due to the rebasing, it'll be nontrivial to understand where the added pub mod dac comes from before this is squashed.)

The latest version you pushed was not tested locally, was it? I've found a few compile errors, but am fixing them locally and pushing to the branch as part of a final checking round.

chrysn · 2024-12-09T13:56:00Z

I've added a few fixes to the branch chrysn-impl_uart_wrapper (couldn't push to the PR's branch); am not through with them, but you may want to have a look at them.

kbarning · 2024-12-14T02:53:58Z

I've added a few fixes to the branch chrysn-impl_uart_wrapper (couldn't push to the PR's branch); am not through with them, but you may want to have a look at them.

When you're done with the fixes, should I rebase this branch from yours?

chrysn · 2025-01-06T18:48:54Z

I think I'm happy with the branch containing your work and my fixes now; I've created #143 as to run CI on it.

Can either of you run a check on that one, and look into whether anything is amiss?

I'll go through the open comments, and mark as resolved what has been addressed.

chrysn · 2025-01-06T18:53:22Z

src/uart.rs

@@ -0,0 +1,331 @@
+//! Access to [RIOT's UART](https://doc.riot-os.org/group__drivers__periph__uart.html)
+//!
+//! Author: Kilian Barning <barning@uni-bremen.de>


We don't have a consistent policy in Rust code for RIOT as to how to annotate authorship per module. I'd leave this in for now, especially until we do have something more generic, but as this is not a copyright note, it may be removed in a later version – realistically, I expect it to be moved into more meta data at some point.

chrysn · 2025-01-07T22:08:58Z

With the review on #143, I've squashed things there; I'll merge that soon.

@kbarning, you might take interest in the notes of squashing there in #143 (comment)

chrysn reviewed Feb 15, 2023

View reviewed changes

chrysn reviewed Feb 18, 2023

View reviewed changes

src/uart.rs Outdated Show resolved Hide resolved

chrysn reviewed Feb 19, 2023

View reviewed changes

src/uart.rs Outdated Show resolved Hide resolved

src/uart.rs Outdated Show resolved Hide resolved

src/uart.rs Outdated Show resolved Hide resolved

chrysn reviewed Mar 19, 2023

View reviewed changes

Teufelchen1 mentioned this pull request Oct 28, 2024

uart: Add initial wrappers #133

Closed

chrysn mentioned this pull request Nov 29, 2024

build: Acknowledge all available periph_uart variations #137

Merged

chrysn reviewed Nov 30, 2024

View reviewed changes

kbarning and others added 14 commits December 7, 2024 04:16

Added uart

9722813

Fixed callback

5ace203

Fix code according to @jaschman

530e441

Add init pins

14f0d08

Fix comments

3d7b15b

Fixed signature

5fb2e12

Fixed closure type

e1dd2c0

Mark init pins as unsafe

ac0d680

Fix comments

a39a7a7

Change drop

1a0d07c

Introduce Phantom Data Lifetimes

b62e14e

Add generics to rxstart

788d633

Add mode feature

7e2badb

PWM: Add wrapper around RIOTs PWM-interface

eec16de

kbarning and others added 19 commits December 7, 2024 04:17

Added new static impl + fix doc

a545c7b

Make get gpio optional

e0e99a6

Remove colission detection for now

820b42c

Add new scoped main

74e68fd

Update src/uart.rs

be20cea

Co-authored-by: chrysn <chrysn@fsfe.org>

Update src/uart.rs

3a9e145

Co-authored-by: chrysn <chrysn@fsfe.org>

Update src/uart.rs

d957c9f

Co-authored-by: chrysn <chrysn@fsfe.org>

Update src/uart.rs

e45c297

Co-authored-by: chrysn <chrysn@fsfe.org>

Update src/uart.rs

7aa931b

Co-authored-by: chrysn <chrysn@fsfe.org>

Make internal construct fn unsafe

762a639

add test

748fe93

Fix scope signature and add cfg to unused structs

cd066aa

Reordering

12fda60

Cleanup

973d70a

Update tests/uart/Cargo.toml

59f3d78

Co-authored-by: chrysn <chrysn@fsfe.org>

Update src/uart.rs

03595f9

Co-authored-by: chrysn <chrysn@fsfe.org>

Update src/uart.rs

9763bf3

Co-authored-by: chrysn <chrysn@fsfe.org>

Update tests/uart/Cargo.toml

2b63e71

Co-authored-by: chrysn <chrysn@fsfe.org>

Add println to examples, remove unused code

455291e

kbarning force-pushed the impl_uart_wrapper branch from 405bfc8 to 455291e Compare December 7, 2024 03:19

Fix rebase

16a67e9

chrysn mentioned this pull request Jan 6, 2025

UART wrapper (chrysn's cleanup) #143

Open

chrysn reviewed Jan 6, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

UART: Add wrapper around RIOT's UART-interface #39

UART: Add wrapper around RIOT's UART-interface #39

kbarning commented Feb 9, 2023 •

edited

Loading

chrysn commented Feb 11, 2023

chrysn left a comment

kbarning commented Feb 15, 2023

chrysn commented Feb 19, 2023

chrysn commented Mar 4, 2023

chrysn left a comment

Teufelchen1 commented Nov 14, 2024

kbarning commented Nov 20, 2024

chrysn commented Nov 20, 2024

Teufelchen1 commented Nov 27, 2024

chrysn left a comment

chrysn Nov 30, 2024

kbarning Dec 7, 2024

chrysn Dec 9, 2024

kbarning commented Nov 30, 2024

kbarning commented Dec 7, 2024

Teufelchen1 commented Dec 9, 2024

chrysn commented Dec 9, 2024

chrysn commented Dec 9, 2024

kbarning commented Dec 14, 2024

chrysn commented Jan 6, 2025

chrysn Jan 6, 2025

chrysn commented Jan 7, 2025

UART: Add wrapper around RIOT's UART-interface #39

Are you sure you want to change the base?

UART: Add wrapper around RIOT's UART-interface #39

Conversation

kbarning commented Feb 9, 2023 • edited Loading

chrysn commented Feb 11, 2023

chrysn left a comment

Choose a reason for hiding this comment

kbarning commented Feb 15, 2023

chrysn commented Feb 19, 2023

chrysn commented Mar 4, 2023

chrysn left a comment

Choose a reason for hiding this comment

Teufelchen1 commented Nov 14, 2024

kbarning commented Nov 20, 2024

chrysn commented Nov 20, 2024

Teufelchen1 commented Nov 27, 2024

chrysn left a comment

Choose a reason for hiding this comment

chrysn Nov 30, 2024

Choose a reason for hiding this comment

kbarning Dec 7, 2024

Choose a reason for hiding this comment

chrysn Dec 9, 2024

Choose a reason for hiding this comment

kbarning commented Nov 30, 2024

kbarning commented Dec 7, 2024

Teufelchen1 commented Dec 9, 2024

chrysn commented Dec 9, 2024

chrysn commented Dec 9, 2024

kbarning commented Dec 14, 2024

chrysn commented Jan 6, 2025

chrysn Jan 6, 2025

Choose a reason for hiding this comment

chrysn commented Jan 7, 2025

kbarning commented Feb 9, 2023 •

edited

Loading