Yes, the PWM module cannot achieve the low duty cycles required while maintaining adequate resolution. If I recall correctly I think if I was willing to tolerate 10ms pulse spacing (instead of 20) then it would have functioned but with very low resolution and I was told the short pulse spacing may have upset some servos. (Don't quote me, I'm speaking from memory - but I'd wanted to use the PWM module and was forced to reject that idea) The way I do it now is to set the TMR0 prescaler to 256, which gets me something like 12 or 13ms until the interrupt. The first time it interrupt= s it resets the prescaler to 128 and returns which delivers the remaining 7 o= r 8ms. The second time the interrupt is triggered it sets all the servo line= s high for 1ms followed by an additional 0 to 1ms. In this way I get 8bit pulse width resolution but still have the processor yielded for communications about 90% of the time. I'm not saying this is the best way... but it was the only way I could come up with to combine control of multiple servos, good resolution, serial communication, 6 ADCs for measurements, and fast 20MHz clock for computation. Drew On Thu, Jul 29, 2010 at 4:04 AM, Jan-Erik Soderholm < jan-erik.soderholm@telia.com> wrote: > On 2010-07-29 12:48, Oli Glaser wrote: > > > > > > -------------------------------------------------- > > From: "Jan-Erik Soderholm" > > Sent: Thursday, July 29, 2010 10:49 AM > > To: "Microcontroller discussion list - Public." > > Subject: Re: [PIC] 16F747 UART errors > > > >>> 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. > >> > >> 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 re= ad > >> the incomming USART data ? > > > > Yes, I'm thinking there are probably better ways to do this. Unless I'm > > misunderstanding what is needed - what about using the PWM peripheral f= or > > the servo input? Then you can just load the registers and let it run > > independently. > > Usualy, the standard PWM module(s) are not particular good at generating > a standard 1.5 +/- 0.5 ms servo signal. And in many cases you have not > a single servo anyway. > > Exactly how the signals are to be generated depends on a number > of factors. One is how many steps (the "resolution") on needs > in the servo. > > > > > > > >> 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 > >>> have > >>> to repeat the request 5 or 10 times which is really going to flood th= e > >>> data > >>> bus on my boat. Can I ignore these interrupts in my data? Am I > >>> guaranteed > >>> that the data is still good, just delayed? > > > > Do you mean the USART data sending is interrupted somewhere by the TMR0 > > interrupt? > > Receiving or sending? What do you mean exactly by ignoring the > > interrupts/data being good? Can you give a bit more explanation? > > > > > > > -- > 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 .