Skip to content
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

interface between the modules #11

Open
gkasprow opened this issue May 26, 2018 · 5 comments
Open

interface between the modules #11

gkasprow opened this issue May 26, 2018 · 5 comments

Comments

@gkasprow
Copy link
Owner

gkasprow commented May 26, 2018

The more I think about the interface between modules, the less I'm convinced that LVCMOS signalling would do the job. Sooner or later somebody will try to hot-plug the modules and in this way will damage them because the connectors I use do not have any form of power sequencing.
RS485 transceivers are not expensive - cost of SNx5176B is 0.3$ at high quantity.
So the idea is to modify the device discovery procedure:

  • all modules are connected in parallel by RS485.
  • each module has single 3.3V input and output. Input is routed to reset signal, output is controlled via MODBUS register.
    By default, module is in reset state and the output is Hi-Z
    The procedure is simple:
  1. The host releases reset.
  2. The host talks to the first and the only device on the MODBUS. Its address is 0xFF. The host changes it to 0x01 and sets active output that releases reset of next device.
  3. the host talks again to the address 0xFF and changes its address to 0x02. It again sets active output that releases reset of next device.
  4. It repeates previous step increasing the assigned address until there is something that still responds to 0xFF address.
    The method proposed has several advantages:
  • the host can always reset whole chain. The reset will propagate through all devices.
  • we use fault-tollerant differential signalling
  • hot-plug won't break the CPU, the reset line can be protected by TVS
@jordens
Copy link

jordens commented Jun 1, 2018

The only disadvantage is that a single broken or crashing node will reset everything downstream. If you have pins, you could have that reset line open collector and the reset segment between two nodes be bidirectional. Then you could access the chain from both ends and be resistant to some types of failures.

@gkasprow
Copy link
Owner Author

gkasprow commented Jun 3, 2018

@jordens I have 4 free pins. All modules simply propagate them from left to right for future applications. So I can simply use them to feed any signal to the end of the chain and back by adding the end-cap module.
I can't imagine how open collector reset line can be controlled both by the host CPU and the device.
Do you mean adding another reset line which propagates the signal in opposite direction ?

@jordens
Copy link

jordens commented Jun 4, 2018

In your description is seemed that the only signal that breaks the left-right symmetry is the reset (it only goes from left (input) to right (output) and is intercepted at each node). I was wondering whether that was necessary.
Let's say you have the reset (active high) segment between two modules weakly pulled high by both. Then use the logical AND of both sides to reset the module and if it receives (let's say) an odd address, it will pull down the right reset line, with an even address it will pull down the left reset line. In both cases you get access to the next module and can start configuring it.

@gkasprow
Copy link
Owner Author

gkasprow commented Jun 4, 2018

That's good idea - you can start configuring devices from either side.
The controller can configure devices from one side so far it gets any response, and then try from other side to make sure all modules except for broken one are configured. The only problem is in the case when the first device keeps the left reset line low and the last module keeps the right reset line low so the controller cannot reset all the chain. This can be solved by introducing different pull levels.
The device can pull let's say with 1mA but the controller can overwrite it and force the high state.

@jordens
Copy link

jordens commented Jun 4, 2018

Yes it's only a way to debug at most a single failure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants