Scott Newell wrote: > I'm trying to get the usart on the 16c74 to talk to a pc, but I > can't even seem to get a stable signal out. I'm seeing some *very* > strange things happening on the TX pin out of the pic, so I thought > someone on the list might be able to help out. > > First, a few details about what I've got running. > > [.... very well-described details snipped.... ] > > What I observe is that the tx LED blinks rapidly, and over the > course of about 3 seconds, seems to ramp dimmer then snap back up to > full brightness. The LED blinking once per second also seems to lose > brightness in about a 3 second ramp. No evidence of this ramp on > the supply rails, V+ is rock solid, as is MCLR. > > Now for the strange part. When transmitting a constant stream of > '00000000', I can see the waveform fine for about the first 2 > seconds or so of the 'ramp-down', then it looks like the last bits > (the msbs) are changing from 0's to 1's. (Imagine going '00000000' > -> '00000011' -> '00001111' '00111111' as seen on the scope.) This > 'sweep' coincides with the minimum brightness of the LEDs. Then, as > soon as all the bits seem to go high, the whole damn cycle starts > over again. > > [.... more good information snipped.... ] > > Timer 0 interrupt? Could it conflict with the usart? > > Any ideas from picland? Please? Steve: Sounds like two asynchronous signals beating against each other (although the LED dimming, especially on the once-per-second LED, mystifies me). Since the only two asynchronous processes you're running are the Timer-0 interrupt and the TX interrupt, try lengthening your 1/30-second tick timer by a factor of 10 or 100 and see if anything changes. My guess is that your TMR0 interrupt-service routine is somehow stomping on the TX registers or the TX interrupt flags. Is there any chance that your code could be clearing the TXEN bit during a transmission? -Andy Andrew Warren - fastfwd@ix.netcom.com Fast Forward Engineering, Vista, California http://www.geocities.com/SiliconValley/2499