-
Notifications
You must be signed in to change notification settings - Fork 141
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 embedded_hal::serial implementation for uarte (continuation) #343
Conversation
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.
How was this code tested? This seems potentially tricky to get right, so I'm a bit hesitant to merge this without proper testing and review (I'd appreciate others to review this for correctness as well)
I tested the UARTE with this little program on the micro:bit: #![no_main]
#![no_std]
use panic_halt as _;
use core::fmt::Write;
use microbit::{
hal::uarte,
hal::uarte::{Baudrate, Parity},
hal::prelude::*,
};
static mut TX_BUF: [u8; 1] = [0; 1];
static mut RX_BUF: [u8; 1] = [0; 1];
use cortex_m_rt::entry;
#[entry]
fn main() -> ! {
let board = microbit::Board::take().unwrap();
let (mut tx, mut rx) = {
let serial = uarte::Uarte::new(
board.UARTE0,
board.uart.into(),
Parity::EXCLUDED,
Baudrate::BAUD115200,
);
serial.split(
unsafe { &mut TX_BUF },
unsafe { &mut RX_BUF }
).unwrap()
};
loop {
write!(tx, "Hello World:\r\n").unwrap();
let input = nb::block!(rx.read()).unwrap();
write!(tx, "You wrote: {}\r\n", input as char).unwrap();
}
} As well as bigger variants of the TX_BUF size and it all seems to work. You were indeed right about the write not being functional though so I added some more logic that should make sure the flags are always properly reset and we only return WouldBlock if the TX transaction has both been started and is not finished yet. One thing I am not 100% sure about is the implementation of the Write trait on the UarteTx struct, at the moment it will stick to the behaviour of waiting until the buffer is full before flushing it so it can happen that the output of a write! call is not at all or only partially printed depending on the buffer and input size. This could however of course simply be fixed by having a .flush() call in the Write trait implemenation. However I am not quite sure about whether that's something we want? One could argue that if a user needs this behaviour they can just write a newtype wrapper around the current UarteTx struct and add the explicit flush (of course we could do that as well). That being said I don't know which of these two options (no flush or autoflush) should be the default for this implementation. |
Yeah, I'm not entirely sure what the intended behavior from This PR still needs a rebase, but other than that I think it's ready to land. Thanks! |
This adds a sub-module named "serial" that splits TX and RX parts of UART into separate types that implements the embedded_hal::serial interfaces. This allows using the nRF UART for drivers that rely on the embedded_hal::serial traits. The buffer management is primitive in order to support the semantics of the more restrictive embedded_hal traits.
… does not affect memory location for DMA.
* Allow making multi-byte DMA transfers by starting DMA only on flush(). Read is still limited by the embedded_hal trait, so will still read only 1 byte at a time. * Auto derive blocking trait from non-blocking version.
* Remove explicit lifetime for tx/rx structs * Refactor write/read logic into functions that are reused in the existing combined Uarte implementation and the UartTx/UarteRx implementation.
Co-authored-by: Jonas Schievink <[email protected]>
Co-authored-by: Jonas Schievink <[email protected]>
5a16c71
to
0ebf91b
Compare
Rebased! |
bors r+ |
343: Add embedded_hal::serial implementation for uarte (continuation) r=jonas-schievink a=hargoniX Since #281 has been abandoned by the author this is a continuation of his work in a seperate PR. Co-authored-by: Ulf Lilleengen <[email protected]> Co-authored-by: Henrik Böving <[email protected]>
bors retry |
bors r+ |
Build succeeded: |
Since #281 has been abandoned by the author this is a continuation of his work in a seperate PR.