For one of our serial communcation programs, we included a feature for
self test of serial port. The application software at startup and
periodically checks the health of serial port. For this pupose we developed
a function for checking helath of serial port. The function enables internal
loopback of serial port, outputs a byte and after a delay of few millisec
reads the byte from port. For enabling the internal loopback of serial port,
we have set BIT 4 of Modem control register (MCR). After enabling internal
loopback, if read byte is same as written byte port is declared as healthy.
Once health check is complete, we reset BIT4 of MCR to disable internal
loopback.
We could observe that with this software feature at startup
health/presence of port could be detected. But after disabling internal
loopback, our serial communication (send/receive) did not work. It
(query-response) worked normally after restarting Dev32.ser and no health
check feature at startup of program. Should the application program
addressing bit4 of MCR directly (outp), disturb the functionality of
Dev.ser?
For one of our serial communcation programs, we included a feature for
self test of serial port. The application software at startup and
periodically checks the health of serial port. For this pupose we developed
a function for checking helath of serial port. The function enables internal
loopback of serial port, outputs a byte and after a delay of few millisec
reads the byte from port. For enabling the internal loopback of serial port,
we have set BIT 4 of Modem control register (MCR). After enabling internal
loopback, if read byte is same as written byte port is declared as healthy.
Once health check is complete, we reset BIT4 of MCR to disable internal
loopback.
We could observe that with this software feature at startup
health/presence of port could be detected. But after disabling internal
loopback, our serial communication (send/receive) did not work. It
(query-response) worked normally after restarting Dev32.ser and no health
check feature at startup of program. Should the application program
addressing bit4 of MCR directly (outp), disturb the functionality of
Dev.ser?
In general, hitting any hardware under the feet of a driver could
be expected to cause it heartburn. (That is, to cause it to stop
working.)
Some of the issues:
outp() can’t change just bit4 – it changes all the bits.
Did you read MCR, change bit4, then right back the current new value.
Then, to restore, do that again?
Do you not keep interrupts disabled that whole time? You really should,
so that nothing else happens while doing your test.
For one of our serial communcation programs, we included a feature
for self test of serial port. The application software at startup and
periodically checks the health of serial port. For this pupose we
developed a function for checking helath of serial port. The function
enables internal
loopback of serial port, outputs a byte and after a delay of few
millisec reads the byte from port. For enabling the internal loopback of
serial port,
we have set BIT 4 of Modem control register (MCR). After enabling
internal loopback, if read byte is same as written byte port is declared as
healthy.
Once health check is complete, we reset BIT4 of MCR to disable internal
loopback.
We could observe that with this software feature at startup
health/presence of port could be detected. But after disabling internal
loopback, our serial communication (send/receive) did not work. It
(query-response) worked normally after restarting Dev32.ser and no health
check feature at startup of program. Should the application program
addressing bit4 of MCR directly (outp), disturb the functionality of
Dev.ser?
In general, hitting any hardware under the feet of a driver could
be expected to cause it heartburn. (That is, to cause it to stop
working.)
Some of the issues:
outp() can’t change just bit4 – it changes all the bits.
Did you read MCR, change bit4, then right back the current new value.
YES
Then, to restore, do that again?
YES
Do you not keep interrupts disabled that whole time? You really should,
so that nothing else happens while doing your test.
NO, KINDLY TELL ME HOW I SHOULD DISABLE INTERRUPTS. BY ADDRESSING
PROGRAMMABLE INTERRUPT CONTROLLER OR WITH THE HELP OF ANY FUNCTION SUPPORTED
BY OS?
NO, KINDLY TELL ME HOW I SHOULD DISABLE INTERRUPTS. BY ADDRESSING
PROGRAMMABLE INTERRUPT CONTROLLER OR WITH THE HELP OF ANY FUNCTION
SUPPORTED
BY OS?
Ouch, why all the yelling?
Disabling interrupts has nothing to do with the PIC, it a setting on the CPU
proper to ignore the level on the INT pin. Check the documentation on
_disable() and _enable() on how to control the disable/enable of interrupts.
Also, simply reading the MSR has the side effect of clearing the MSR change
bits, so the driver would not see any of these change bits (assuming that it
looks for them).
NO, KINDLY TELL ME HOW I SHOULD DISABLE INTERRUPTS. BY ADDRESSING
PROGRAMMABLE INTERRUPT CONTROLLER OR WITH THE HELP OF ANY FUNCTION
SUPPORTED
BY OS?
Ouch, why all the yelling?
Disabling interrupts has nothing to do with the PIC, it a setting on the
CPU
proper to ignore the level on the INT pin. Check the documentation on
_disable() and _enable() on how to control the disable/enable of
interrupts.