IO_Modbus #429
Open
IO_Modbus #429
+1,060
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I would like to include my Modbus driver for Hal into the available methods of I/O communication.
More info and usage can be found Here.
More info about Modbus can be found Here.
it has been tested on a STM32 F439ZI, and needs to be tested on other boards. I have it set to error out on unsupported boards, unless the flag MBEXPERIMENTAL is defined in config.h, and that is only to weed out use for untested boards, but the flag is there to allow beta testers to test other boards.
it requires no external libraries, as i have squashed them into one driver, and re-wrote it to be the least blocking i can.
in testing, when the test node is communicating, there is no noticeable lag in sending DCC commands. there is only a slight update lag between changing an input pin on a node, and JMRI updating the status. when the node is unplugged, there is also no lag in sending DCC commands noticed, but other nodes will be very lagged while it tried to make contact with the lost node. when the node is replaced, it takes a moment to boot, and Modbus spits out a CRC error due to the lost command, but recovers very quickly after that. again, with no lag in DCC commands noticed.
i have tested various baud rates, and in my tests, 115200 worked well, but may need to be slowed down in severe noise and distance.
please feel free to ask any questions. :-)