Thanks everyone. I don't know exactly which variable did the trick, but a new crystal, new PIC, and using a real serial port seems to have done the trick. I /had/ tried a real port previously and had similar trouble, but this time its working. The behavior of the USB-serial jobs is very odd. I get reasonable performance if I stay at 4800 baud or below, but roughly 10% of my data strings turn up incomplete. I'm going to try a PCMCIA serial port and hope that works better. Another, related, question - what happens to the USART when the TMR0 interrupt fires? Does it finish sending the byte normally? Reason being, this is a servo driver/current monitor for my lonelybot.com project - the TMR0 interrupt is used to generate the 20ms "off" time for the servo's PWM input; when the 20ms is up, the interrupt holds control for the 1-2ms servo pulse. 4800 baud means that my data strings collide with the interrupt frequently - my testing shows that, at 4800 baud almost 70% of my strings collide with the interrupt in this way, which is unacceptable because I hav= e to repeat the request 5 or 10 times which is really going to flood the data bus on my boat. Can I ignore these interrupts in my data? Am I guaranteed that the data is still good, just delayed? Drew On Wed, Jul 28, 2010 at 9:13 PM, Oli Glaser wrote= : > > > -------------------------------------------------- > From: "Drew Maurer" > Sent: Thursday, July 29, 2010 3:43 AM > To: "Microcontroller discussion list - Public." > Subject: Re: [PIC] 16F747 UART errors > > > Nope, all voltages look fine. > > > > I just bought a new USB-serial dongle... same problem. Maddening!! > > Have you tried it on another PC yet? (preferably with a proper serial por= t) > Making sure it's not the PC side would help, may be an issue with your PC= s > USB hub/drivers etc. > > When testing a bit banged serial a little while back on a 16F636 I used a > little test program to send a couple of characters in a tight loop so I > could examine the timing on a scope - maybe you could try this, send a lo= op > of a few characters and see if there is any evidence of timing problems > that > could cause bytes to be dropped. You can also just hold a key down on the > PC > and examine timings the other way for comparison. > Also, if you have a PicKit2 handy you could use the UART tool to connect = to > the PIC - this should be pretty much guaranteed to work so if you are sti= ll > getting problems you can be almost certain it's on the PIC side. > > Just in case if you have another PIC handy you could give that a go too -= I > was helping a chap some time ago with similar issues and using a differen= t > PIC sorted the problem (the PICs clock appeared to be playing up for some > reason, causing timing problems) I know this kind of thing is a very rare > occurrence but eliminating everything helps. > > I'm assuming power supply, pin voltages, clock speed etc have all been > tested, bypass caps are being used etc etc. > > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .