Restructure and implement embedded-nal UDP traits #26

jonahd-g · 2020-11-24T07:32:19Z

This has been a long time in the works (over a year), but it's finally working and ready for a review. This PR majorly restructures the driver into a state machine design so that only valid actions can be taken. It abstracts the SPI connection into a Bus trait, with implementations for a three-wire and a four-wire connection. It also abstracts the host config into a Host trait, with implementations for Manual and DHCP (incomplete). And importantly, it implements the embedded-nal UDP traits.

This is depending on an un-released rev of embedded-nal, since the latest UDP traits have not been released yet. If this is merged before that is released, I'll create another PR to depend on the new version.

andresv · 2020-11-26T09:48:03Z

@kellerkindt what it takes to get it merged, do you see any problems in this approach that you do not like?

kellerkindt · 2020-11-26T21:07:48Z

Wow, thanks for your contribution! I'll try to review it on the weekend. I'll be more than happy to merge this - although having to depend on an unreleased version of embedded-nal is kind of a bummer. Is there any schedule for its release?

jonahd-g · 2020-11-26T22:05:44Z

@kellerkindt Yes it is a bummer. Release is pending an update to the TCP trait(s).

rust-embedded-community/embedded-nal#30

kellerkindt

One thing that does not seem to be possible anymore, is to store the W5500/InactiveDevice in a struct and to activate it for a short duration as needed?

Before, I would write something like

pub struct SomePlatformDevices {
   w5500: W5500<..>,
  ...
}

impl SomePlatformDevices {
    pub fn receive_udp(
        &mut self,
        buffer: &mut [u8],
    ) -> Result<Option<(IpAddress, u16, usize)>, TransferError<SpiError, W5500CsError>> {
        let mut active = self.w5500.activate(&mut self.spi)?;
        let active = &mut active;
        let socket = self
            .network_udp
            .as_ref()
            .ok_or(TransferError::SpiError(spi::Error::ModeFault))?;

        (active, socket).receive(buffer)
    }
}

In the new version:

pub struct SomePlatformDevices {
   w5500: InactiveDevice<..>,
  ...
}

impl SomePlatformDevices {
    pub fn receive_udp(
        &mut self,
        buffer: &mut [u8],
    ) -> Result<Option<(IpAddress, u16, usize)>, TransferError<SpiError, W5500CsError>> {
        let mut active = self.w5500.activate(&mut self.spi)?; // ERROR: this takes ownership/moves w5500

        ...
    }
}

Am I approaching this wrong?

src/lib.rs

README.md

src/interface.rs

jonahd-g · 2020-12-01T06:13:29Z

One thing that does not seem to be possible anymore, is to store the W5500/InactiveDevice in a struct and to activate it for a short duration as needed?

Yeah, this does make that a bit more tricky. I think you could apply the Option pattern here fairly easily though.

pub struct SomePlatformDevices {
   w5500: Option<InactiveDevice<..>>,
  ...
}

impl SomePlatformDevices {
    pub fn receive_udp(
        &mut self,
        buffer: &mut [u8],
    ) -> Result<Option<(IpAddress, u16, usize)>, TransferError<SpiError, W5500CsError>> {
        if let Some(w5500) = self.w5500.take() {
            let mut active = w5500.activate(&mut self.spi)?;
            // do something ...
            self.w5500 = Some(w5500.deactivate())
        }
    }
}

jonahd-g · 2020-12-02T16:14:10Z

@kellerkindt we're now depending on a released version of embedded-nal.

jonahd-g · 2020-12-02T16:38:13Z

Uh-oh, looks like there were some upstream changes I didn't take into account. Will fix.

jonahd-g · 2020-12-02T16:53:22Z

All fixed.

andresv · 2020-12-03T17:34:23Z

Looking forward to see it in crates.io, good stuff!

jonahd-g · 2020-12-11T05:00:08Z

@kellerkindt are there any issues holding this back from being merged?

andresv · 2020-12-11T05:01:56Z

I also voice my interest to get it merged.

kellerkindt · 2020-12-13T20:43:00Z

