Searching \ for '[PIC] 16F747 UART errors' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: '16F747 UART errors'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 16F747 UART errors'
2010\07\28@162236 by Drew Maurer

picon face
Hello,

I have a 16F747 and am attempting to communicate with my PC via a MAX233
translator - pretty standard stuff.  However the PIC-to-PC direction is very
unstable, dropping 1 out of 4 bytes seemingly at random.

I'm using the HS oscillator with a 20MHz xtal.  My link troubleshooting
program replies to a 4-byte string with a 5-byte string and does absolutely
nothing else.  I've tried adding delays between bytes but still random bytes
are *always* lost.  Lengthening the string worsens the problem which makes
me think this may be a timing problem, however I *am* using a crystal and
haven't noticed the oscillator being "off" when measuring various periods
from other test programs on this device.  The PC-to-PIC direction is
rock-solid.

Slowing the baud rate to 2400 improves things vastly, with only ~1 byte out
of 50 lost.  But at 9600 (in either BRGH=0 or 1) the link is nigh on
unusable.

Here are the relevant sections of my code (there are no other "interesting"
functions - no interrupts, timers, etc in use):

;*** Enable USART
BSF STATUS, RP0 ; Go to Bank1
MOVLW D'129' ; Set Baud rate 9600
MOVWF SPBRG
MOVLW b'00100100' ; 8-bit transmit, transmitter enabled,
MOVWF TXSTA ; asynchronous mode, high speed mode
BCF STATUS, RP0 ; Go to Bank 0
MOVLW b'10010000' ; 8-bit receive, receiver enabled,
MOVWF RCSTA ; serial port enabled

;*** Send character
send         call         errchk
          movwf TXREG           ; send data in W
TransWt    bsf         STATUS, RP0 ; RAM PAGE 1
WtHere     btfss TXSTA, TRMT ; (1) transmission is complete if hi
               goto         WtHere
               bcf         STATUS, RP0 ; RAM PAGE 0
return

;*** Error check
errchk btfss RCSTA, OERR
  goto errdone
  bcf RCSTA, CREN ; reset USART RX logic, clear RCSTA,OERR
  bcf RCSTA, FERR ; reset framing error bit
  bsf RCSTA, CREN ; re-enable continuous reception
errdone return

;*** Send string
               movlw '#'
call send
movfw UnitID
call send
movlw '3'
call send
               movfw       Thtl1
               call   send
               movlw       '@'
               call   send


Thanks in advance,
Andre

2010\07\28@163745 by Olin Lathrop

face picon face
Drew Maurer wrote:
> I have a 16F747 and am attempting to communicate with my PC via a
> MAX233 translator - pretty standard stuff.  However the PIC-to-PC
> direction is very unstable, dropping 1 out of 4 bytes seemingly at
> random.
>
> I'm using the HS oscillator with a 20MHz xtal.  My link
> troubleshooting program replies to a 4-byte string with a 5-byte
> string and does absolutely nothing else.  I've tried adding delays
> between bytes but still random bytes are *always* lost.  Lengthening
> the string worsens the problem which makes me think this may be a
> timing problem, however I *am* using a crystal and haven't noticed
> the oscillator being "off" when measuring various periods from other
> test programs on this device.  The PC-to-PIC direction is rock-solid.
>
> Slowing the baud rate to 2400 improves things vastly, with only ~1
> byte out of 50 lost.  But at 9600 (in either BRGH=0 or 1) the link is
> nigh on unusable.

This smells like a problem with the MAX232, probably somewhere in the charge
pumps.  That would explain why the PC to PIC direction works fine since it
doesn't rely on the charge pumps.  Look at the charge pump outputs.  They
should be around -8V and +8V.  The RS-232 output should also switch between
those levels, with -8V being the idle level.  That's probably not what is
happening in your setup.

Here's a self-serving suggestion:  Next time just use one of these
http://www.embedinc.com/products/rslink2


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\07\28@164814 by Drew Maurer

