-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EX-IOExplorer485 CS-side portion #433
Closed
Closed
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 made a Hal driver for a EX-IOExplorer, over RS485 (half-duplex). this is the CS-side portion. the node portion is at https://github.com/travis-farmer/EX-IOExpander485
the nodes compile as follows:
nanoatmega328new, nanoatmega328, pro16MHzatmega328, pro8MHzatmega328, uno, mega2560 SUCCESS.
Nodes tested on a Mega2560. need further config on a per-board basis by those that know the boards. nodes not compiled for nucleo or SAMD as i don't know the serial ports needed. can be added per-board.
CS side tested on a Nucleo F439ZI. needs further testing on other platforms. will not work on single UART boards, or boards with only two UARTs with Seral WiFi enabled. should work on a Mega 2560, i would think.
this is the first submission to get the code available for beta testers, while i draw up a write-up on it's use. the Write-up i will make into a PDF so the information can be copied to the DCC-EX website as needed.
the myAutomation.h lines i used on my F439ZI are:
HAL(EXIO485,0, Serial5, 115200, 51, 75)
(serial port, baud, TX enable pin, unused number... will fix that later)
HAL(EXIO485node, 300, 62, 1)
(first pin, number of max pins of node, node ID)
there is still work to do, but while it works, i wanted to add it to the DCC-EX codebase. before i break it again... ;-)
TODO:
fix the unused number in the EXIO485 call.
setup board configs for more node boards, Mega 2560 known working.
fix max number of pins in EXIO485node call and in node per-board configs to subtract for conflicted pins removed (62 would become 59, as 3 pins on the Mega2560 are used for comms)
Hardware used to test:
CS side, i used a RS485 module connected to Serial5 UART, and pin 51 for TX enable, plus 5v and Gnd for the module. there is a voltage divider between the module TX and the Serial5 RX for 3.3v compensation. not needed with 3.3v RS485 shield listed below.
Node side, i used a Frankenstein looking circuit to connect a MAX485 chip to the Mega 2560.
both can be replaced with a 3.3V shield like:
https://www.amazon.com/dp/B00XMERZA4/
i have ordered the shield, but have not received it to test yet. it uses a MAX3485 chip and is 3.3V compat.
RS485 is like serial UART communication, but uses a differential RX/RX hardware for noise reduction. it requires a 120ohm terminating resistor at only the two ends of the string. this removes signal "ring".
this use of RS485 is Half-Duplex, and that means it uses the same two wires for TX and RX, in turns. first the master sends a request, with a payload. then it switches back to RX mode and receives the response.
i have included the data frame details in the .h file as a FYI.