I don't see any issues at first glance and I also want this to be merged, but I also do not want to merge such a big change without testing/playing around with it myself (I plan to upgrade a small personal project). And at the moment, I do not have the time at hand to do so (I assume I`ll need one or two evenings). I hope I will be able to do so the week before Christmas or before new year. Sorry!

I am really grateful for all your effort!

jonahd-g · 2020-12-14T17:56:31Z

Thanks @kellerkindt . I'd be interested in becoming a maintainer in the future if you're open to that, that way the project has a bit of redundancy.

Other things I'd like to work on after this is merged:

Compilable examples
A chip simulator for running integration tests
DHCP
TCP

Re: merging a big change, you could merge it and release as a beta, i.e. 0.4.0-beta.1. [semver docs]

kellerkindt

I just ported over a small project of mine so that it uses this PR. I had to make some changes to be able to use it.

I can see the appeal of having definite states, but using it feels a bit clumsy. It also did not find one of my errors while porting it over: I failed to re-bind the UdpSocket after sending data. Also the fact that the device instance is moved in and out of the Option (self.w5500 in the code snippets below) just screams for someone to forget to put it back under some edge case scenario. Moving the InactiveDevice in and out from the option, calling .activate(SpiRef(&mut self.spi)).into_interface() and interface.release().deactivate().0 is also not a perfect experience, especially if you remember that internally it is moved in and out of the RefCell and additional overhead for the runtime borrow checks is caused.

If I see this correctly, the RefCell and into_interface()/release() calls are only required because the function calls in UdpClient take a shared reference instead of an exclusive/mut reference? Can someone explain me the reason of it? Because I don't get it. No trait of embedded-hal does it (see Spi/FullDuplex for example). People seem to circumvent it anyways?

As an additional note, the chip version assertion does not cover all scenarios? I am working with at least one chip, for which the check does not work at all, so I had to add a way to disable the check.

Below are some snippets of the code that uses this PR - please excuse my (now) poorly chosen fn-signatures, I only replaced the body parts.

...
            w5500: {
                let mut w5500_cs = gpiob.pb1.into_push_pull_output(&mut gpiob.crl);

                w5500_cs.set_low_infallible(); // deselect
                w5500_reset.set_high_infallible(); // request reset
                delay.delay_ms(250_u16); // allow boot
                w5500_reset.set_low_infallible();

                let interface = Interface::setup(
                    SpiRef(&mut spi),
                    w5500_cs,
                    MacAddress::new(0x02, 0x00, 0x00, 0x00, 0x00, 0x00),
                    IpAddress::from(NetworkConfiguration::DEFAULT_IP.octets()),
                );

                if let Ok(interface) = interface {
                    Some(interface.release().deactivate().0)
                } else {
                    None // no way to recover
                }
            },
...
    pub fn init_network(&mut self) -> Result<(), SpiError> {
        if let Some(device) = self.w5500.take() {
            let mut active = device.activate(SpiRef(&mut self.spi)).into_interface();

            if let Some(socket) = self.network_udp.take() {
                let _ = active.close(socket);
            }

            let (bus, config) = active.release().release();

            // reset the network chip (timings are really generous)
            self.w5500_reset.set_low_infallible();
            self.system.delay.delay_ms(250_u16); // Datasheet 5.5.1 says 500_us to 1_ms (?)
            self.w5500_reset.set_high_infallible();
            self.system.delay.delay_ms(250_u16); // Datasheet says read RDY pin, the network chip needs some time to boot!

            self.system.delay.delay_ms(100_u16);

            let mut device = match UninitializedDevice::new(bus).initialize_advanced(
                self.network_config.mac,
                self.network_config.ip,
                self.network_config.gateway,
                self.network_config.subnet,
                w5500::Mode {
                    on_wake_on_lan: OnWakeOnLan::Ignore,
                    on_ping_request: OnPingRequest::Respond,
                    connection_type: ConnectionType::Ethernet,
                    arp_responses: ArpResponses::Cache,
                },
            ) {
                Ok(device) => device,
                Err(_) => panic!("lul"), // no way to recover
            };

            self.system.delay.delay_ms(100_u16);

            // init the UdpSocket
            if let Some(socket) = device.take_socket() {
                let mut udp = UdpSocket::new(socket);
                let mut interface = device.into_interface();
                interface.bind(&mut udp, SOCKET_UDP_PORT);
                self.network_udp = Some(udp);
                self.w5500 = Some(interface.release().deactivate().0);
            } else {
                self.w5500 = Some(device.deactivate().0);
            }
        }

        Ok(())
    }

