On Oct 11, 5:27*am, "Hendrik van Rooyen" <m...@microcorp.co.zawrote:
Quote:
This of course means that there has to be another
thread active to actually do the i/o on a periodic basis,
gathering the outputs and writing them out, and reading
the inputs and scattering them to the various named input
bits
|
Not necessarily. You've mentioned two ways.
Quote:
I would even not mind if I have to write:
>
if e_stop():
* * put_everything_off()
>
or:
>
set(push,1)
>
|
PS: Umm, a little bit off note: set is a built-in name, I'm a little
confused whether you meant on creating a "set" or setting the push bit
to 1, if the latter case it might be better to use set and clear
instead of passing a second parameter (and also to choose another
name).
Alternatively, there is one more way:
if bb.e_stop:
bb.e_stop = 0
where bb is some kind of "property bag" and .e_stop is a "property"
instead of an "instance member".
Quote:
Quote: Quote:
This approach has the advantage that you can
add a ninth "dirty" bit to indicate that the "byte"
in question needs to be written out.
| | > Quote: |
What do you mean by "written out" to where?
| >
See above explanation - see also a recent thread here
about "Python string immutability broken" where I posted the
prototype ctypes code, if you are really interested...
> Quote: Quote:
Is there not some OO way of hiding this
bit banging complexity?
| | > Quote:
foo & bar is complex? So you want to replace foo + bar
as well with something? ;)
| > Quote: Quote:
Using getters and setters? - I tend to go "tilt"
like a cheap slot machine when I read that stuff.
| | > Quote:
Getters setters? Where would that improve the situation
beside having to write lots of unneccessary code?
| >
Not necessarily unnecessary - the getters and setters could be
used to actually do the i/o to the relevant card when anything
makes an access to one of the bits on the memory representation
of that card - that would obviate the necessity for a second thread...
|
Rather than directly using getters and setters, I'd go with property.
It (usually) makes a cleaner external interface of the class. And for
the mess of having to write lots of boilerplate codes, you _could_
dynamically generate the boilerplate code from a dictionary (of name
to bit position) and currying (or something to that effect).
Alternatively, you could also do some magic with getattr and setattr.