search

esp-rs / esp-hal

no_std Hardware Abstraction Layers for ESP32 microcontrollers
https://docs.esp-rs.org/esp-hal/
Apache License 2.0
717 stars 194 forks source link

Async support for IEEE 802.15.4. #2208

Open Frostie314159 opened 1 week ago

Frostie314159 commented 1 week ago

Motivations

Hi, I'd like to build async support for esp-ieee802154 in the future. I wanted to ask if any extensive docs on the hardware registers for ieee802154 are available, so I can try and build an async layer.

Solution

Alternatives

Additional context

lattice0 commented 1 week ago

Also would like this. It blocks the hardware a lot currently, preventing quality development for thread/zigbee stuff

bjoernQ commented 1 week ago

Unfortunately, there is no additional documentation about that peripheral that I'm aware of. A few things could be derived from the code but we don't have anything beyond that.

For async luckily you probably can get away with implementing Futures around the existing interrupt functionality at least

lattice0 commented 1 week ago

Would be nice if espressif stopped making these internals so secretive, I bet any competitor can already reverse engineer it anyways. We're seeing a huge boost on thread/matter devices and I'd love for them to be in Rust. Async support on places like the ieee801254 stack is a must. Not to mention how Rust would make these products much more stable, I always have problems with zigbee devices that need to be resetted because of bugs.

This might make me switch to other boards with better ieee801254 rust support. Anyways, thanks for the answer everyone

Frostie314159 commented 1 week ago

Would be nice if espressif stopped making these internals so secretive, I bet any competitor can already reverse engineer it anyways. We're seeing a huge boost on thread/matter devices and I'd love for them to be in Rust. Async support on places like the ieee801254 stack is a must. Not to mention how Rust would make these products much more stable, I always have problems with zigbee devices that need to be resetted because of bugs.

This might make me switch to other boards with better ieee801254 rust support. Anyways, thanks for the answer everyone

I'll have to defend Espressif a little here. I personally contribute to the project reverse engineering the WiFi peripheral, and would of course like register docs. The thing is though, that Espressif didn't design the WiFi, BLE,IEEE 802.15.4 and RF peripherals themselves, but licensed these from CEVA (previously Riviera Waves). They're thus bound by certain NDAs and legally can't publish any of this. I would love a general shift in the industry towards more openness, because sadly the assumption that all mobile communication stacks are flawed is correct, but realistically this won't happen.

lattice0 commented 1 week ago

@Frostie314159 makes sense, I know nothing about these legal obligations. I thought they made their own radio.

So, espressif, if you're reading this: would be nice to have proper rust async support for the iee radio and bluetooth/wifi as well. I'd like for future matter devices to be rust instead of C, I have seen way too many buggy zigbee devices that probably enter a bad state after days online and I have to turn them off and on again.

The thread border router board that you guys offer is pretty nice, but official support is for C only.

Frostie314159 commented 1 week ago

I'll do my best to build an async version from the limited knowledge we have. Although, I'll have to see how much time I've to do that.