...
    pub fn receive_udp(
        &mut self,
        buffer: &mut [u8],
    ) -> Result<Option<(IpAddress, u16, usize)>, SpiError> {
        if let Some(socket) = self.network_udp.as_mut() {
            if let Some(device) = self.w5500.take() {
                let mut interface = device.activate(SpiRef(&mut self.spi)).into_interface();
                let result: nb::Result<_, _> = interface.receive(socket, buffer);
                self.w5500 = Some(interface.release().deactivate().0);

                return match result {
                    Ok((_, SocketAddr::V6(_))) => unreachable!(),
                    Ok((len, SocketAddr::V4(v4))) => Ok(Some((*v4.ip(), v4.port(), len))),
                    Err(...) => ...
                };
            }
        }

        Ok(None)
    }
...
    pub fn send_udp(&mut self, host: &IpAddress, port: u16, data: &[u8]) -> Result<(), SpiError> {
        if let Some(socket) = self.network_udp.as_mut() {
            if let Some(device) = self.w5500.take() {
                let mut interface = device.activate(SpiRef(&mut self.spi)).into_interface();
                let result = block!(interface.send_to(
                    socket,
                    SocketAddr::V4(SocketAddrV4::new(*host, port)),
                    data
                ));
                interface.bind(socket, SOCKET_UDP_PORT);
                self.w5500 = Some(interface.release().deactivate().0);

                return result.map_err(|e| ...);
            }
        }
        Ok(())
    }
...

/// Helper to circumvent Spi-Ownership
#[derive(Debug)]
pub struct SpiRef<'a, Spi: FullDuplex<u8>>(&'a mut Spi);

impl<'a, Spi: FullDuplex<u8>> FullDuplex<u8> for SpiRef<'a, Spi> {
    type Error = Spi::Error;

    fn read(&mut self) -> nb::Result<u8, Self::Error> {
        self.0.read()
    }

    fn send(&mut self, word: u8) -> nb::Result<(), Self::Error> {
        self.0.send(word)
    }
}

kellerkindt · 2020-12-27T21:43:19Z

src/socket.rs

+            register: block + 1,
+            tx_buffer: block + 2,
+            rx_buffer: block + 3,


Unnecessary memory consumption? Can be computed in the getter fns

I'm not certain. This should only consume 3 bytes, but I have no idea how much memory would be consumed by three separate functions dedicated to adding three different integers (plus the extra time needed to compute upon every use). Thoughts?

kellerkindt · 2020-12-27T21:52:41Z

src/host/manual.rs

