Searching \ for 'PIC16C54 RC vs. XT' 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=16C
Search entire site for: 'PIC16C54 RC vs. XT'.

Truncated match.
PICList Thread
'PIC16C54 RC vs. XT'
1994\11\01@004242 by crocontroller discussion list

flavicon
face
I'm working on a design that is very cost sensitive and would like
to hear anyone's experience using a 16C54 with an R/C oscillator.

My application requires that some action be taken once every 16
hours, +/- 15 minutes and that I be able to generate a slow
pulse train that is low for 1 second out of every 10 seconds. The
pulse train portion of the application the actual times are not
as critical as the duty cycle.

The working environment of the devices is indoors so temperature
fluctuations can probably be ignored. Any opinions on whether the
RC oscillator version would work? The crystal option would add about
$1.00 to the overall system cost and is moderately significant unless
that's the only way it will work reliable.

Speed is not important. A 32KHz clock would be adequate for this
application.

Tim McDonough -- spam_OUTtimmedTakeThisOuTspamcencom.net

1994\11\01@104712 by crocontroller discussion list

flavicon
face
Tim, (and by extension, list members)

Is the RC version of the '54 really that much cheaper? When I last
did a low-cost product, '54s went for $1.72 in 11K quantity, and
using a 32.768 KHz watch crystal and a pair of caps ran about $.020.
The crystal was $.173 (and yes, in quantity 0.1 cents makes a
difference!). Can you save a dollar on the PIC cost, or are you
figuring on an inflated price for the crystal?

I presume that you don't have AC power available somewhere. If
you did, you could clock it from that. (Purists everywhere retch
in agony). The 60Hz line isn't reliable on a cycle-by-cycle
basis, but it's fine over the long term.

Can you tell us a little more about your application?

