Hi Dymoben and other
No other signals nearby, it is generated by the PIC itself, clean negative going
pulses aproximatly 25 uSecondes long or 40khz
Walter
Hi Dymoben and other
No other signals nearby, it is generated by the PIC itself, clean negative going
pulses aproximatly 25 uSecondes long or 40khz
Walter
Start tearing the code apart, there has got be de something doing it. In short you shouldn't have a pulse on an RX pin. Very odd.
RFsolution, The problem is in the "DEFINE HSER_CLOERR 1 ' automatic clear overrun error " statement. PBP clears the error by disabling the port and re-enabling it the same way as using the statement: RCSTA.4 = 0 and then RCSTA.4 = 1. this command set disables the receiver and then re-enables it to clear an overflow error. It's in the data sheet for the processor you are using. To prevent seeing this pulse you should set the output pin's state to normally high before using it as an input for the usart mode.
Dave Purola,
N8NTA
Thanks,
I will give it a try
I'm sure that those pulse are in conflict with the received data comming
from the max232
So if understand each time i use HSERIN i should make the pin high before
or just Tris portc.7 at startup ?
Finally !!!
I found probably a solution.
A faulty max 232 was generating those pulse on the RXport
and disturbing the RXdata
Thanks to all untill now for all replys hints etc...
Cool, I figured something odd was going on. Usually its the simple stuff.![]()
Bookmarks