qwerty19106

5. I removed `bytes` dependency in [#136](https://github.com/mavlink/rust-mavlink/pull/136) because of it not supports `no_std` mode. First I wanted write PR for `bytes`, but its API strongly depends on `alloc` dependency. I...

The `bytes` support `no_std`, but requires `alloc`. The `alloc` use heap, which is not recommended for most of `no_std` architectures, such as Cortex-M and RISC-V microcontrollers. You can not `impl...

It is good idea. You can make small PR, which remove `heapless::Vec` from parser? Need to think about MessageMeta and MessageData, I think that it can simplify.

I think `***_DATA::default()` will be inlined. Thus `default` field is not necessary. Traits supports associated constants in stable rust (1.20). I propose this API: ```rust pub trait MessageData { const...

Your API requires ~16 bytes on each `MessageMeta` object. For `mavlink::common::Message` RAM size will be increased (if I call `Message::meta` in my code) on 203*16 = 32KB. Typical RAM size...

Embedded example is very simple. In real code I use RTOS, allocators, lock-free queues, et.al. To send message first I get object from allocator: ``` use heapless::{mpmc::Q4, object_pool, Object}; pub...

At first it seems like a good idea. But I checked the generated assembler code on Cortex-M4 (ARM). ``` #![no_std] #[repr(u32)] pub enum E { A(u8) = 5, B(u16) =...

You example with `--cfg discriminant` generates 2 table which contains 216 `LBB0_210` (padding). It gives ~432 bytes. Without `--cfg discriminant` compiler generates 1 table with 0 padding. With `--cfg discriminant`...

With `--cfg discriminant` compiler generates 2 table (836 bytes) for `match msg { ... all variants ... }`, and 0 table (~4 bytes) for `fn message_id(&self)`. Without `--cfg discriminant` compiler...

Any updates for it?