picon face
On Wed, Jul 28, 2010 at 1:38 PM, Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamembedinc.com>wrote:

{Quote hidden}

>

2010\07\28@174015 by Bob Blick

face
flavicon
face

On Wed, 28 Jul 2010 13:48:14 -0700, "Drew Maurer" said:

>
> Thanks.  Actually I've already 'scoped the levels in all directions, they
> look fine.  In fact that MAX233 is new but the problem is not - I added
> the
> 233 because I thought the problem might be related to the crude level
> shifter made out of discretes (which borrowed -12V from the PC itself)
> that
> I was using, but the problem persists unchanged.

On the PC is it a real serial port or a USB adapter under Windows? I had
problems once where a byte here and there was being munged, and a
different driver fixed it. Prolific PL-2303 based USB-Serial adapter.

Cheers,

Bob

-- http://www.fastmail.fm - A fast, anti-spam email service.

2010\07\28@175409 by Drew Maurer

picon face
Bob,

Very interesting; yes its a Prolific USB adapter.  Driver version 2.0.2.8 -
do you happen to know which driver "fixed" your issue?  I did previously try
the device on a PC with a built-in serial port and the behavior was more
predictable but not perfect; I will check again.

Also, I'm playing in realtime, here is some more grist for the mill -
setting the SPBRG to '134' (9259 baud) helps quite a bit.  Hard to believe
my crystal would be that far out.

Andrew

On Wed, Jul 28, 2010 at 2:40 PM, Bob Blick <.....bobblickKILLspamspam@spam@ftml.net> wrote:

{Quote hidden}

>

2010\07\28@180623 by Bob Blick

face
flavicon
face

On Wed, 28 Jul 2010 14:54:09 -0700, "Drew Maurer" said:
> Bob,
>
> Very interesting; yes its a Prolific USB adapter.  Driver version 2.0.2.8
> -
> do you happen to know which driver "fixed" your issue?
I don't know what the bad driver was but my computer is using 2.0.0.18
right now.

> try
> the device on a PC with a built-in serial port and the behavior was more
> predictable but not perfect; I will check again.
>
> Also, I'm playing in realtime, here is some more grist for the mill -
> setting the SPBRG to '134' (9259 baud) helps quite a bit.  Hard to
> believe
> my crystal would be that far out.

Sounds like maybe a dwarf bit? There is no harm in setting the PC side
to two stop bits to see if by forcing that extra idle bit will change
things.

Almost makes the extra weight of a USB stack seem worth it :)

Cheerful regards,

Bob



-- http://www.fastmail.fm - Access all of your messages and folders
                         wherever you are

2010\07\28@213759 by RussellMc

face picon face
No chance of an out of spec voltage being applied to any PIC pin?
That's a potential risk with informal level shifters but shouldn't be
a problem with the driver IC.


2010\07\28@224316 by Drew Maurer

picon face
Nope, all voltages look fine.

I just bought a new USB-serial dongle...  same problem.  Maddening!!

Drew

On Wed, Jul 28, 2010 at 6:37 PM, RussellMc <apptechnzspamKILLspamgmail.com> wrote:

> No chance of an out of spec voltage being applied to any PIC pin?
> That's a potential risk with informal level shifters but shouldn't be
> a problem with the driver IC.
>
>
>               R
>

2010\07\29@001343 by Oli Glaser

flavicon
face


--------------------------------------------------
From: "Drew Maurer" <.....a.l.maurerKILLspamspam.....gmail.com>
Sent: Thursday, July 29, 2010 3:43 AM
To: "Microcontroller discussion list - Public." <EraseMEpiclistspam_OUTspamTakeThisOuTMIT.EDU>
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 port) Making sure it's not the PC side would help, may be an issue with your PCs 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 loop 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 still 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 different 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.

2010\07\29@020732 by Drew Maurer

