On Wednesday 06 November 2013 09:06:44 EBo did opine: > On Nov 6 2013 6:25 AM, Gene Heskett wrote: > > On Wednesday 06 November 2013 08:20:21 Michael Haberler did opine: > >> Am 06.11.2013 um 10:59 schrieb andy pugh <[email protected]>: > >> > On 6 November 2013 06:27, Michael Haberler <[email protected]> > >> > >> wrote: > >> >> - on startup, rather than using the hal Python comp to connect > >> >> directly to HAL, collect all pin names, types and direction, and > >> >> pass this list to an HALrcomp API class instance; this would be > >> > >> the > >> > >> >> basis for the initial bind operation > >> > > >> > Rather than explicitly add new pins, would it be practical to > >> > >> change > >> > >> > the function of the "net" command to provisionally create/register > >> > >> any > >> > >> > pins that don't exist when it is called? > >> > >> hm, interesting idea; I need to think this through > >> > >> what once could do is say state in halcmd > >> > >> autocreate gladevcp.* > >> > >> which would cause net's to gladevcp.* not fail but rather put them > >> in a > >> dormant state, and have halserver gooble those up and create the > >> unbound component around them > >> > >> the key problem I see with this idea is: one cannot determine the > >> pin > >> direction just because the pin is named in a net statement; there > >> might > >> be several net commands to link more pins to the same signal and one > >> would have to look at the complete set > >> > >> even if you have the complete net - pins and the signal, it isnt a > >> valid > >> conclusion to draw that if all other pins except the gladevcp.* pin > >> are > >> input, then the gladevcp.* pin must be output - it might have been > >> intended as input, but the whole signal/pin net left unconnected to > >> a > >> writer for now > >> > >> both pro-forma declaration by 'newpin foo in float' and remote > >> creation > >> by the bind message handle this case unambiguously > >> > >> > The obvious problem with this is that simple typos in pin names > >> > >> will > >> > >> > not be picked up on the first pass, but then I suppose there is a > >> > similar problem with the newpin command. > >> > >> yes, if the remote component is created by the UI through the bind > >> commmand, typos would surface once the component is bound (after the > >> 'waitbound gladevcp' completes and halcmd continues) > >> > >> if you go the extra mile and declare the component pro-forma and > >> immediately start halserver and wait for bound, then the mismatch > >> would > >> appear as soon as the UI binds and the requested pinlist is > >> validated > >> against the existing pins > >> > >> > I don't know how you would test for whether a pin was "real" or > >> > "typo". It is perfectly reasonable to create pins and not connect > >> > >> to > >> > >> > them, most of the HAL components do that all the time. Nor is it > >> > unusual to create a net and signal and not have any "writer" in > >> > >> the > >> > >> > net. (Many of the sample configs do this) > >> > >> this is still possible in the current scenario, both with pro-forma > >> or > >> remote creation. Actually this would be information a UI could make > >> use > >> of; for instance, to grey out unconnected input pins. > >> > >> > >> -m > > > > I like where this is going. That is one of the places where > > rockhopper > > fails as it only draws a logic line if it has both a source and a > > load. > > I'd like a line stubbed out if I forget to hook it up. > > a dashed line to a "Undefined" pin?
Yeah, something like that, as in if the net has a name, use that but use a dashed line ending in a question mark if it has no destination, one could visually pick it out of a 6 letter sized printout a lot faster. I don't think you can define a netname with no source however since when a net name is defined, the next namestring in that line is assumed to be the source of the netname signal. This has in the past been a problem because while I re-used the netname, the re-use was above, not below the line intending to define the source. I've had odd gotchas that made me move whole blocks of lines around to satisfy that the first use of a netname did define the source. Thats just me learning the "ropes" of course. The end result was always a more readable .hal file so breaking that rule really is a PEBKAC. ;-) Unforch, its unavoidable that connected functions may be 100 lines apart when the file is pushing 300 active lines. > ------------------------------------------------------------------------ > ------ November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore techniques for threading, error checking, porting, and tuning. > Get the most from the latest Intel processors and coprocessors. See > abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.cl > ktrk _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) A tall, dark stranger will have more fun than you. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
