move statime-embassy-stm32 into statime

[jordens]

As a heads up: we added the PTP tooling around embassy-net/embassy-stm32 through embassy-rs/embassy#6325, embassy-rs/embassy#6327, and embassy-rs/embassy#6359.

https://github.com/quartiq/statime-embassy-stm32 contains both a reusable PTP runner as well as an example.
There is already statime-stm32 and while it's a working template, it's not a reusable lib crate that would plug into an existing app.

Since the code is tightly statime-bound, statime-embassy-stm32 may well fit into the statime repo as well and we'd be happy to donate it.

cc #140 #56

[davidv1992]

Thank you for your interest in the statime ptp implementation, and cool to see another integration of the library with network and clock drivers.

Right now we are not in a good position to adopt this, as we are in some major refactor work over the next months, during which we will likely be integrating statime more closely into ntpd-rs. Once that has quieted down a bit, we might want to consider this but I cannot make a strong statement on that at this time.

Would it be Ok if we get back to you with a decision on this later?

[jordens]

Sure.
If you focus more on ntpd-rs (which does seems worthwhile), does that mean you'll abandon the embedded support in statime? I do think a embedded (no_std, no alloc, small, bare metal) PTP stack is extremely high-value for all kinds of reasons.

[davidv1992]

We are planning to keep the no_std no_alloc PTP stack (in fact, I am still dreaming of someday also making our ntp stack that), its just that with all the reorg that is happening that we just dont have the bandwidth right now to really take a good look at this.