On 2010-07-29 08:07, Drew Maurer wrote: > 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 ho= pe > that works better. That is not my view of the RS232/USB dongles. For standart serial communication, they work usualy just OK (at any speed). > > Another, related, question - what happens to the USART when the TMR0 > interrupt fires? Nothing. The USART (if you are talking about a hardware USART, not something built in firmware) does it's job independant of any interrupts. If you are not messing with the USART registers in the interrupt. > 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 PW= M > input; when the 20ms is up, the interrupt holds control for the 1-2ms ser= vo > pulse. That might not be a good solution. Just set some timer and return from the interrupt as soon as possible. Are you also using interrupts to read the incomming USART data ? 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 h= ave > to repeat the request 5 or 10 times which is really going to flood the da= ta > bus on my boat. Can I ignore these interrupts in my data? Am I guarante= ed > that the data is still good, just delayed? > > Drew > > On Wed, Jul 28, 2010 at 9:13 PM, Oli Glaser wro= te: > >> >> >> -------------------------------------------------- >> 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 po= rt) >> Making sure it's not the PC side would help, may be an issue with your P= Cs >> 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 l= oop >> 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 th= e >> 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 st= ill >> 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 differe= nt >> PIC sorted the problem (the PICs clock appeared to be playing up for som= e >> reason, causing timing problems) I know this kind of thing is a very rar= e >> 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 .