On Thu, Jul 28, 2016, at 12:12 PM, Nicklas Karlsson wrote: > Ken Lerman wrote: > > It might be worth reconsidering how unconnected pins are handled. Letting > > something read or write to dummy can cause nasty bugs. That's particularly > > true for writing to dummy. > > Reading a unconnected pin should result at least in a warning.
Something is being lost in translation here. Reading and writing unconnected pins happens ALL THE TIME! And there is absolutely nothing wrong with it. Example: PID tuning parameters are pins. 99.9% of they time they are NOT connected to anything. A series of "setp" commands in the HAL file sets the unconnected pins to the proper values. Then the PID comp spends the remainder of its life reading those values from the unconnected pins. Works fine, and anything else would be a major pain in the ass. Example: The SIGGEN component has sine, triangle, and square wave outputs. The component writes to all three of them and neither knows nor cares whether a signal is connected. You can point halscope at either an unconnected pin or a signal connected to a pin, works fine. > I guess this could be checked beforehand as soon as linuxcnc is started. What exactly do you mean by "started"? One of the strengths of HAL is that it can be interactive. You can make and break HAL connections while the system is running. In fact, the two-year-old commit that started this whole discussion only makes sense in that context. If you make all your connections before you start the real-time code, that commit would have no effect. > > Checking for a null pointer is pretty fast with today's machines -- even > > with the ARM and other little processors. Yuck. I have two objections. The first is cosmetic. Today, reading or writing a pin is simple: read: localvar = *pin; write: *pin = localvar; You can even do something like *pin += localvar; or *pin1 = *pin2 + *pin3; To do null pointer checking, you'd have to invoke a macro or function for every pin access. But that is only an inconvenience. The second objection is: what should the macro/function do when it detects that the pin is disconnected? This is real-time code. You can't stop and throw an error message. Code in real-time threads MUST ALWAYS run to completion quickly and consistently. Code in real-time threads must ALWAYS produce results that are sane. Consider a component like "sum". The code must ALWAYS write a legal floating point number to the output pin, regardless of whether the input pins are connected or not. And as mentioned above, the "sum" component must continue to produce sane and timely results even if you disconnect and reconnect it on the fly. > Yes checking is fast but the best is to allow only valid assignment > because it make software simpler and avoid the problem did not > remember to check everywhere. Only a few languages however > have good type checking. HAL does have type checking. You cannot connect a float signal to an s32 pin. But that checking is done when you issue the "linksp" command (or "net", which invokes linksp behind the scenes). It is not a realtime thing, and halcmd can refuse to make the link and return an error message. The real-time code doesn't know (or care) whether the pin is connected to anything. And the code for making and breaking links was specifically designed so that those operations are atomic and real-time safe. > > I wrote a similar system back in the early 70's (the processor was an Intel > > 8080). The model didn't differentiate between signals and parameters. > > Everything was implemented as a (logical) value in a named register. The > > last writer of the value won. There were four thread priorities that ran > > asynchronously. That could lead to some "interesting" bugs. HAL's linksp command allows only one "writer" pin to be connected to a signal, along with any number of "reader" pins. There is also a "bidirectional" pin type, but it is used only for a very limited number of pins. The one that comes to mind is encoder index-enable, where it is used as a handshake. One component sets the index-enable true telling the encoder driver to start looking for an index. When the driver detects the index, it sets the signal false to indicate that the index was detected. > > That's why global variables or other form av similar global storage > should not be used. There is a time and place for everything, including global storage. -- John Kasunich [email protected] ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
