That sounds promising! On Wed, Jun 9, 2021 at 3:32 PM Kenton Varda <[email protected]> wrote:
> Hi Kenny, > > Avoiding malloc should be easy. With custom subclasses of MessageReader > and MessageBuilder, you can do your memory management any way you want. > Cap'n Proto's serialization layer is very good about avoiding memory > allocation unless you ask for it. > > (The RPC layer, on the other hand, does lots of dynamic allocation, and > there's no way around that. But, it sounds like you're interested in the > serialization only.) > > -Kenton > > On Wed, Jun 9, 2021 at 3:03 PM Kenny Koller <[email protected]> > wrote: > >> Thank you Kenton. >> >> I certainly understand that the "big server" use-case is far more common >> (embedded software engineers everywhere are weeping in their Cap'n >> Crunch**) and I appreciate the clarification regarding CAPNP_LITE. >> >> Personally, I find that code space is much less of a concern these days >> within reason (though it shouldn't be completely ignored). Many of these >> microcontrollers have quite a bit of flash. This is obviously not true for >> very inexpensive devices but there are plenty of applications where the >> cost of the processor is negligible relative to the device as a whole. >> >> The more pressing issue is avoiding (possible) memory fragmentation when >> using new or malloc. C++ has been my language for choice for my embedded >> development for more than 20 years. I suspect, if I had time, I could have >> looked into overriding some classes to provide my own chunks of memory. >> Just having say 16 256 byte chunks that I could recycle would probably do >> the trick. >> >> Thanks again, >> >> Kenny >> >> **With crunch berries because we're adults. >> >> On Wed, Jun 9, 2021 at 10:44 AM Kenton Varda <[email protected]> >> wrote: >> >>> Hi Kenny, >>> >>> The code is fairly modular, so I think it should be possible to pull out >>> a subset that has a reasonably small code footprint. However, this is >>> admittedly not a well-traveled path, so you'll be a bit on your own. The >>> maintainers of the C++ implementation (such as myself) mainly use it on big >>> beefy servers, so we haven't had a whole lot of reason to work on >>> optimizing code footprint. >>> >>> CAPNP_LITE might be a good starting point. Note that that option was not >>> really designed to minimize code footprint, but rather was designed to >>> identify a subset of code that could be compiled on MSVC circa 2013. MSVC >>> has since improved, and is now able to compile the whole codebase. Hence, >>> CAPNP_LITE is a bit vestigial now and may have bitrotted somewhat. But, it >>> definitely does cut out a lot of bulkier parts of the library, which you'd >>> also want to remove in an embedded system. So it might be a good guide. >>> >>> Another option that might be less work would be to use c-capnproto, >>> which I think is more explicitly designed for constrained use cases. >>> >>> -Kenton >>> >>> On Mon, Jun 7, 2021 at 10:52 AM Kenny Koller <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> My team and I were hoping to use Cap'n P on our system to pass messages >>>> around via UDP. There is a powerful Linux system running a control system >>>> but the nodes are STM32F7 devices (1 MB flash, 320 kB of RAM, 216 MHz >>>> Cortex-M7 processor) running FreeRTOS with the LWIP networking stack. >>>> >>>> When I tried to build for the embedded system I ran into some errors >>>> related to a dependency on pthreads (in the KJ library I believe). >>>> >>>> I did some searches and saw discussions in this group from 2015-16 that >>>> suggested things like inheriting from MessageBuilder to get around using >>>> malloc or using nanopb instead. >>>> >>>> I don't fully understand what CAPNP_LITE gets me so maybe this would be >>>> helpful. >>>> >>>> What is the thinking today on this topic? >>>> >>>> Thanks, >>>> >>>> Kenny >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Cap'n Proto" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/capnproto/81988491-bcde-4025-b9b8-74f9a06c6eebn%40googlegroups.com >>>> <https://groups.google.com/d/msgid/capnproto/81988491-bcde-4025-b9b8-74f9a06c6eebn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJAKWv8w-QRioKNwBPHt8ifAp7pNzpa8i1iMHGC9FeLvqwEOOg%40mail.gmail.com.