picon face
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 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?

Drew

On Wed, Jul 28, 2010 at 9:13 PM, Oli Glaser <oli.glaserspamspam_OUTtalktalk.net> wrote:

{Quote hidden}

>

2010\07\29@055024 by Jan-Erik Soderholm

face picon face


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 hope
> 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 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 ?

  4800 baud means that my data strings collide with the interrupt
{Quote hidden}

>> -

2010\07\29@064900 by Oli Glaser

flavicon
face


--------------------------------------------------
From: "Jan-Erik Soderholm" <RemoveMEjan-erik.soderholmspamTakeThisOuTtelia.com>
Sent: Thursday, July 29, 2010 10:49 AM
To: "Microcontroller discussion list - Public." <piclistEraseMEspam.....mit.edu>
Subject: Re: [PIC] 16F747 UART errors

{Quote hidden}

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.


>   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?

2010\07\29@070532 by Jan-Erik Soderholm

face picon face
On 2010-07-29 12:48, Oli Glaser wrote:
{Quote hidden}

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.


{Quote hidden}

2010\07\29@071614 by Olin Lathrop
face picon face
Drew Maurer wrote:
> Very interesting; yes its a Prolific USB adapter.

You might have mentioned you were using a USB to RS-232 adapter in the first
place.

Try it directly without the adapter.  If this PC doesn't have a serial port,
try it on one that does.  This isn't meant to be a long term solution, but
will help diagnose what is going on.

A few years back Wouter sent me a USB to serial adapter to try out.  At
first it didn't work at all.  I dug around, found the latest driver,
installed that on Windows 2000, and it then basically worked as long as you
had RTS and CTS looped back (or something like that, it was a few years
ago).


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\07\29@071934 by Olin Lathrop

face picon face
Bob Blick wrote:
> Sounds like maybe a dwarf bit? There is no harm in setting the PC side
> to two stop bits to see if by forcing that extra idle bit will change
> things.

I thought he is having problems with the PIC to PC direction, in which case
the PIC should be set to 2 stop bits with the PC still at 1.  That may mess
up the PC to PIC direction, but it's a interesting test to see how it
effects the PIC to PC direction.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\07\29@072005 by sergio masci

flavicon
face


On Wed, 28 Jul 2010, Drew Maurer wrote:

{Quote hidden}

Doing the servo pulse timing as you describe is reasonable if you are controlling multiple servos. Consider using two PICs, one for the servo control and one for the comms. You could get the comms PIC to buffer data and present it to the servo controller as fast (high speed bursts "packet at a time" over SPI) or slow (byte at a time as requested) as you want.

Regards
Sergio Masc

2010\07\29@073402 by Olin Lathrop

face picon face
Drew Maurer wrote:
> Another, related, question - what happens to the USART when the TMR0
> interrupt fires?

Nothing special.  If there was some bizarre interaction, then this would be
described in the datasheet or the errata.

Think about it.  The UART and timer 0 are two independent hardware modules.
They would be expected to each do their thing independently unless something
was deliberately done to connect them somehow.  Since there is no such
connection, not even any reason to suspected such a connection, what you're
asking makes no sense.  It's like asking if your car will still run when the
bedroom window is closed.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\07\29@081753 by Olin Lathrop

face picon face
> 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.

I've got a side project (active control of a inherently unstable flying
wing) that drives 4 hobby servos directly from a 24HJ32GP302.  The dsPIC
class PWM modules have wide enough period counters that you can do 500us to
2.5ms every 20ms with sufficient resolution in fire and forget hardware.

With a PIC 18 or something I would look into multiplexing the output of a
single PWM module.  The important observation is that you can fit a number
of 1-2 ms pulses in the 20ms repetition period.  You do the pulse for each
channel successively.  The multiplexer can be as easy as a AND gate per
servo output.  Now the PWM hardware only needs a period a bit more than 2ms,
so you should have enough resolution for the varying pulse width.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\07\29@105928 by Drew Maurer

