Repository navigation
move statime-embassy-net into statime #845
Description
Activity
- changed the title
[-]embassy stm32[/-][+]move statime-embassy-stm32 into statime[/+]on Jun 16, 2026 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?
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.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.
Reacted by Robert Jördens- changed the title
[-]move statime-embassy-stm32 into statime[/-][+]move statime-embassy-net into statime[/+]on Aug 19, 2026
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-net contains both a generic PTP runner over embassy/statime traits, an impl of the traits for stm32 as well as an example.
There is already
statime-stm32and while it's a working template, it's not a reusablelibcrate that would plug into an existing app.Since the code is tightly
statime-bound,statime-embassy-netmay well fit into thestatimerepo and we'd be happy to donate it.cc #140 #56