Looking for Comments: Adopting core::cell for dynamic borrowing in RTIC

[HarryMakes]

(Note: the following write-up has not been edited or cleaned up.)

Summary

A total of 3 aspects should be discussed:

1. Re-factoring SpiEth and smoltcp_phy::SmoltcpDevice for dynamic borrowing
2. Applying RTIC to the current examples, which could benefit from dynamic borrowing
3. Deciding the system timer: current SysTick timer, or monotonic timer based on RTIC's CYCCNT

Major modifications

When I was trying to implement this driver in an RTIC-based project (e.g. sinara-hw's Booster), I encountered the issue where the SPI controller SpiEth object was needed to be borrowed twice, because this SpiEth object and the smoltcp interface smoltcp::iface::EthernetInterface object were instantiated as "late resources" in the RTIC model. SpiEth was borrowed when instantiating EthernetInterface because my original implementation for the smoltcp::phy::Device trait is a struct that contains a mutable reference to the SpiEth object.

From what I've observed, when smoltcp is used in RTIC, the interface is more often related or bound to a register block in STM32 like ETHERNET_DMA. However, since the Tx and Rx buffers are accessible by a serial interface instead of DMA in our case, a custom class (SpiEth) binds to the interface instead, and done by the means of mutable reference instead of moving. This prevents me from instantiating the interface in [#init].

To avoid the restrictive borrowing rule at Rust compile-time, I decided to re-factor the smoltcp_phy::SmoltcpDevice struct such that it now contains a core::cell::RefCell mutable container wrapping the target SpiEth. This removes the need to extend SmoltcpDevice's lifetime to the SpiEth object. I also cleaned up my code to avoid using trait objects. The code now uses generics and trait bounds for static dispatch - although using RefCell to borrow means dynamic borrowing.

Minor modifications

When I was developing the RTIC examples, I also became aware of the CYCCNT monotonic timer provided by RTIC, whose mechanism is about "adding" clock cycles to a 32-bit clock value. By experimenting with the code, this method would bring indefinite delays, as demonstrated by the time-out feature of the port 1234. For example, the time-out could be delayed by more than 2 seconds:

[0.0s] Listening to port 1234 for echoing, time-out in 10s
[0.0s] Listening to port 4321 for greeting, please connect to the port
[11.389s] Received packet: Ok("asdasdasads\n")
[23.491s] Listening to port 1234 for echoing, time-out in 10s

Meanwhile, some other existing RTIC projects that uses smoltcp seem to ignore the delay and simply use CYCCNT. Therefore, it would be great to know whether or not SysTick is preferred over RTIC's monotonic timer.

[astro]

This looks like a really good idea to me. It seems to get rid of lifetime hacks.

[HarryMakes]

I just force-pushed this branch again to apply styling/spelling/simplification of the code in master (4ba5052) first, which has solved all merge conflicts. This latest push (eeea973) has been tested on STM32-H407, but further testing on other platforms are welcomed.