nrf-rs / nrf51-hal Goto Github PK

GPIO.split() returns a Parts struct, whose members have types like PIN0<Input<Floating>>:
https://docs.rs/nrf51-hal/0.6.2/nrf51_hal/gpio/gpio/struct.Parts.html

This means its members claim to implement the embedded_hal::digital::InputPin trait, and so the compiler will let you call is_high() and is_low() on them.

But split() doesn't do anything to enable the input buffer for each pin (which is disabled by default), so these calls won't return meaningful information until you explicitly call one of the .into_xxx_input() methods.

In general the typestate system for these PIN types means the compiler prevents you making mistakes like this, so I think it would be better to either

• have split() reconfigure all the pins as floating input; or
• have a third mode for the PIN types which doesn't implement either input or output traits, and have Parts use those types.

The second change isn't fully backwards compatible, but if it makes a program stop compiling it's probably revealing a bug.

There's also a weakness that nothing stops you arbitrarily configuring the GPIO pins before calling split(), leading to another way for the typestates to get out of sync with the hardware. Either of the changes above would remove that weakness too.

Opening this issue to avoid polluting rust-embedded/nb#13 with too much device specific discussion.

The current impl embedded_hal::serial::Write for Tx<UART0> is blocking, the easy implementation of

fn write(&mut self, byte: u8) -> nb::Result<(), !> {
    let uart = unsafe { &*UART0::ptr() };
    if uart.events_txdrdy.read().bits() == 1 {
         uart.events_txdrdy.reset();
         uart.txd.write(|w| unsafe { w.bits(u32::from(byte)) });
         Ok(())
    } else {
        Err(nb::Error::WouldBlock)
    }
}

doesn't work because events_txdrdy is only set after a byte is transmitted, not when the peripheral is first enabled. It doesn't appear to be possible to manually set event registers as well.

I have some changes which add support for the nRF9160 (UART and GPIO I think - not sure I did anything else). If I can get permission to publish them, would you like to add them here, or create an nrf91-hal? Or create an nrf-hal?

I also have github.com/thejpster/nrfxlib-sys, which generates bindings for the Nordic nrfxlib BSD library, which provides the socket API for the nRF9160. Would you like to host that in this org too, or shall I put it in rust-embedded-community?