On Thu, Oct 9, 2014, at 02:15 PM, John Prentice (FS) wrote: > John, thank you for your elaboration. > > Two points interleaved below: > > <snip> > > >To extend the wire-signal analogy, I think of I/O pins as tri-stateable > signals. > > I don't really get this analogy as there is also a memory hiding somewhere > for when everyone it tri-stated. It feels more like a wire with some sort of > latch with weak pull-up (and perhaps pull-downs?) on its output. I.e. it > remembers the state imposed on it by anything bussed onto it when the driver > turns on a strong 3-state buffer
The analogy is getting stretched almost to the breaking point, but: Consider a tri-state signal with no pull-up or pull-down resistor. All pins connected to it are truly infinite impedance when "off". All inputs likewise have infinite input impedance. The wire has some capacitance such that when not driven it retains its current value. > It was actually trying to do a manual test that got me into this trouble. I > think one needs a special comp with an IO pin to connect to the index-enable > to something like a pyVCP button. Why not just type "sets index-ena 1"? That command writes to the signal one time, which is exactly what you want. > Is the fundamental concept we want for REQ not an edge-input? The receiver > latches this and clears the latch when the action (e.g. count reset by the > index) is performed. The requester then has to see an ACK signal, deal with > the data, and eventually drop and re-raise the REQ. Yes and no. As normally used by LinuxCNC, an edge-sensitive request would probably work. It is actually a mix of edge and level - the level still matters so that the ACK line works correctly. It works like this: in idle state, REQ and ACK both 0 master sets REQ slave sees REQ change from 0 to 1 slave does whatever it does and makes data available slave sets ACK master sees ACK go from 0 to 1 master reads data master clears REQ slave sees REQ go from 1 to 0 slave clears ACK master sees ACK go from 1 to 0 back in idle state, ready to start again Note that the master cannot clear REQ until it sees ACK go true, since it has no way of knowing if the slave saw the edge. Remember that the master and the slave might be in different threads, either one might run hundreds of times before the other runs once. For the same reason, the slave can't clear ACK until it sees REQ go false, because until then it doesn't know if the master saw the ACK edge. The old way works like this: in idle state, REQ is 0 master sets REQ slave sees that REQ is 1 (prior state doesn't matter) slave does whatever it does and makes data available slave clears REQ master sees REQ go from 1 to 0 master reads data back in idle state, ready to start again Simpler, fewer steps, but still robust, even in the case of master and slave in different threads. > This wired OR would look neat in the HAL but unless faulting pins (e.g. > limit switches) are to be forced to use the mechanism we need an > understanding of what an IO pin connected to an input pin does (c.f. a > tristated output connected to a TTL input without pull-ups/pull-downs would > have an indeterminate value). If you consider the "signal has capacitance" model, then a signal driven by 10 tri-stated outputs and connected to any number of inputs will hold whatever value it has until one of those tri-stated outputs is enabled and drives it to a new level. The initial state of a brand new HAL signal is zero. If I was designing a machine, that would be the faulted state, and I would have a "reset" function (a button or whatever) that would write a 1 to the signal ONCE when the user presses the button. > The limit switch example seems to require > making the GPIO pins of Hostmot2 be IO in case they are to be wire-ORed. Nope. There is nothing special about GPIO pins. Any pin could be used in this way, by running it through the tri-state component. The pin signal would actually be used to drive the enable of the tri-state component. The input of the tri-state would be tied either high or low. When you hit the limit, the tri- state turns on and drives either a 1 or a 0 onto the output. Note: I believe there is also a floating point tri-state component, and it can be used to make an analog multiplexor in much the same way as the boolean tri-state can do an open-collector fault line. Just enable one of N tri-state components. > This seems much more complicated that a multiple input OR - which is perhaps > why it is not currently used. Perhaps. > Anyhow I think I must code a one-shot, whose output is an IO, to exercise > the encoder index-enable input. Nope. Just use "sets". Or if you must have a GUI thing, connect a VCP button to the enable input of a tri-state, and setp the input to 1. Regards, John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
