Hi Johann, thanks for the reply!
>> There are a few of reasons why having this feature would be nice:
>> - As of now, it seems that the full Modbus spec isn't implemented and
>> this would allow end users to work around that, if necessary.
>> - Modbus has specific function ranges for user defined features.
>> - Since Modbus is easy to extend, it's not uncommon to do so.
> There is a mandatory function from the spec that is not implemented? Which one?
Well, depends on how you look at it whether you'd consider it
mandatory. The spec
section 5 p. 10 says that there are specific ranges of user-defined
function codes whose implementation is left to the vendor, referring
to device manufacturers. The existence of said ranges probably doesn't
count as a mandatory requirement for the software stack provider (in
this case Zephyr), but device vendors might consider it a requirement
when selecting a stack. Anyway, it's a nice feature to have.
> It could work, struct modbus_server_param should also be changed accordingly.
> And we would need test for this functionality.
I was originally thinking of adding a new API function in the lines of modbus_register_function(),
but adding a pointer to modbus_server_param is arguably simpler.
I haven't had the time to dig into the testing side of Zephyr. I guess the tests are written against QEMU?
If so, I might try to add a few tests next.
Btw, what's your preferred workflow with GitHub PRs? Mainly, should I open an issue before creating
a PR and who to add as reviewers? I scanned the maintainers file but couldn't find a suitable
section for Modbus.