picon face
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.  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 <
RemoveMEjan-erik.soderholmspam_OUTspamKILLspamtelia.com> wrote:

{Quote hidden}

>

2010\07\29@111316 by Drew Maurer

picon face
I take it you've seen the videos on the web of the similar flying wing from
Stanford, maybe 10 years ago?  They had to build custom servos because the
rates required were so high; the thing looked like it was flapping its
ailerons for propulsion, they were so fast.  I digress...

Thanks, I check out the other classes of PICs. My bot is 24' stem-to-stern
so my plan was to keep cost and complexity low by running only DC power and
serial comm lines to the extremities of the boat, with several
generic/"general purpose" microcontroller modules living next to the
distributed pockets of sensors or actuators.  Ergo I chose the biggest, most
feature-packed PIC I could find for the generic modules, hoping that it'd be
adequate for the various applications.  Generally the 16F747 has enough
toys, though obviously this particular problem is a little tricky.  I have
no answer as to why I didn't look outside the 16F lineup; tradition I
suppose.

Drew


On Thu, Jul 29, 2010 at 5:18 AM, Olin Lathrop <RemoveMEolin_piclistKILLspamspamembedinc.com>wrote:

{Quote hidden}

>

2010\07\29@112141 by Olin Lathrop

face picon face
Drew Maurer wrote:
> Thanks, I check out the other classes of PICs. My bot is 24'
> stem-to-stern
> so my plan was to keep cost and complexity low by running only DC
> power and serial comm lines to the extremities of the boat, with
> several generic/"general purpose" microcontroller modules living next
> to the distributed pockets of sensors or actuators.  Ergo I chose the
> biggest, most feature-packed PIC I could find for the generic
> modules, hoping that it'd be adequate for the various applications.
> Generally the 16F747 has enough
> toys, though obviously this particular problem is a little tricky.  I
> have
> no answer as to why I didn't look outside the 16F lineup; tradition I
> suppose.

Yeah, that sounds like a natural for a full featured 24H or 33F with CAN
module.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000

2010\07\29@113814 by alan.b.pearce

face picon face
> 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.  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

OK, I have a feeling you could possibly select a better chip for the job
- seriously.

The chip you have is not a nanowatt part - from what I can make out from
the Microchip site, it won't let me look at the page for that chip
currently. There are PIC24 chips that are nanowatt, and I suspect you
probably want to be saving all the power you can in a pilotless drone.
This may or may not be a consideration, it is not clear to me if you are
attempting a solar powered drone or not.

As indicated above you are having problems with PWM resolution. PIC24
PWM channels have 16 bit resolution in place of the 5/6/7/8/10 bit that
that the 16F series do. And they have a heap of hardware channels that
will do it for you - as Olin said, set and forget. The largest chips do
have 5 hardware PWM channels and 4 UART channels. There is also a number
of SPI channels that could be used (with a bit of thought) as PWM
channels, with 16 stages of resolution, by transmitting a 16 bit word
with the appropriate bits set, at a timer interrupt determined interval.
Set the SPI clock to make the 16 bits 2.5mS long if that gives you
enough resolution, or stuff a number of 16 bit words into the SPI Tx
FIFO with a suitably faster clock to achieve better resolution.

You are already using a 40/44 pin part, so going to a large pin count
PIC24 won't be a hardship. Use the best tool for the job, instead of
make do and mend.
-- Scanned by iCritical.

2010\07\29@113937 by Jan-Erik Soderholm

face picon face


On 2010-07-29 16:59, Drew Maurer wrote:
> 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}

>> -

2010\07\29@124014 by Oli Glaser

flavicon
face


--------------------------------------------------
From: <EraseMEalan.b.pearcespamEraseMEstfc.ac.uk>
Sent: Thursday, July 29, 2010 4:38 PM
To: <@spam@piclist@spam@spamspam_OUTmit.edu>
Subject: RE: [PIC] 16F747 UART errors

