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.

[ivmarkov]

Overall LGTM except a couple of nits, and most importantly: I don't think we need the stm32wb module, as explained.

[ivmarkov]

Nit: you might want to replace nRF82840_xxAA with STM32WB55RG

[ivmarkov]

I wonder... shall we shorten stm32-offload to stm32wb?

[ivmarkov]

I think this whole module should be removed. Reasons:

• You don't use it yourself, in your "basic_udp" example so why is it here? If you plan to use it, then create an example which uses it.
• This is the first MCU specific radio in openthread. At the very least it should be named NoopRadio and it is an open question if it should do unreachable! or core::future::task::pending()

[xoviat]

The reason that I created this was because the ENetRunner requires a radio. I will rename it and return core::future::pending.

[ivmarkov]

Have you actually tried ENetRunner with this "radio"?
I strongly suggest copy-pasting the enet example, and the srp example and testing those - perhaps even as part of this PR.

If you still target rs-matter, SRP is mandatory anyway, and the enet example is kinda mandatory if you want to prove to me and yourself that this fake radio is necessary and that in its current shape it works correctly.

BTW: how did you actually test the basic_udp example? Typically, you need a thread dataset?

[ivmarkov]

Also if you are doing this so as to run rs-matter on stm32wb, it might be a bit tight, because the thing only has 1MB flash (right?) and ~ 200-300KB (if not more?) are reserved for the firmware of the offload MCU.

Which leaves you with only 700-800KB for the the rs-matter stack plus the openthread app CPU stubs plus whatever clusters the user would run.

Also, AI is trying hard to convince me that stm32wb specifically is no longer listed as "suitable for Matter" (Matter = the C++ SDK but still, this and rs-matter are in the same ballpark w.r.t. flash size) because of the too little flash, and pointing me at stm32wba which seems to be a completely different architecture (single core, network stack and app stack co-located), and more flash (1MB to 2MB).