no alloc support

[theunkn0wn1]

I note #71 Which adds support for no_std crates, but capnp still depends on an allocator. It is desirable to have support for environments that do not have an allocator / are memory constrained such as microcontrollers.

In my application, I am presently using postcard to provide object de/encoding on both sides of the wire. Among other features, it supports de/encoding messages out of a &[u8] buffer, thus allowing it to work without alloc.

I am evaluating capnproto to see if it can be a viable replacement for postcard and gRPC (replacing the latter with capnproto's RPC) as to simplify my software situation.

It appears that capnp, even in no_std mode, does not have a mechanism for statically parsing messages.

[dwrensha]

Yes, that is accurate: the capnp crate still requires an allocator. I agree that it would be good to remove that requirement. To achieve that, we would need:

1. An implementation of ReaderSegments that does not allocate
2. To remove the description: String field from capnp::Error, maybe replacing it with an enum.

Note, however, that getting the capnp-rpc crate (as opposed to just the base crate capnp) to work with no_std and no alloc would be a lot more difficult.

[theunkn0wn1]

Thanks for the response.

For Capnproto to be viable, I don't require RPC support in no std; I only require the capability to statically decode a message of known maximum size.

[romixlab]

Tried it on STM32F051 (thumbv6m) with alloc-cortex-m crate. Unfortunately something in capnp::private::layout::wire_helpers::allocate () causes a HardFault to occur on str r1, [r5, #0] instruction, while r1 = 0.

Btw size of the binary increased by approx 10kB after adding allocator and capnp dependencies (with opt-level = "z", codegen-units = 1, lto = true)

Upd: Here is a backtrace:

(gdb) backtrace 
#0  0x08004298 in HardFault ()
#1  <signal handler called>
#2  capnp::private::primitive::{{impl}}::set (value=0, raw=<optimized out>) at /Users/roman/.cargo/registry/src/github.com-1ecc6299db9ec823/capnp-0.14.2/src/private/primitive.rs:43
#3  capnp::private::primitive::WireValue<u32>::set<u32> (self=0x0, value=0) at /Users/roman/.cargo/registry/src/github.com-1ecc6299db9ec823/capnp-0.14.2/src/private/primitive.rs:105
#4  capnp::private::layout::WirePointer::set_kind_and_target (self=0x0, kind=<optimized out>, target=<optimized out>) at /Users/roman/.cargo/registry/src/github.com-1ecc6299db9ec823/capnp-0.14.2/src/private/layout.rs:184
#5  capnp::private::layout::wire_helpers::allocate (arena=..., reff=0x0, segment_id=0, amount=1, kind=<optimized out>) at /Users/roman/.cargo/registry/src/github.com-1ecc6299db9ec823/capnp-0.14.2/src/private/layout.rs:425
#6  0x0800101a in vhrdbutton::__cortex_m_rt_main ()
#7  0x08000cb4 in main ()

[dwrensha]

We got another report of a hard fault using the alloc-cortex-m crate here: #293

[dwrensha]

@romixlab I expect there's a good chance that if you upgrade to capnp-v0.14.10 the HardFault will go away (and probably be replaced by an allocation failure).

[romixlab]

Would be interesting to check again!