Re: [PIC] 16F747 UART errors by Jan-Erik Soderholm .

On 2010-07-29 16:59, Drew Maurer wrote: {Quote hidden}> 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 interrupts > it resets the prescaler to 128 and returns which delivers the remaining 7 or > 8ms. The second time the interrupt is triggered it sets all the servo lines > high for 1ms followed by an additional 0 to 1ms. Note that there is no need to have all servos "in sync". It might often be easer to take care of one 1-2 ms puls at the time and at the end sum it up to (aprox) 20 ms before starting over again. It might be more "work" for the processor to keep track of a number of pulses active at the same time. And the servios doesn't care if one servo gets its pulse first, then the second servo and so on. That way, you can have a lookup-table with the timer values for all your "positions", say aprox 100 different values/positions (few applications needs more then 100 different servo positions). Then the sequence becomes (something like) : On each timer-interrupt : - stop pulse for servo pointed to by servo-flag. - All servos done ? If so: Reset servo-flag to first servo (minus 1?) Load timer with "rest-of-20ms". If not : Start pulse for next servo. Load timer with "postition" for next servo. Set servo-flag to "next-servo". RETFI And then setup/initialization at power on and so on of course. With this setup, you will not stay many cycles in the timer-interrup and it will probably not interfere with the USART routines/interrupts. As I read your description, I go the impression that you stay in the timer-interrupt the whole 1-2 mS period ? That is a looong time... :-) In this way I get 8bit {Quote hidden}> 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< > TakeThisOuTjan-erik.soderholmspamBeGonetelia.com> wrote: > >> On 2010-07-29 12:48, Oli Glaser wrote: >>> >>> >>> -------------------------------------------------- >>> From: "Jan-Erik Soderholm"<jan-erik.soderholm@spam@RemoveMEtelia.com> >>> Sent: Thursday, July 29, 2010 10:49 AM >>> To: "Microcontroller discussion list - Public."<@spam@piclistKILLspammit.edu> >>> 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 read >>>> 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 for >>> 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 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? >>> >>> 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? >>> >>> >>> >> -