Discussion:
[capnproto] Cap'n'proto on microcontrollers
David Ondrušek
2017-10-05 19:06:45 UTC
Permalink
Hi Kenton,

I'm developing an IoT device using the ESP8266 wifi-enabled
microcontroller. When connected to wifi it has 48kB free RAM.
Cap'n'proto is useful for my project since message building/reading is a
static process. So it's easy to check if there is enough free memory to
process the message. That's important because while modern microcontroller
toolchains do compile C++ code. C++ exceptions aren't really supported.

What i'm unsure about is if i should also port over the two party RPC
implementation. It would make communication a lot easier. But i don't know
if that's even feasible given the low memory available.
--
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 capnproto+***@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
'Kenton Varda' via Cap'n Proto
2017-10-05 20:09:02 UTC
Permalink
Hi David,

I'm not sure, but I suspect you may have a tough time with the RPC
implementation -- and the KJ async framework in general -- in such a
constrained environment. :/

Disabling exceptions should be OK -- everything is designed such that it
should still work (although fatal errors may abort the process). But the
async stuff is pretty malloc-heavy and I don't think it would be easy to
guarantee that memory usage stays under your threshold.

-Kenton

On Thu, Oct 5, 2017 at 12:06 PM, David Ondrušek <
Post by David Ondrušek
Hi Kenton,
I'm developing an IoT device using the ESP8266 wifi-enabled
microcontroller. When connected to wifi it has 48kB free RAM.
Cap'n'proto is useful for my project since message building/reading is a
static process. So it's easy to check if there is enough free memory to
process the message. That's important because while modern microcontroller
toolchains do compile C++ code. C++ exceptions aren't really supported.
What i'm unsure about is if i should also port over the two party RPC
implementation. It would make communication a lot easier. But i don't know
if that's even feasible given the low memory available.
--
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
Visit this group at https://groups.google.com/group/capnproto.
--
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 capnproto+***@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
Vitaliy Bondarchuk
2017-10-06 09:10:12 UTC
Permalink
imho, Capnproto is too heavy even for successor, dual core ESP32
i can suggest use more lightweight binary flat-serialization protocol, or
don't invent bicycle and use JSON (with RapidJSON library) + JSONRPC 2.0.
and as transport trivial http+WebSocket is enough.

четверг, 5 Пктября 2017 г., 22:06:45 UTC+3 пПльзПватель David OndruÅ¡ek
Post by David Ondrušek
Hi Kenton,
I'm developing an IoT device using the ESP8266 wifi-enabled
microcontroller. When connected to wifi it has 48kB free RAM.
Cap'n'proto is useful for my project since message building/reading is a
static process. So it's easy to check if there is enough free memory to
process the message. That's important because while modern microcontroller
toolchains do compile C++ code. C++ exceptions aren't really supported.
What i'm unsure about is if i should also port over the two party RPC
implementation. It would make communication a lot easier. But i don't know
if that's even feasible given the low memory available.
--
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 capnproto+***@googlegroups.com.
Visit this group at https://groups.google.com/group/capnproto.
Loading...