On Thursday 27 October 2005 09:50 pm, Marek Wodzinski wrote: > On Wed, 26 Oct 2005, Paul Alfille wrote: > > On Wednesday 26 October 2005 04:37 pm, Marek Wodzinski wrote: > >> On Wed, 26 Oct 2005, Alfille, Paul H.,M.D. wrote: > >>> Ahhh... I'm sorta a software guy. 1=on 0=off > >>> Sorry for all the confusion. > >> > >> I'm a hardware based software guy:-) > >> > >>> The easiest way to bypass this is the add an "alias" -- another > >>> property that is the inverted state of the PIO pin. What should it be > >>> called? > >> > >> Maybe another idea: something like --dont-convert, --dont-negate or > >> --raw-rw to configure? > >> > >> And do not convert input/output with this option - just raw values like > >> in documentation of chips. > > > > Umm... unmanageable. We can't have incompatible behavior based on > > compilation settings, the confusion would be prodigious. > > > > A little more acceptable would be command line options -- though when you > > start negotiating between server and client settings, and owperl... it > > gets complex again. How about rPIO? It stands for "raw PIO" or "real PIO" > > or "reversed PIO"? The name reveals the syntax. Just looking at the man > > page brings the issue to light. > > Another idea for cleaning the mess: > - Just leave PIO as is and document this as something like 'not > recommended for use by hardware guys':-) > - Make latch.* writable in chips like DS2413 and add readable in > chips like DS2405 > - sensed.* is ok for reading real state of pin > - add write only toggle.* in chips like DS2405 (because you can not set > state of internal latch - just toggle). > - in DS2408 'latch' should be renamed to something like 'activity' for > consistency, because there are two latches: main (pio) and activity. And > of course add a real 'latch'. > > For more complete 'todo' list I must go across the sources and chip > documentation to see if there is something else. > I can help you with revision source vs. chip docs and maybe some simple > patches. > That would be great.
In general the policy should be: 1. Correct behavior (i.e. using the correct field to set the second pin, as in the bug you found). 2. Consistency across the devices for similar naming and behavior for similar properties 3. Not breaking existing code. There is almost no penalty for new properties, but saving state information outside of the device is discouraged. Paul > > regards > > majek ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
