add support for stm32wb offload

[xoviat]

This allows support for thread offload to be implemented in embassy-stm32-wpan. Ideally, async rust would be propagated further down the call chain but that would involve far more refactoring that would only benefit stm32wb users (a small userbase) and therefore this is the approach I have taken.

[ivmarkov]

Interesting...

I must admit that the esp-idf-sys code-path route you have taken for the stm32wb offloading impl is actually not really used, because - in the end - the ESP-IDF-based Rust (Open)Thread support ended up with its own separate bindings and high-level Rust wrapper for reasons.

Help me understand:

• Is this stm32wb support good enough for you, or just the beginning and more work would follow, which might change the approach completelty?
• If it is good enough, you probably have a working example?
• But if yes, I'm banging my head how it works given that I don't see any implementation of the Radio trait for the stm32wb?

[xoviat]

Is this stm32wb support good enough for you, or just the beginning and more work would follow, which might change the approach completelty?

Specifically, when calling an open thread function, the core could block for ~500us (I have not measured it, but that is a hypothetical estimate) when, if implemented with async fns the core could run other tasks in the interim. Solving this would require potentially a huge amount of work that would have no benefit for other platforms and save at most 500us per ot function call. This is speculative because the blocking time could be even less.

If it is good enough, you probably have a working example?

I do not have a working example yet.

But if yes, I'm banging my head how it works given that I don't see any implementation of the Radio trait for the stm32wb?

otPlatRadioTransmit is never called and therefore the radio transmit never runs. same is true for the receive. embassy-stm32-wpan will implement a fake radio trait that does nothing to allow all of this to compile. However, this does raise one problem: I need to either move the trait to another crate that does not depend on embassy-time or make embassy-time optional. Otherwise, we'll have dependency hell in embassy when embassy-time is updated.

[xoviat]

Would you be alright if I made a new openthread-radio crate with just the radio trait?

[ivmarkov]

I do not have a working example yet.

But if yes, I'm banging my head how it works given that I don't see any implementation of the Radio trait for the stm32wb?

otPlatRadioTransmit is never called and therefore the radio transmit never runs. same is true for the receive. embassy-stm32-wpan will implement a fake radio trait that does nothing to allow all of this to compile. However, this does raise one problem: I need to either move the trait to another crate that does not depend on embassy-time or make embassy-time optional. Otherwise, we'll have dependency hell in embassy when embassy-time is updated.

The fake/noop Radio trait impl can just be a part of openthread itself, as I assume there is nothing stm-specific in it being a no-op/panicking.

With that said, otPlatRadioTransmit not being called and same for receive sounds weird to put it mildly. Are you running some sort of heavily patched/modified OpenThread variant?

Or (more likely) is the OpenThread variant you are running an RCP (or - hm - NCP): https://openthread.io/platforms/co-processor (sorry - STM is not really something I've ever played with).

If yes, perhaps we have to enable support for these in openthread and that's what you actually need?

Last but not least - you can ping me in esp-rs or embassy (username ivmarkov) and perhaps we can discuss there or in private on Matrix.

[xoviat]

needs to be fixed

[xoviat]

@ivmarkov I believe this is ready.