Are there plans to not use the std lib? I know nothing about embedded devices, but it looks like would be nicer to have no std in this one. I'm trying to put it into the ESP32 and had to activate std stuff.

I don't know, it looks like this MCU is too slow for std

I wish to implement the 6LoWPAN standard on no_std rust. Right now I'm searching for IEEE 802.15.4 link-layer implementations. It would be really helpful If you can point me towards the relevant sections. Right now Im looking at the psila-data crate. Thank You!

Hi Erik,

I noticed you've found my Zigbee/Rust experimentation, and in turn I've stumbled upon your project. It turns out that there's quite a big overlap, and I would like to have a chat to see if we could split off the parts of our projects that we could use together (e.g. mostly the 802.15.4 & Zigbee data structures).
I'm quite fond of your Pack trait (in contrast to my Serialize/Deserialize traits), and I could port my automated deriving for basics structs and enums over to that trait.
The point of contention I do see is that you're bound by no-std, while I'd like to enjoy the comforts of std in my hub implementation, so we'd have to figure out a pack function that could either take a pre-allocated &mut [u8] as well as a &mut Vec, and similarly would have to figure out data-structures that fit both our use-cases.

If you're interested, we could continue the conversation here, or feel free to e-mail me at [email protected].

Frans-willem

I just got a esp32 and when interpreting the mac frame with psila, I get packets with strange cluster and profile numbers:

################
nwk: NetworkHeader { control: FrameControl { frame_type: InterPan, protocol_version: 14, discover_route: EnableDiscovery, multicast: true, security: false, contains_source_route_frame: false, contains_destination_ieee_address: false, contains_source_ieee_address: false }, destination_address: ShortAddress(0), source_address: ShortAddress(0), radius: 0, sequence_number: 0, destination_ieee_address: None, source_ieee_address: None, multicast_control: None, source_route_frame: None }, used: 2

security header: SecurityHeader { control: SecurityControl { level: Integrity64, identifier: Network, has_source_address: false }, counter: 785921159, source: None, sequence: Some(4) }
APS: ApplicationServiceHeader { control: FrameControl { frame_type: InterPan, delivery_mode: Unicast, acknowledge_format: true, security: true, acknowledge_request: false, extended_header: true }, destination: None, group: None, cluster: Some(13323), profile: Some(0), source: None, counter: 0 }
SEC SecurityHeader { control: SecurityControl { level: EncryptedIntegrity64, identifier: KeyLoad, has_source_address: false }, counter: 72418744, source: None, sequence: None }
payload loaded, size: 96

which when converted to hexadecimal have nothing to do with the cluster and profiles listed on zigbee's documentation. Is it possible that this library is just interpreting random stuff as an APS header? I'm still waiting for my sniffer to arrive so I can look better on wireshark.