Comment #2 on issue 169 by robhamerling: Flipping a pin with the 18F PICs
http://code.google.com/p/jallib/issues/detail?id=169
Hi gentlemen,
I appreciate your comments, but would like to keep these together in the
issue-section of GoogleCode. So please do not 'reply' to the messages which
are send by GogleCode to Jallib, but rather add your comments online in
issue 169 of GoogleCode.
Here a copy of your contributions so far:
Kiste:
It might be necessary to modify the device files is such a
way that for the read of a port or pin the TRIS register
must be consulted: when configured for input read the PORT
register, when configured for output read the LAT register.
Hummm... This is not an easy subject. A pin can change its function and be
both input and output while running a program. So this decision would have
to be made at runtime. That would cost some code space, and, what concernes
me more, execution time. I wouldn't want such basic tasks like reading a
pin take more time than neccessary.
The read-modify-write-problems are extensively described in the PIC
datasheets, as well as the fact that a loaded pin may read not back the
value it is driving.
My opinion would be, that the program using
led=!led
is simply faulty. If one is programming a microcontroller, he should have
at least some knowledge about electronics. If he doesn't want to care about
hardware, programming a computer would be the choice.
------------------
Matt:
My opinion would be, that the program using
led=!led
is simply faulty. If one is programming a microcontroller, he should have
at least some knowledge about electronics. If he doesn't want to care
about hardware, programming a computer would be the choice.
I disagree, this is not a faulty program. Flipping a led should be
allowed just like any other variable. If it is left as it is, some
libraries will not work.
----------------------------
Joep:
This is an interesting issue.
IIRC the (some?) 16F chips suffer from the RMW issue. This means that
although an output pin is set to low, it might read back high due to load
or capacity. If you change an other pin on the same port, the operation to
set that particular bit might flip bits of other pins.
However, inverting the pin means RMW at 'user level' and I'd say this is
always prone to the RMW issue, since you tell to read the pin, invert the
value and write it again.
Microchip fixed the RMW issue (due to bit-operations) with the LAT register.
I don't understand what's happening here. A led is no heavy load and 250ms
handles the capacity. So why is the value of the pin not equal to its
driven value?
PS Actually, this happend to me quite a few times. It always turned out the
pin was set as analog, so reading its digital level was not supported.
PPS I would not be in favor of additional overhead to check pin direction
and select source on that. We're not trying to exceed the Arduino library
overhead, are we? ;)
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en.