{Quote hidden}

I agree with Olin and Alan here too. For something like this I would use an 18F minimum, but most likely something like a PIC24, dsPIC or maybe even a PIC32.
The price differences are negligible for a hefty increase in performance. I hardly use 16Fs for anything apart from the most basic stuff nowadays, when you can get an 18F for just about the same prices, and PIC24s and PIC32s for a couple of pounds more.

Few options here that maybe of interest:

dsPIC33F - 16-bit, 40MIPS, 4 PWM modules:
High-Speed PWM Module Features
Up to Four PWM Generators with Four to Eight Outputs
Dead Time for Rising and Falling Edges
Duty Cycle Resolution of 1.04 ns for Dead-Time, Phase Shift, and Frequency
Supported PWM modes: Standard Edge-Aligned, True Independent Output, Complementary, Center-Aligned, Push-Pull, Multi-Phase, Variable Phase, Fixed Off-Time, Current Reset, and Current-Limit
PWMxL, PWMxH Output Pin Swapping
PWM4H, PWM4L Pins Remappable
On-the-Fly PWM Frequency, Duty Cycle and Phase Shift Changes
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en537159

PIC24 - 16-bit, 16MIPS, nanowatt power, up to 5 PWM modules:
Peripherals      - CTMU supports Capacitive Touch applications      - Peripheral Pin Select allows I/O remapping of many peripherals in real      - 4xUART Modules with LIN and IrDA support, 4 Deep FIFO      - 3xSPI Modules with 8 Deep FIFO      - 3xI2CT Modules with Master and Slave       - Five 16-bit Timer Modules      - Up to 9 Input Capture and 5 Output Compare/PWM with dedicated time base      - Hardware RTCC, Real-Time Clock Calendar with Alarms      - PMP, Parallel Master Port, with 16 Address Lines, and 8/16-bit Data
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en531072

PIC32 - 32-bit, 80MHz, 1.56 DMIPS/MHz, 5 PWM modules:
Max Speed MHz         80
Program Memory Size (KB)         512
RAM (KB)         32
DMA Channels         4
SPITM         2
I2CTM Compatible         2
A/D channels         16
Max A/D Sample Rate         1000
Input Capture         5
Output Compare/Std. PWM         5
16-bit Digital Timers         5
Parallel Port         PMP16
Comparators         2
Internal Oscillator         8 MHz, 32 kHz
RTCC         Yes
I/O Pins         85
Pin Count         100
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en532441



2010\07\29@130120 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: spamBeGonepiclist-bouncesspamKILLspammit.edu [.....piclist-bouncesspam_OUTspammit.edu] On
Behalf
{Quote hidden}

Some years ago I wrote an example in C to explain this method to someone
else:

http://forum.htsoft.com/attachments/45512-servo.c

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2010\07\29@131240 by Dave Tweed

face
flavicon
face
Jan-Erik Soderholm wrote:
> 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.

Furthermore, depending on the sophistication of the servo's internal drive
electronics, the current pulse that the servo draws from the battery to
move the motor may be synchronous with the control pulse -- so staggering
the control pulses will also tend to even out the load on the battery.

Note that this is how standard (non-computerized) R/C transmitters and
receivers work. The pulses for the different channels are transmitted
sequentially, and the receiver simply demultiplexes them and applies them
to the servos with essentially the same timing.

-- Dave Twee

2010\07\30@061122 by gordond1980n/a

flavicon
face
Drew Maurer wrote:
> Very interesting; yes its a Prolific USB adapter.

I've used the FTDI cable with ease on my PIC projects with no problems. The  TTL level output makes life very much easier, and the 5V power rail very  useful for bus powered devices.

http://www.ftdichip.com/Products/EvaluationKits/TTL-232R-3V3.htm

Regards
Gordo

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...