Feature: Modbus Support about ems-esp32

[proddy]

I've added the Web settings.

Also noticed with modbus enabled it takes up 17kb of heap memory, and 13 when disabled. We need to try and bring that back. I haven't looked into all the code yet.

[mheyse]

How exactly do you compare the heap usage? Build the firmware from dev and from feat_modbus and compare System -> System Memory -> Heap? Or is there a better way?

I suspect that the data I allocate in modbus_entity_parameters.cpp is not stored in Flash (as I thought it would) if it takes up 13kB of heap memory even when disabled.

There are other optimizations I can do (e.g. I register 4 modbus workers each for all ems devices, this could be changed to use ANY_SERVER and ANY_FUNCTION_CODE wildcards)

[proddy]

yes, I actually use a python script for memory profiling but you can also use the WebUI or just read the "free mem" from the JSON output of http://ems-esp.local/api/system

The Modbus is a great feature and easily fits on modern ESP32s like the S3, but it will struggle on 4MB variants. We just need to find ways to reduce the amount of heap memory if Modbus isn't been used. When it's enabled it's fine as that is the price to pay for a new module/feature.

I see the object ModbusServerTCPasync instantiated as default but this can't be the main culprit, something else is eating the memory, even when it's disabled.

[proddy]

could you possibly instantiate ModbusServerTCPasync from within Modbus::start() and just use static pointers? This may save on heap memory.

Also check that LOCAL_LOG_LEVEL is not set, unless EMSESP_DEBUG is.

I'm working on a new C++ Factory class so we can try this as a hot-pluggable module. Could you describe which integration points you have with EMS-ESP? I see the start() but you have nothing in the loop() ?

[proddy]

dev has 190KB free heap, feat_modbus with Modbus disabled and using the Michael's change to static Modbus * modbus_ is 177KB so we're still eating up 13KB of memory even if not using Modbus. We need to bring this down before accepting into the dev branch. Can you see what you can do @mheyse ?

[mheyse]

Yes. The issue is the static data with the Modbus Parameters. It ends up in the .flash.text section but apparently it's copied to RAM anyways, even after I've made everything const. I guess I have to familiarize myself with the ESP32 memory model to debug this.If all fails I can still try to embed the data as a static binary but that will be pretty ugly.Allocating the Modbus client dynamically in start() doesn't help at all by the way.Am 09.05.2024 16:57 schrieb Proddy ***@***.***>: dev has 190KB free heap, feat_modbus with Modbus disabled and using the Michael's change to static Modbus * modbus_ is 177KB so we're still eating up 13KB of memory even if not using Modbus. We need to bring this down before accepting into the dev branch. Can you see what you can do @mheyse ? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[proddy]

The design pattern is that Modbus should allocate as little to no heap memory if the service is not enabled. So something is still lurking in the headerfiles and eating up the heap during runtime (not static, progmem/flash). I still suspect it's the creation of the ModbusServerTCPasync object in modbus.cpp - see if you can turn that into a pointer and new-it when it needs to be created.

[mheyse]

I did make the ModbusServerTCPasync a pointer and allocate it dynamically in "Modbus::start" using new - no change at all in memory consumption if Modbus is disabled. I'll push the changes anyways. On the other hand, if (just as a test) I remove all entries from modbus_register_mappings this reduces memory consumption by about 10kB if Modbus is not enabled - so it's this static data that somehow allocates heap memory. I have to figure out how to solve that because it should be possible to have this static data in flash only. Unfortunately I have a project to finish at work and not a lot of spare time, but I'll look into it as soon as possible.

…

------ Originalnachricht ------ Von "Proddy" ***@***.***> An "emsesp/EMS-ESP32" ***@***.***> Cc "mheyse" ***@***.***>; "Mention" ***@***.***> Datum 10.05.2024 10:16:27 Betreff Re: [emsesp/EMS-ESP32] Feature: Modbus Support (Issue #1744)

The design pattern is that Modbus should allocate as little to no heap memory if the service is not enabled. So something is still lurking in the headerfiles and eating up the heap during runtime (not static, progmem/flash). I still suspect it's the creation of the ModbusServerTCPasync object in modbus.cpp - see if you can turn that into a pointer and new-it when it needs to be created. — Reply to this email directly, view it on GitHub <#1744 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJD5GWEIQNE6BM4B25OCM3ZBR65XAVCNFSM6AAAAABHIYXM6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBUGE2TQNJTHA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[proddy]

that's probably it - missed that. The modbus_register_mappings list and tag_to_type map. Is there a way to populate both these in the start() function using static_ptr? Also watch out for that Serial.print() in the start() function - sending Serial on a live EMS-ESP can cause havok since we're spoofing the UART for the EMS bus.

even better is to make it dynamic, like we do with HA MQTT Discovery so the modbus registry's are only created when a valid ems device entity is found.

[mheyse]

FYI, I submitted another PR addressing the memory iasues: #1770

[proddy]

thanks, I'll take a look and run some more benchmarking. I've been out the last weeks. I still need to fix the Web settings right?

[mheyse]

Yes, I didn't do anything regarding the web settings.Am 28.05.2024 13:45 schrieb Proddy ***@***.***>: thanks, I'll take a look and run some more benchmarking. I've been out the last weeks. I still need to fix the Web settings right? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>