+    fn refresh<SpiBus: ActiveBus>(&mut self, bus: &mut SpiBus) -> Result<(), SpiBus::Error> {
+        if !self.is_setup {
+            Self::write_settings(bus, &mut self.current, &self.settings)?;
+            self.is_setup = true;


It only writes the settings once? Meaning, it compares the user settings with current which is always HostConfig::default(), but still stores two instances and the flag in memory?

Correct, it'll only write once. This is the intent, to keep a consistent interface between Manual and DHCP. DHCP needs to be periodically renegotiated. Manual doesn't need to, so after the initial setup it does nothing. I suppose this might be improved, but this is a private API, and DHCP isn't implemented yet, so I'd have no issues with merging as is and then re-considering once I start on DHCP. In fact I expect that I'll need to.

kellerkindt · 2020-12-27T22:33:15Z

src/uninitialized_device.rs

+        self.initialize_with_host(host, mode_options)
+    }
+
+    fn initialize_with_host<HostImpl: Host>(


The self.bus is lost on an error here, so there is no way to recover from a temporary issue

Same for Interface::setup

I agree, however I'm not certain that's a huge issue in this particular case. UninitializedDevice can be re-created at basically no cost, it has nothing without being initialized.

kellerkindt · 2020-12-27T22:39:50Z

src/device.rs

+        }
+    }
+
+    pub fn reset(mut self) -> Result<UninitializedDevice<SpiBus>, ResetError<SpiBus::Error>> {


self is lost on an error here, so there is no way to recover from a temporary issue

src/interface.rs

jonahbron · 2020-12-28T18:27:15Z

Thanks for the thorough review. I'll have some time to address your feedback in the new year.

Re: the usage of internal mutability, I wasn't a huge fan either. It is a justifiable design decision though. rust-embedded-community/embedded-nal#4 (comment)

The traits mandate immutable references, which makes a difference in implementation style impossible. If you want to take the design choice war to the NAL repo, I'll have your back 😉

jonahbron · 2021-01-18T16:29:36Z

@kellerkindt I think we're close to a win here! Once it's merged I'll update this PR and review your feedback.

rust-embedded-community/embedded-nal#39 (comment)

jonahd-g · 2021-01-20T06:07:52Z

As an additional note, the chip version assertion does not cover all scenarios? I am working with at least one chip, for which the check does not work at all, so I had to add a way to disable the check.

I have no explanation for that, I pulled that value directly from the datasheet. Can you determine what the value is, or track down a datasheet that mentions a different number?

W5500 Datasheet Version1.0.2(November2013)43/ 66VERSIONR (W5500 Chip Version Register)[R][0x0039]
[0x04]VERSIONR always indicates the W5500 version as 0x04.

Page 43

jonahd-g · 2021-01-20T06:10:39Z

Note-to-self, I've reviewed and addressed all of the feedback except for this paragraph:

I can see the appeal of having definite states, but using it feels a bit clumsy. It also did not find one of my errors while porting it over: I failed to re-bind the UdpSocket after sending data. Also the fact that the device instance is moved in and out of the Option (self.w5500 in the code snippets below) just screams for someone to forget to put it back under some edge case scenario. Moving the InactiveDevice in and out from the option, calling .activate(SpiRef(&mut self.spi)).into_interface() and interface.release().deactivate().0 is also not a perfect experience

I will consider the issues brought up further and come up with a solution/response.

jonahbron · 2021-02-16T01:03:12Z

@kellerkindt I've spent several hours tweaking and thinking, and I can see a couple of simplifications I could make here.

The Interface concept is redundant now that the embedded-nal traits can be implemented directly on the Device struct.
The shared-bus crate would allow us to completely get rid of the distinction between Active and Inactive states. This will simplify the state machine, and completely eliminate the issue you had around needing to store the inactive version in your struct. Are you okay with externalizing that complexity? In practice, that would mean removing any convenient mechanisms for pulling out the SPI bus, and the user would need to use shared-bus (or some other sharing mechanism, like RefCell) if they want to share a single SPI bus between multiple devices.

Also, can you provide some further clarification on this comment?

It also did not find one of my errors while porting it over: I failed to re-bind the UdpSocket after sending data.

I don't understand what you mean here... why does a socket need to re-bound?

jonahbron · 2021-02-16T04:58:14Z

I've gone ahead and made the changes I mentioned.

The only outstanding issues AFAIK are

Need to understand the socket re-binding issue
The version number mismatch you encountered

…ThreeWireBus

…traits to allow users to use shared-bus

jonahbron · 2021-02-26T03:43:13Z

Rebased on to the upstream master branch. @kellerkindt just waiting on those details mentioned in my previous post.

kellerkindt · 2021-02-28T13:30:16Z

src/bus/four_wire.rs

+
+const WRITE_MODE_MASK: u8 = 0b00000_1_00;
+
+// TODO This name is not ideal, should be renamed to VDM


What stands VDM for?

Variable length Data Mode, as defined in the data sheet.

kellerkindt · 2021-02-28T13:31:31Z

src/bus/three_wire.rs

+const FIXED_DATA_LENGTH_MODE_4: u8 = 0b000000_11;
+
+// TODO This name is not ideal, should be renamed to FDM
+pub struct ThreeWire<Spi: Transfer<u8> + Write<u8>> {


What stands FDM for?

Fixed length Data Mode (see screenshot of datasheet above).

kellerkindt · 2021-02-28T13:33:07Z

src/bus/three_wire.rs

+    /// Transfers a frame with an arbitrary data length in FDM
+    ///
+    /// This is done by passing chunks of fixed length 4, 2, or 1.  For example if a frame looks like this:
+    ///
+    /// (address 23) 0xF0 0xAB 0x83 0xB2 0x44 0x2C 0xAA
+    ///
+    /// This will be sent as separate frames in the chunks
+    ///
+    /// (address 23) 0xF0 0xAB 0x83 0xB2
+    /// (address 27) 44 2C
+    /// (address 29) AA


What is the advantage of this behavior?

These two modes are for when you either have or do not have a CS pin. You can connect with only three wires (MISO, MOSI, CLK), but you have to use FDM.

kellerkindt · 2021-02-28T13:37:15Z

src/device.rs

+use crate::socket::Socket;
+use crate::uninitialized_device::UninitializedDevice;
+
+pub struct Device<SpiBus: Bus, HostImpl: Host> {


Shouldnt this be called something like W5500 instead of generically calling it Device?

I felt that was kind of repetitive, considering the crate is already called w5500. w5500::W5500. IMO, I'm willing to discuss renaming.

kellerkindt · 2021-02-28T14:45:45Z

Rebased on to the upstream master branch. @kellerkindt just waiting on those details mentioned in my previous post.

Sorry, I missed that. Thanks for the reminder!

@kellerkindt I've spent several hours tweaking and thinking, and I can see a couple of simplifications I could make here.

The Interface concept is redundant now that the embedded-nal traits can be implemented directly on the Device struct.

The shared-bus crate would allow us to completely get rid of the distinction between Active and Inactive states. This will simplify the state machine, and completely eliminate the issue you had around needing to store the inactive version in your struct. Are you okay with externalizing that complexity? In practice, that would mean removing any convenient mechanisms for pulling out the SPI bus, and the user would need to use shared-bus (or some other sharing mechanism, like RefCell) if they want to share a single SPI bus between multiple devices.

Also, can you provide some further clarification on this comment?

It also did not find one of my errors while porting it over: I failed to re-bind the UdpSocket after sending data.

I don't understand what you mean here... why does a socket need to re-bound?

Nice!
Sounds reasonable. Could you add at least one example though, either for sahred_bus and/or for RefCell.

I am not entirely sure what my issue was, but I think it was along the lines of receiving data and wanting to send a response, which failed (without further clarification) until I bound the (same) socket as UdpSocket (again).

I appreciate your effort - I really do - but I`ll be unable to test your most recent changes in the next few days. I still would like to have an additional way to not own the bus by the Device / borrow it for when I am using it to talk to the W5500 (so I can do some tricks with the scope and lifetimes), but I'll play around with that on my own, after this PR is merged.

jonahbron · 2021-03-01T16:27:04Z

Could you add at least one example though, either for sahred_bus and/or for RefCell.

Yes

I am not entirely sure what my issue was, but I think it was along the lines of receiving data and wanting to send a response, which failed (without further clarification) until I bound the (same) socket as UdpSocket (again).

Hmm, I'll try to write a UDP server and see if I can replicate the issue.

jonahbron · 2021-03-23T04:50:41Z

Finally got back around to this. I am able to replicate the issue around needing to re-bind, using this code:

    let device = UninitializedDevice::new(FourWire::new(spi, cs)).initialize_manual(MacAddress::new(0, 1, 2, 3, 4, 5), Ipv4Addr::new(192, 168, 86, 79), Mode::default());    
    if let Ok(mut device) = device {
        let socket = device.socket();    
        if let Ok(mut socket) = socket {    
            // Binding inside loop works    
            device.bind(&mut socket, 8000);
            loop {    
                let mut buf = [0u8; 16];    
                if let Ok((size, addr)) = block!(device.receive(&mut socket, &mut buf)) {    
                    ufmt::uwriteln!(&mut serial, "received {} {} {} {} {} {}", buf[0], buf[1], buf[2], buf[3], buf[4], buf[5]).unwrap();    
                    device.send_to(&mut socket, addr, &[104, 101, 108, 108, 111, 10]);    
                }    
            }    
        }    
    }

Since I'm able to replicate reliably I should be able to figure out what's causing the issue.

jonahbron · 2021-03-23T05:05:22Z

The fix turned out to be very simple! Just needed to re-open the socket after executing RECV. @kellerkindt afaik that's all outstanding issues resolved. I look forward to your further review and hopefully merging soon!

kellerkindt · 2021-03-23T20:07:06Z

src/bus/mod.rs

+pub use self::four_wire::FourWire;
+pub use self::three_wire::ThreeWire;


How to access FourWire/ThreeWire Error when not public?

Not sure what you mean, bus is public.

This wasn't public before. Otherwise one could not work with the FourWireError type?

src/lib.rs

kellerkindt · 2021-03-23T20:59:01Z

src/uninitialized_device.rs

+pub struct UninitializedDevice<SpiBus: Bus> {
+    bus: SpiBus,
+}


How to restore after deactivate from HostImpl without resetting / loosing device buffer?
Locally I added

pub fn restore_from_host<HostImpl: Host>(mut self, host: HostImpl) -> Device<SpiBus, HostImpl> { Device::new(self.bus, host) }

This can be achieved by instead using initialize_with_host. I'll open a PR to make that function public.

But initialize_with_host resets the device.

I added InactiveDevice for that reason - or do you have better solution?

src/net.rs

kellerkindt · 2021-03-23T21:38:48Z

src/host/manual.rs

+    is_setup: bool,
+    settings: HostConfig,
+    current: HostConfig,


This is quite a fat struct

What do you mean?

The Device<Manual> is about 38 bytes large in memory:

~0 bytes for the SPI-Bus (depending on the optimization)

37 bytes for HostImpl (for Manual)

1 byte for is_setup (maybe we could eliminate this with a generictype and PhantomData, e.g. Manual<Setup> and Manual<NotSetup>)

36 bytes because of 2x HostConfig

6 bytes for mac

4 bytes for ip

4 bytes for gateway

4 bytes for subnet

1 byte for the sockets

What I mean is, that "just for" the feature of not having to always send the whole config in Host::refresh all Device instances consume 18 additional bytes in memory. Assuming that everyone is okay with spending 18 bytes for having the current configuration cached in the first place. In my personal projects I neither need the current state nor the "shall be" state, which means the Device instance is - for me - 36 bytes / 3600% larger than needed.

What I just noticed, If we were to pass the "shall value" HostConfig into Host::refresh we could free up 18 bytes. Because of the trait we would probably require a associated type? Like:

pub trait Host { type Config; /// Gets (if necessary) and sets the host settings on the chip fn refresh<SpiBus: Bus>(&mut self, bus: &mut SpiBus, new_config: &Self::Config) -> Result<(), SpiBus::Error>; //... }

You raise some good points. I'll work on cutting this down.

jonahbron · 2021-03-24T00:14:52Z

woohoo, thanks for merging! I'll get on your latest round of feedback asap (probably tomorrow morning).

kellerkindt reviewed Nov 29, 2020

View reviewed changes

src/lib.rs Outdated Show resolved Hide resolved

src/lib.rs Show resolved Hide resolved

README.md Outdated Show resolved Hide resolved

src/interface.rs Outdated Show resolved Hide resolved

jonahd-g force-pushed the master branch from aa90670 to b4c95a5 Compare December 1, 2020 05:53

jonahd-g force-pushed the master branch from 23f0122 to 40a908c Compare December 2, 2020 16:52

kellerkindt reviewed Dec 28, 2020

View reviewed changes

kellerkindt mentioned this pull request Dec 31, 2020

Revisit on mutable self references rust-embedded-community/embedded-nal#39

Closed

jonahd-g force-pushed the master branch from a5acc67 to 39cfd99 Compare January 19, 2021 21:08

jonahbron added 6 commits February 18, 2021 19:12

Began skeleton of new UninitializedW5500 struct and Bus trait/impls

03e30ef

Added bus model and InactiveW5500 state

a43f86d

Implemented frame transfer for four-wire bus

16e813e

Fixed some masking issues with FourWireBus, added implementation for …

aa0c69b

…ThreeWireBus

Added state-machine diagram SVG

d47de54

Restored chip mode settings/common type structs

3177bad

jonahbron added 11 commits February 18, 2021 19:23

Recovered MAC address docs from previous driver code

259da58

Removed unnecessary extern crate statements

d3ca4a3

Updated to released version of embedded-nal

da2bcd4

Updated UDP impl to be compatible with embedded-nal 0.2.0

9a05719

Updated to latest embedded-nal

d844a11

Removed refcell container from Interface

d6574b8

Updated embedded-nal and removed (now-redundent) Interface struct

5509732

Removed the active/inactive concept, and changed bus to use blocking …

ca8268a

…traits to allow users to use shared-bus

Minor typo fixes, clean-up of the public interface

a3e0911

Minor typo fixes, clean-up of the public interface

daa1c00

fmt

b49f41c

jonahd-g force-pushed the master branch from 8701b1b to b49f41c Compare February 26, 2021 03:42

Short-term net fix

dfa252f

kellerkindt reviewed Feb 28, 2021

View reviewed changes

Updated dependencies, fixed port closing after receive

52f0d06

kellerkindt force-pushed the master branch 2 times, most recently from f8008e0 to 2b82c7f Compare March 23, 2021 19:34

kellerkindt merged commit 52f0d06 into kellerkindt:master Mar 23, 2021

kellerkindt reviewed Mar 23, 2021

View reviewed changes

kellerkindt mentioned this pull request Mar 23, 2021

Adding TCP-based NAL implementation #24

Merged

2 tasks

This was referenced Mar 24, 2021

Support 3-wire SPI bus #15

Closed

Take ownership of SPI/CS? #13

Closed

Vertical Integration #17

Closed


		const WRITE_MODE_MASK: u8 = 0b00000_1_00;

		// TODO This name is not ideal, should be renamed to VDM

		pub use self::four_wire::FourWire;
		pub use self::three_wire::ThreeWire;

Restructure and implement embedded-nal UDP traits #26

Restructure and implement embedded-nal UDP traits #26

Conversation

jonahd-g commented Nov 24, 2020

andresv commented Nov 26, 2020

kellerkindt commented Nov 26, 2020

jonahd-g commented Nov 26, 2020 • edited Loading

kellerkindt left a comment • edited Loading

Choose a reason for hiding this comment

jonahd-g commented Dec 1, 2020

jonahd-g commented Dec 2, 2020

jonahd-g commented Dec 2, 2020

jonahd-g commented Dec 2, 2020

andresv commented Dec 3, 2020

jonahd-g commented Dec 11, 2020

andresv commented Dec 11, 2020

kellerkindt commented Dec 13, 2020 • edited Loading

jonahd-g commented Dec 14, 2020 • edited Loading

kellerkindt left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kellerkindt Dec 27, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonahbron commented Dec 28, 2020 • edited Loading

jonahbron commented Jan 18, 2021 • edited Loading

jonahd-g commented Jan 20, 2021

jonahd-g commented Jan 20, 2021 • edited Loading

jonahbron commented Feb 16, 2021 • edited Loading

jonahbron commented Feb 16, 2021

jonahbron commented Feb 26, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kellerkindt commented Feb 28, 2021

jonahbron commented Mar 1, 2021

jonahbron commented Mar 23, 2021

jonahbron commented Mar 23, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kellerkindt Mar 24, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonahbron commented Mar 24, 2021

jonahd-g commented Nov 26, 2020 •

edited

Loading

kellerkindt left a comment •

edited

Loading

kellerkindt commented Dec 13, 2020 •

edited

Loading

jonahd-g commented Dec 14, 2020 •

edited

Loading

kellerkindt left a comment •

edited

Loading

kellerkindt Dec 27, 2020 •

edited

Loading

jonahbron commented Dec 28, 2020 •

edited

Loading

jonahbron commented Jan 18, 2021 •

edited

Loading

jonahd-g commented Jan 20, 2021 •

edited

Loading

jonahbron commented Feb 16, 2021 •

edited

Loading

kellerkindt Mar 24, 2021 •

edited

Loading