Default memory footprint is too large about homekitadk HOT 9 OPEN

A port for ESP32/ESP32S2 has been made available here: https://github.com/espressif/esp-apple-homekit-adk

from homekitadk.

FWIW, i found 1.5k i/o buffer size to be adequate. it has to be greater than 1k + some crypto padding to be able to contain 1k encrypted frames.
further, in my mongoose-os port of the library. i've successfully made all the buffers dynamic, so that at present the largest statically allocated structure is the sessions array, followed by the scratch buffer.
esp8266 build of the shelly-homekit firmware is able to support 9 concurrent connections with about 20k to spare.

the key changes are:

• readContexts - mongoose-os-libs/homekit-adk@ace7e0f
• writeContexts - mongoose-os-libs/homekit-adk@5a97a69
• eventNotifications - mongoose-os-libs/homekit-adk@2ddb188
• inboundBuffer - mongoose-os-libs/homekit-adk@c2aaf26
• outboundBuffer - mongoose-os-libs/homekit-adk@d70ad2c

if there is interest, i can try to upstream the changes, as a compile-time option.

from homekitadk.

I'm also looking for guidance on the size of the scratch buffer - 32K is obviously a no go, but how much is really needed?

from homekitadk.

ESP32 has 200K or so

That's weird, Espressif distributes the MFi version of the HomeKit ADK for the ESP32... Surely there is some info we are missing here.

https://www.espressif.com/en/products/software/esp-homekit-sdk

from homekitadk.

they may have reduced buffer size and/or number of sessions.
this is why i'm looking for clarity on the required size. 32K seems excessive when the spec says max payload size is 1K.
@aajain-com ?

from homekitadk.

if anyone's interested, i've been gradually converting static allocations to dynamic in my Mongoose OS port: readContexts, writeContexts, eventNotifications.

i/o buffers will be more challenging, but i have no choice...

from homekitadk.

if anyone's interested, i've been gradually converting static allocations to dynamic

I believe that in embedded systems, dynamic allocation is generally frowned upon, and with good reasons.

Maybe compile time configuration is a more fitting solution ? Like a "easy-to-access" header defining all the buffer sizes or a configuration file used to set the defines at compile-time.

from homekitadk.

i am well aware of that.
but Mongoose OS, for one, embraces dynamic allocation, we're brave like that :)
i mean, i'm all for static allocation, but current sizes are simply not viable for many platforms, including all of the ones we support.
for me, the choice is between "no way, forget it" and "will work unless all the clients decide to request all the attributes at the same time".

"easy-to-access" header defining all the buffer sizes or a configuration file used to set the defines at compile-time.

it's perfectly possible to define all the necessary constants right now, the problem is that the produce of all the necessary buffers blows through available memory for the platforms in question.

from homekitadk.

it's perfectly possible to define all the necessary constants right now, the problem is that the produce of all the necessary buffers blows through available memory for the platforms in question.

Is it not possible to simply calculate the total size of the buffers beforehand ? For example, "we know the ESP8266 does not have enough memory for the default sizes, but if you set them at these values, it's going to work".
If it is possible, maybe we could make a document giving the buffer sizes that should be defined for popular platforms ?

from homekitadk.