dammit, hit the wrong key and sent in the middle of editing my thoughts on this are still muddled, but I added a couple of things...
On Thu, Jul 21, 2016, at 05:57 PM, John Kasunich wrote: > I started to write a "quick" reply, but the deeper I look > the more complex it gets - and I have to be somewhere. > I'm going to post this partial reply now and hope to get > back to it later... > > On Thu, Jul 21, 2016, at 11:00 AM, Jeff Epler wrote: > > snippage > > > > Note that HAL threads are not started, so the function that updates PO has > > never had a chance to run and drive PO's value. > > This is a key point. > > The "default" values mentioned in that commit message > were never intended to be defaults. The struct member > name is "dummy", not "default". I only now realized that .comp files can specify a STARTVALUE. That probably explains how "dummy" has been (mis-)interpreted as a default... > > HAL pins are nothing more than C pointers. Once connected, > they point to the value, which is part of the signal struct. > Since HAL was intended to be simple, clean, and fast, I didn't > want to force every pin reference to do NULL pointer checks > to handle unconnected pins. So an unconnected pin still needs > to point somewhere. The "dummy" field is that somewhere. > HAL pin pointers must never be NULL. > > When HAL component code reads a pin, it reads from the > pointer. If the pin is connected to a signal, the component > reads the signal value. If the pin is unconnected, it reads > the dummy value. > > When a HAL component code writes a pin, it writes to the > pointer. If the pin is connected to a signal, the write goes > to the signal value. If the pin is unconnected, the write > goes to the dummy value. > > The component code neither knows nor cares if the pin is > connected. > > Sorry if the above is already common knowledge, but knowing > the implementation makes the behavior easy to understand: > > "sets" ALWAYS modifies the value of the signal. If the signal > has no writers, the "sets" value will persist. If there is a > writer the value will be over-written by that writer sooner > or later. > > "setp" modifies the target of the pin pointer. If the pin is > connected, it modifies the value of the signal, just like a > "sets". If the pin is unconnected, it modifies the dummy > value. > > > Here's the thought experiment I've been using for myself, and mentioned on > > IRC: > > > > # (newsig rather than creating via net command, to show that a signal > > # can also have an explicit initial value) > > newsig S signed > > sets S 1 > > # Note: assume pin PI is direction IN and power-on value 2 > > net S <= PI > > # Note: assume pin PO is direction OUT and power-on value 3 > > net S <= PO > > # Note: assume pin PJ is direction IN and power-on value 4 > > net S <= PJ > > > > show sig S > > > > We need to think about input and output pins separately (bidir pins > too, but they are a mix of both and come later) > > For all types of pins, I like to think of components as if they were some > kind of hardware. Many people have experience with hardware components, > and the "principle of least astonishment" applies. HAL components should > behave like regular hardware would, when possible. > > For INPUT pins: think about the inputs of say a stereo amplifier. > Typically the input impedance is very high - the input doesn't drive > anything, it is driven by other things. However, there is usually a > weak pull-down to ground so an unconnected input doesn't go > floating off. > > For an unconnected input, ideally the value would be STARTVALUE. > This is where I ran out of time. The problem: Sometimes you want an unconnected input to behave like the stereo with a pull-down to ground - unlink it and it goes back to STARTVALUE. Other times you want an unconnected input to have memory - unlink it and the pin retains its current value (what the commit does on unlink). Certainly if you "setp" an unconnected input you want it to retain that setp value - that is how we tune PID loops for example. -- John Kasunich [email protected] ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