.....forbesmKILLspamspam@spam@csos.orst.edu
Mark G. Forbes
R & D Engineer
(who's designed several products with PICs in them)

1994\11\01@122855 by crocontroller discussion list

flavicon
face
> My application requires that some action be taken once every 16
> hours, +/- 15 minutes and that I be able to generate a slow
> pulse train that is low for 1 second out of every 10 seconds. The
> pulse train portion of the application the actual times are not
> as critical as the duty cycle.
Use a standard 32.768kHz crystal.  They are extreamly cheap.  It is what
almost every clock and watch uses.  We bought 100 of them for around $.75
apiece.  On top of that they work with lp PICs.  Which are also cheaper.
> Speed is not important. A 32KHz clock would be adequate for this
> application.
As I said.
later
       John
-----------------------------------------------------------------------------
John Johnson  Team OS/2 member | johnsonjspamKILLspambga.com | .....johnsonjKILLspamspam.....utdallas.edu
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done."  Around him lay Bill Gates and Microsoft apps.  Their
evil in this world at an end.
                                       Revelations of InfoWorld, Oct 11 1994

1994\11\01@124803 by crocontroller discussion list

flavicon
face
Tim,
Concerning your RC for PIC's, here is a response I made last Aug. that should an
swer
your questions.  I use these ceramics all the time and have had no problems.
Ask for the kind that have build in caps and resistors, no other parts are neede
d.

Steve


Concerning Autobaud, I started down the path of using RC PIC's for low cost.  Cr
ystals
and ceramic resonators were over $1.00 where RC circuits were $.10-.15.  Then I
found
ceramic resonators from FAI at $.26 each.  Its hard not to take the .3%  frequen
cy
stability over an RC for $.15.  Also very good prices on PIC's.  Call Chris or N
ancy
at
1-800-303-5701 or 303-237-1400.  This is not a recommendation for FAI, just a co
st
effective place to buy some items.
PS  Anyone had experiance with PIC running stright off 115VAC power, no xformer?



----------{Original Message removed}

1994\11\01@204403 by crocontroller discussion list

flavicon
face
I've used the RC oscillator and as long as you don't need accurate clock
frequencies, it works fine.  Your application sounds almost too primitive
for a PIC, but then again, you can't beat the PICs for flexibility.  And
they are cheap!

David
--
fghit entyrop

1994\11\01@230225 by crocontroller discussion list

flavicon
face
The quantities on this particular device will only be about 500-1000
per year by my estimate. My pricing for comparison and budgetary
purposes is to basically use Digi-Key prices for all components but
the microcontroller. The PIC16C54 RC version was quoted by Future
as $3.57ea in 100 quantities. The XT version was about 0.20 more.

There's some method to my madness in using Digi-Key's prices; I know
they are not necessarily the cheapest when you work with larger
quantities but I've found in the past that by using their prices as
a starting place and buying elsewhere changes and/or small additions
tend to be "covered" without having to go back to the customer with
price increases.

The difference in cost between an RC PIC with timing components and
an XT part with crystal and caps won't kill the product but every
little bit helps.

I have another 16C54 question as well. Since the '54 doesn't have
an interrupt for the RTCC what's the usual procedure for running
a given section of code periodically, say every 100mS or so? Can
you run a tight loop waiting for the RTCC to roll over from some
calculated value or will this methos "miss" the rollover if you simply
test for it to be equal to zero?

Please pardon the novice type questions--I spend most o{ my time
with 8051 family systems and am fairly new to the PIC!

Tim McDonough{-- EraseMEtimmedspam_OUTspamTakeThisOuTcencom.net

1994\11\02@081932 by crocontroller discussion list

flavicon
face
> I have another 16C54 question as well. Since the '54 doesn't have
> an interrupt for the RTCC what's the usual procedure for running
> a given section of code periodically, say every 100mS or so? Can
> you run a tight loop waiting for the RTCC to roll over from some
> calculated value or will this methos "miss" the rollover if you simply
> test for it to be equal to zero?

I am going to have to deal with this soon too.
My plan is to assign the prescaler to the RTCC and spin waiting for it to
equal zero.  With the prescaler, the count will be zero for several
(possibly many) instruction cycles, so I shouldn't miss it.  I just need to
have some logic to keep from detecting the same zero multiple times.

Does anyone know of a better way to do this or have I hit it on the head?

1994\11\02@081932 by crocontroller discussion list

flavicon
face
> I have another 16C54 question as well. Since the '54 doesn't have
> an interrupt for the RTCC what's the usual procedure for running
> a given section of code periodically, say every 100mS or so? Can
> you run a tight loop waiting for the RTCC to roll over from some
> calculated value or will this methos "miss" the rollover if you simply
> test for it to be equal to zero?

I am going to have to deal with this soon too.
My plan is to assign the prescaler to the RTCC and spin waiting for it to
equal zero.  With the prescaler, the count will be zero for several
(possibly many) instruction cycles, so I shouldn't miss it.  I just need to
have some logic to keep from detecting the same zero multiple times.

Does anyone know of a better way to do this or have I hit it on the head?

1994\11\02@100957 by crocontroller discussion list

flavicon
face
> I am going to have to deal with this soon too.
> My plan is to assign the prescaler to the RTCC and spin waiting for it to
> equal zero.  With the prescaler, the count will be zero for several
> (possibly many) instruction cycles, so I shouldn't miss it.  I just need to
> have some logic to keep from detecting the same zero multiple times.
>
> Does anyone know of a better way to do this or have I hit it on the head?

In a project I'm working on at the moment, I don't need to know exactly
when the timer runs out (indeed, I might miss it having the value zero)
but I do want to act on every cycle it goes through, so that I don't lose
long-term accuracy.

For this, I can poll the most significant bit of the RTCC until I've seen
a one followed by a zero. I only have to poll, at worst, once per 128
increments to get the indication I need, which is much easier than polling
at least once every increment.

-adrian

1994\11\02@113252 by crocontroller discussion list

flavicon
face
  "My plan is to assign the prescaler to the RTCC and spin waiting for
   it to equal zero."

That works; my usual technique is to set the RTCC to a negative number
and bit-test the MSB.  Remember to account for the delay between
initializing the RTCC and when it begins to increment.

                               Paul Milazzo <milazzospamspam_OUTbbn.com>
                               BBN Systems and Technologies
                               Cambridge, MA

1994\11\02@113707 by crocontroller discussion list

flavicon
face
>> I have another 16C54 question as well. Since the '54 doesn't have
>> an interrupt for the RTCC what's the usual procedure for running
>> a given section of code periodically, say every 100mS or so?

>Does anyone know of a better way to do this or have I hit it on the head?

How about using the WDT?  Then, you can put the PIC to sleep and save
batteries.  You just have to test a status bit to see if you're waking up or
being reset...  Then the entry point of your program becomes the entry of
the main loop.

Or are you already using the WDT?

- JohnR

--
John R. Haggis            @spam@haggisKILLspamspamnetcom.com
Millennium Research
(408) 269-1814 vox
(408) 269-9323 fax

1994\11\02@152409 by crocontroller discussion list

flavicon
face
>
> >> I have another 16C54 question as well. Since the '54 doesn't have
> >> an interrupt for the RTCC what's the usual procedure for running
> >> a given section of code periodically, say every 100mS or so?
>
> >Does anyone know of a better way to do this or have I hit it on the head?
>
> How about using the WDT?  Then, you can put the PIC to sleep and save
> batteries.  You just have to test a status bit to see if you're waking up or
> being reset...  Then the entry point of your program becomes the entry of
> the main loop.
>
> Or are you already using the WDT?

No, I'm not using the WDT.  In my particular application, not much (if
anything) would be gained by sleeping on the WDT, since I'm just sitting there
generating waveforms and running a motor speed control loop.  I can save more
power by running at a slower clock speed.  Either way, the power consumption of
the PIC is miniscule compared to the motor and the LEDs.  Because of those
devices, this must be a line powered device.

1994\11\02@162127 by crocontroller discussion list

flavicon
face
Tim McDonough <KILLspamtimmedKILLspamspamcencom.net> asks:
> I have another 16C54 question as well. Since the '54 doesn't have
> an interrupt for the RTCC what's the usual procedure for running
> a given section of code periodically, say every 100mS or so? Can
> you run a tight loop waiting for the RTCC to roll over from some
> calculated value or will this methos "miss" the rollover if you simply
> test for it to be equal to zero?

If you run the RTCC without the prescaler, you have to be tricky to sync up to
it.  It takes four instruction cycles (= 4 RTCC counts) to test the RTCC and
loop, so what you do is read the RTCC, mask the low two bits, and use them for
a computed delay to get in phase.  Then you can test for zero and loop.

The following code is a simplified excerpt from my PONG game.  I haven't
tested it after the simplification, but it might not work exactly as shown.
The comments show the RTCC value as instructions are executed for four
different entry conditions.  As you can see, by the time the label tw1 is
reached, the low two bits of the RTCC are always 00.

       movf    rtcc,w          ; f0 f1 f2 f3
       andlw   03h             ; f1 f2 f3 f4
       addwf   pcl             ; f2 f3 f4 f5
       nop                     ; f4
       nop                     ; f5 f5
       nop                     ; f6 f6 f6
       nop                     ; f7 f7 f7 f7
tw1:    movf    rtcc,w          ; f8 f8 f8 f8
       btfss   status,zf
       goto    tw1

This obviously works especially well if you want to sync up the RTCC every
256 instruction cycles.  If you need some other number, the simplest thing to
do is to add a constant to the RTCC after syncing up.  If you do so you have
to consider that the RTCC doesn't increment for two (if memory serves) cycles
after it is written, so add ((256 - desired_count) - 2).

Cheers,
Eric

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