Add modbus_reply_callback()#396
Conversation
|
It seems very interesting on first quick review 👍 |
0d21b1b to
bc769b3
Compare
| application_context *ctx = user_ctx; | ||
|
|
||
| /* ... */ | ||
|
|
There was a problem hiding this comment.
I think you want a better example here, ie, what is length meant to be? related, Where is "len" coming from if not the bytes? Your comment above about this being "values" not bytes makes it very hard to do generic code, without having to handle all the modbus function code internals.
There was a problem hiding this comment.
Agreed, the doc needs some more work. Have you looked at the implementation I put into modbus.c for the mapping-reply?
Modbus internals yes, but not many. A user needs to know how to get/put bits and registers out of/into the buffer given to the read and write callback. I chose to propose it like this because it avoids allocating memory and additional copies inside libmodbus.
| { | ||
| application_context *ctx = user_ctx; | ||
|
|
||
| /* ... */ |
There was a problem hiding this comment.
likewize, I feel some trivial, but real example would be better here than just "/.../"
bc769b3 to
524fabe
Compare
|
Please do not merge the pull-request for the moment, I'm currently working actively on it and it is not yet ready. However, the basic idea probably won't change, feel free to comment. |
e76dd39 to
7e56e8f
Compare
|
I made more changes to reduce LOC and thus more DRY, maybe the code has become more complex. Basically the verification-part and read/write-part has been separated in two switch-cases and thus exception-replies are done once for all MODBUS_FC_* as well as value-count extraction of buffers. When reviewing, looking at the diff for modbus.c is maybe not the best idea (anymore). Doc is still missing. |
94cd17f to
8535b71
Compare
8535b71 to
3f8465e
Compare
Based on @frodete's proposal (stephane#319) this implementation adds a a callback-based reply-functionality. The old mapping-implementation is now based on this version. As a nice side-effect some DRY code optimizations could have been done. Also adds a MODBUS_SLAVE_ACCEPT_ALL "address", which can be used with modbus_set_slave(). This makes the modbus_receive()-function accept all requests, independently of the slave-address found in the decoded-request. Useful for multi-slave-implementation using libmodbus.
3f8465e to
d113379
Compare
Based on @frodete's proposal (#319) a more minimalist implementation of a callback-based reply-function.
The old mapping-implementation is now based on this version. As a nice side-effect some DRY code optimizations could have been done.
Unit tests are OK. And my RTU-multi-slave server starts to work.
EDIT:
My motivation for needing a callback-based reply is that I need to implement a modbus-tcp-server and a modbus-rtu-slave. Both will handle the data within a cache. The rtu-slave implementation has to be able to handle multiple slaves. One RS485-port multiple slave-id will be handled.
More details to what I have done: I took the
modbus_reply-function and changed its name tomodbus_reply_callback. Then, each time where something was checked against thestart_bits/start_registers-adresses andtab_*-counts I replaced it with a call to the callbackverify. And each time the payload-part of the request or response-buffer was accesses I replaced it with a call to the callbackreadorwriterespectively.Then I implemented the previous
modbus_reply-function in a way that it uses themodbus_reply_callbackfunction by providing callbacks forverify,readandwrite. In these callback-functions I put the code which previously was in charge to fill in the buffer or to verify the boundaries. By doing so, some code-duplicates have been removed, especially accesses to the buffers in the mapping and its verification.