Question about directly accessing holding register data array via union #124
Labels
topic: documentation
Related to documentation for the project
type: enhancement
Proposed improvement
I have developed an application using yaacov ArduinoModbusSlave via RS485 serial
That library requires the program allocating the array of data structures and then using
a union to link the application memory and the modbus holding register space.
This enables conserving memory by having only a single array in memory.
I need to upgrade the application to use TCP rather than RTU and so far I am not clear how to migrate
the ethernet support from ESP to Ethernet shield v2 W5500
I have successfully upgraded the RTU version of the Kitchen Sink which was/is missing from the TCP examples.
Is there a way to create an array of data structures and have it overlay the memory
which is allocated by:
modbusTCPServer.configureHoldingRegisters(0x00, numHoldingRegisters);
I'm guessing this allocates memory somewhere which is normally only accessed via
As I write this I am realizing I could probably do what I need by sacrificing the struct and the element naming
and just brute force the accesses by organized indexing...
something like defining the current structure element names as constants
and then
i = struct_index * struct_size + struct_element
Anyway, I thought I would ask the question anyway... maybe there is a way to find the address of the
HoldingRegister
array and union it with the structure array...Oh... I noticed one little anomaly related to my conversion of KitchenSink RTU to TCP...
In both RTU and TCP, toggling the LED to ON takes effect immediately
in RTU the LED goes off immediately. In TCP version there is initially no change, and then after a few seconds
the LED kinda fades to OFF - a shaky dimming rather than switching OFF
Feel free to check this code and stick it in the TCP examples...
I always think example code should be more than the bare minimalist simplest functionality
leaving any practical implementation as further mysteries ;-)
The text was updated successfully, but these errors were encountered: