Hi Sebastian,
last days I've tried your patch.
I think the output of "Pin::operator char" was inconsistent with
"Pin::operator=", so i swapped "A" and "a" there. Is this ok? Or should
the swap be done in "Pin::operator="? Or was the inconsistency
deliberate?
Yes, this is a bug. I (!!) would prefer to use "A" for normal analogue
behavour and "a" for shortcut. But one one hand, this is my opinion, :-)
and it's easy to change.
Is it ok to extend Pin? Or should the python interface use AdcAnalogPin
in some way?
AdcAnalogPin is originally created for usage with tcl interface. And, in
the moment, it's not included in python interface. This class is only
used for interfaces like tcl or python. The Pin class itself is used by
many internal functionality.
So it would not be bad to improve AdcAnalogPin for such cases and insert
it in python interface too. (it would replace the XPin python class in
your example). And there is a next problem. You SetAnalog method dosn't
respect the Net class functionality. (in my opinion! but I'll test it,
maybe in the same manner like the python io pin examples) But on the
other hand, handling of analog values in Pin class isn't really good
made, so a rework on that is outstanding. The solution with INT_MAX is
not intuitive, as you found out forself on writing your python example
code. :-) So, suggestions for this are welcome!
> Can I get commit rights or do you prefer to push it yourself?
If you plan to do more, then it could be a good idea to become a project
member. In this case I would create a topic branch for your changes on
adc stuff. Then you could upload your changes to this branch and other
have the possibility to review this in a easy way. Later, if this is
finished, we can integrate your work in master branch and delete this
topic branch. If you want this, I will create this topic branch for you,
insert your patch on it. (this is in fact now done in my local
repository, additional I've made some code cleanings too and just a
little bit cosmetics on your python code) So you'll have a base to start.
cu, Thomas
_______________________________________________
Simulavr-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/simulavr-devel
