Searching \ for '[PIC:] Generating a squarewave at a specific frequ' 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=pic
Search entire site for: 'Generating a squarewave at a specific frequ'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Generating a squarewave at a specific frequ'
2004\08\02@225952 by Jason S

flavicon
face
I'm working on the LED stroboscope I talked about a few days ago and I'm having trouble calculating the squarewave output.

If I have an 8-bit register with the frequency in Hertz, and the LED has to be on for a fixed 20uS, how do I calculate the off-time in the PIC?  For example, if the frequency is 125Hz, the total period is 8mS.  With the on-time of 20uS, the off-time must be 7980uS.  I can't see a reasonable way to do this calculation in the PIC.  To further complicate things, I'll probably want to go up to 1kHz, so I'll need to store the frequency in 10 bits.

Will a high level language like JAL be fast and precise enough for this project?

Jason

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\03@001735 by Jinx

face picon face
So, is the LED always on for 20us and the frequency is variable ?

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

2004\08\03@002517 by Jason S

flavicon
face
Yes, the LED will always be on for 20us.

I may need to tweak the on time once I get farther along in the design, but
I expect the on time will always be fixed once I decide what it's fixed to.

Jason

{Original Message removed}

2004\08\03@024021 by Jinx

face picon face
> Yes, the LED will always be on for 20us.
>
> I may need to tweak the on time once I get farther along in
> the design, but I expect the on time will always be fixed once
> I decide what it's fixed to

- by what method is the frequency changed ?

- does the frequency need to smoothly and/or quickly track what
is changing it ?

- what granularity/resolution is needed ? Maximum with a PIC
would be 100ns. For example, 10,000 instruction cycles = 1kHz,
10,001 IC = 999.9 -> 0.1Hz resolution to at least 1kHz and 0.01Hz
at 100Hz

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2004\08\03@040734 by Jason S
flavicon
face
I don't think a granularity of 100ns will be needed.  I was planning on
having a 1Hz resolution from 1 to 999 Hz.  It might be nice to have it go
higher or have a 0.1Hz resolution.

The best way to change the frequency would be with buttons; maybe 3 to cycle
the units, tens, and hundreds, or 4 for (fast + slow) * (up + down).  A
keyboard would be very nice, but it would be impractical to scan a keyboard
in the amount of time between pulses, especially if I also have to output
data to an LCD.

The easy way would be to get a nice 10 turn pot and connect it to an analog
input.  That might even be more intuitive for the user.  I could even have 2
pots for coarse and fine adjust.

It does need to quickly track what is changing it.  If the user is trying to
finely adjust the flash rate to measure the speed of something, it will be
very frustrating to wait any noticible amout of time between making a change
and seeing the result.

This is probably an inefficient use of parts, but I could use one pic as a
master to handle the input, translation to a delay amount, and LCD display
and a second pic as a slave to flash the LED; sort of my own custom PWM
chip.

Jason

{Original Message removed}

2004\08\03@053849 by Jinx

face picon face
> I don't think a granularity of 100ns will be needed.  I was planning
> on having a 1Hz resolution from 1 to 999 Hz.  It might be nice to
> have it go higher or have a 0.1Hz resolution

The faster the PIC the better. I started something a while ago, now
gathering dust, physically at least. A high-voltage PWM from 0.1Hz
to 200Hz, which is very doable with an 18F452 @ 40MHz

> The best way to change the frequency would be with buttons;
> maybe 3 to cycle the units, tens, and hundreds, or 4 for (fast
> + slow) * (up + down).  A keyboard would be very nice, but it
> would be impractical to scan a keyboard in the amount of time
> between pulses, especially if I also have to output data to an LCD

A keyboard and LCD would be fine at those speeds. Writing one
character to an LCD takes typically just 40us. If your timing is being
done with a timer interrupt that would give you plenty of time to
send a few characters to the display. Scanning buttons can be done
very much faster than a person could push/release, and also quite
possible between pulses

> The easy way would be to get a nice 10 turn pot and connect it
> to an analog input.  That might even be more intuitive for the user.
>  I could even have 2 pots for coarse and fine adjust

There will be a limit to how close you can get to the actual frequency
desired because of the granularity of instruction cycle times. But that
may not be important when trying to match a rotating shaft for example

I think I would try some method of coarse adjustment with either pots
or buttons, the result got by either maths or a table, and use a variable
clock input to Osc1 to fine tune the frequency exactly. Because the
instruction time is variable doing it that way, you'd have to use Timer1
in oscillator mode to measure the frequency for display

> This is probably an inefficient use of parts, but I could use one pic
> as a master to handle the input, translation to a delay amount, and
> LCD display and a second pic as a slave to flash the LED; sort of
> my own custom PWM chip

The only extra part I might consider would be 20us monostable,
like a 555, 74123 or 1/2 a 4001. This could also be made variable
so that the 20us is not dependent on s/w, leaving you with only the
frequency to worry about

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu

2004\08\03@062204 by Alan B. Pearce

face picon face
>The only extra part I might consider would be 20us
>monostable, like a 555, 74123 or 1/2 a 4001. This
>could also be made variable so that the 20us is not
>dependent on s/w, leaving you with only the
>frequency to worry about

It would also provide a failsafe in case the micro locks up leaving the
drive to the LED on. The hardware timer will ensure the led is not left with
permanent high current drive, resulting in failure of the LED.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu

2004\08\03@064035 by hael Rigby-Jones

picon face
{Quote hidden}

The easy way to do this is use a PIC that has a CCP module.  In compare
mode, this can be programmed to toggle an output when the CCPRxH:CCPRxL
registers match Timer1's value.  You get the advantage of the best possible
granularity (1 instruction cycle depending on timer1's pre-scaler setting)
and zero CPU overhead so the PIC won't break a sweat over updating LCDs and
scanning buttons.

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.
=======================================================================

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu

2004\08\03@085750 by Jan-Erik Soderholm

face picon face
Hi.
I sent this a couple of hours ago, but I never saw i on the piclist.
I'm resending and I'm sorry if it shows up twice...
/Jan-Erik.


Jason S wrote :

> The best way to change the frequency would be with buttons;
> maybe 3 to cycle the units, tens, and hundreds, or 4 for (fast + slow) * (up +
> down).

[AD:] Maybe something like this ? :

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3831550418

(Yes, it's me selling that module... :-) )



> The easy way would be to get a nice 10 turn pot and connect
> it to an analog input.  That might even be more intuitive for the
> user.  I could even have 2 pots for coarse and fine adjust.

I'd definitly use a "rotary encoder", with fine/coarse controlled
by the software. This is an all-digital solution, and you don't
have to worry about all analog design issues. Maybe combined
with the display module showed in the link above :-) :-)

> It does need to quickly track what is changing it.  If the
> user is trying to finely adjust the flash rate to measure the
> speed of  something, it will be very frustrating to wait any
> noticible amout of time between making a change
> and seeing the result.

A "noticible amout of time" (for a human) is a veeery looooong
time for a PIC !

This point is "pointless" if you don't quantify all those
times in some real time units, why not seconds... :-)

Best Regards,
Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu

2004\08\03@092239 by DJMurray

flavicon
face
Why do a calculation at all, Jason??  If I understand what you're trying
to acheve, I've done similar things many times with low-end PICs with no
real issues.  However, it may not be appropriate for your application.

What I did was find out what "granularity" I absolutely HAD to have
(i.e. 1 uSec resolution).  Granularity is defined as how fine I needed
to resolve the output and cycle time.  Then I set up a timer that I
could check for that resolution.  Every time my counter reached a number
equivalent to my resolution, I'd increment another counter.  This new
increment counter was set for a hard compare equal to the TOTAL number
of increments needed in a full cycle.

This increment compare, at a count equal to the TOTAL cycle time, set an
output HIGH and reset the increment counter, starting another cycle.
Another routine within this main loop would check the increment counter
for the number of counts I wanted the output HIGH and, when that number
was reached, turn OFF the output.

As a SUPER simple example, let's say I can live with a granularity of
10%, thus I have a total of 10 counts for every cycle, no matter how
many of those counts result in a HIGH output.  If I wanted a HIGH of 20%
of duty cycle, my HIGH routine would have a compare count of 2 counts.
Thus, at the start of every cycle the output is HIGH  and the cycle
begins.  2 counts later, the HIGH count is equal and output is turned
OFF, resulting in 1100000000 output.

This way, total cycle time is ALWAYS constant and the output ON time can
be easily varied almost anywhere within that time.

I'm oversimplifying this technique somewhat, but I hope it gives you
some idea how to go about addressing the problem.  This concept uses
polling to check for expiration, but I've also done a similar routine
using interrupts, which allowed me to do a lot of background processing
without significantly impacting the cycle.

Good luck!
Dennis

Jason S wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu

2004\08\03@092446 by Jan-Erik Soderholm

face picon face
Jason S

> The best way to change the frequency would be with buttons;
> maybe 3 to cycle the units, tens, and hundreds, or 4 for (fast + slow) * (up +
> down).

Maybe something like this ? :

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3831550418

> The easy way would be to get a nice 10 turn pot and connect
> it to an analog input.  That might even be more intuitive for the
> user.  I could even have 2 pots for coarse and fine adjust.

I'd definitly use a "rotary encoder", with fine/coarse controled
by the software. This is an all-digital solution, and you don't
have to worry about all analog design issues. Maybe combined
with the display module showed in the link above :-) :-)

> It does need to quickly track what is changing it.  If the
> user is trying to finely adjust the flash rate to measure the
> speed of  something, it will be very frustrating to wait any
> noticible amout of time between making a change
> and seeing the result.

A "noticible amout of time" (for a human) is a veeery looooong
time for a PIC !

This point is "pointless" if you don't quantify all those
times in some real time units, why not seconds... :-)

> This is probably an inefficient use of parts,

At first thought, I'd say yes...

> but I could use
> one pic as a
> master to handle the input, translation to a delay amount,
> and LCD display
> and a second pic as a slave to flash the LED; sort of my own
> custom PWM
> chip.


Best Regards,
Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu

2004\08\03@172940 by Jason S

flavicon
face
From: "Jinx" <joecolquittEraseMEspam.....CLEAR.NET.NZ>
Sent: Tuesday, August 03, 2004 2:40 AM


> A keyboard and LCD would be fine at those speeds. Writing one
> character to an LCD takes typically just 40us. If your timing is being
> done with a timer interrupt that would give you plenty of time to
> send a few characters to the display. Scanning buttons can be done
> very much faster than a person could push/release, and also quite
> possible between pulses

By those speeds do you mean 40MHz? I was planning on using 4MHz; with an
upper speed of 1kHz, that still leaves me almost 1000 instructions during
each off-period.  At least I have some 18F252's so I won't have to buy
another pic for the project to do 40MHz.

> There will be a limit to how close you can get to the actual frequency
> desired because of the granularity of instruction cycle times. But that
> may not be important when trying to match a rotating shaft for example

The design goal is to be a few times better at everything than the human eye
can detect.  I can't imagine how this could be used with a detector other
than a human eye.  In the grand scheme of how fast the MCU is, this allows a
pretty high granularity.

> I think I would try some method of coarse adjustment with either pots
> or buttons, the result got by either maths or a table, and use a variable
> clock input to Osc1 to fine tune the frequency exactly. Because the
> instruction time is variable doing it that way, you'd have to use Timer1
> in oscillator mode to measure the frequency for display

If I'm using a coarse adjust and variable clock input, how will I be able to
display the actual frequency with any more precision than the coarse adjust
alone gives?


Jason

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu

2004\08\03@173145 by Jason S

flavicon
face
That's an excellent point.  While developing the device, I'll limit the
current to 20mA, but in use it will be 60-100mA which will kill the LED very
fast if it's left on.  Do you mean an external device or something inside
the pic?

Jason

From: "Alan B. Pearce" <RemoveMEA.B.PearceEraseMEspamEraseMERL.AC.UK>
Sent: Tuesday, August 03, 2004 2:52 AM


> It would also provide a failsafe in case the micro locks up leaving the
> drive to the LED on. The hardware timer will ensure the led is not left
with
> permanent high current drive, resulting in failure of the LED.

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu

2004\08\03@174014 by Jan-Erik Soderholm

face picon face
Jason S wrote :

> From: "Alan B. Pearce" <RemoveMEA.B.PearceTakeThisOuTspamspamRL.AC.UK>
> > The hardware timer will ensure the led is not left with
> > permanent high current drive, resulting in failure of the LED.

>
>  Do you mean an external device or something inside the pic?

Hi. (I'm not Alan, but... :-) )

I read "hardware timer" as using one of the TMR0-3 timers
instead of using software timing loops (that could easily "hang"
with the LED "on" due to some unexpected event). The TMRx
timers could also hang, but that's a bit more unlikely...

Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamspamspamBeGonemitvma.mit.edu

2004\08\03@174843 by Jason S

flavicon
face
From: "Jan-Erik Soderholm" <RemoveMEjan-erik.soderholmKILLspamspamTELIA.COM>
Sent: Tuesday, August 03, 2004 3:37 AM

> Maybe something like this ? :
>
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3831550418

It looks nice, but I want the overall device to be a lot smaller than that
module.  I'd like the whole device to be easily hand-held.  Actually, I've
been trying to find small character LCDs.  Even a standard 1x8 module is
almost 3 inches wide.  I'l like to get one in the 1-1.5" range; of course it
doesn't help that I want to keep the single unit price for the display in
the $5 range which means surplus.

You can buy commercially made digital stroboscopes with xenon flash tubes
for under $200 on ebay:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=4678&item=3830499175&rd=1

Since the xenon tube alone makes that unit better than anything I could do
with LEDs, it sets a fairly low ceiling on price of components for this
project.  That one is 9" long, weighs 2 pounds, and must be line powered
though.  My advantages will be small size and weight, battery powered, and
low cost.

> I'd definitly use a "rotary encoder", with fine/coarse controled
> by the software. This is an all-digital solution, and you don't
> have to worry about all analog design issues. Maybe combined
> with the display module showed in the link above :-) :-)

I might be missing something with a rotary encoder.  The only ones I've seen
are cylinders 4" tall and 4" in diameter.  I had a quick look at Mouser and
they do seem to be around that size and start at $160.

> A "noticible amout of time" (for a human) is a veeery looooong
> time for a PIC !

That just means the PIC hardware should easily be able to respond that fast.
Whether or not it does is up to the software.


> > This is probably an inefficient use of parts,
>
> At first thought, I'd say yes...

But Microchip would probably love that design style :).

Jason

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu

2004\08\03@174844 by Jason S

flavicon
face
From: "Michael Rigby-Jones" <spamBeGoneMichael.Rigby-JonesSTOPspamspamEraseMEBOOKHAM.COM>
Sent: Tuesday, August 03, 2004 3:43 AM

> The easy way to do this is use a PIC that has a CCP module.  In compare
> mode, this can be programmed to toggle an output when the CCPRxH:CCPRxL
> registers match Timer1's value.  You get the advantage of the best
possible
> granularity (1 instruction cycle depending on timer1's pre-scaler setting)
> and zero CPU overhead so the PIC won't break a sweat over updating LCDs
and
> scanning buttons.

I'd thought about that, but the CCP mo

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu

2004\08\03@175505 by Jason S

flavicon
face
I think I just hit send on my reply to this before entering my reply.  Sorry
for the accidental post.

From: "Michael Rigby-Jones" <EraseMEMichael.Rigby-JonesspamEraseMEBOOKHAM.COM>
Sent: Tuesday, August 03, 2004 3:43 AM

> The easy way to do this is use a PIC that has a CCP module.  In compare
> mode, this can be programmed to toggle an output when the CCPRxH:CCPRxL
> registers match Timer1's value.  You get the advantage of the best
possible
> granularity (1 instruction cycle depending on timer1's pre-scaler setting)
> and zero CPU overhead so the PIC won't break a sweat over updating LCDs
and
> scanning buttons.

That sounds promising, but I'll have to learn to use the CCP in compare
mode, I've only used PWM mode.

Anyway, I still don't know where I get the value to put in CCPRxH:CCPRxL if
I have a frequency in Hz.  There are too many values to use a lookup table
and the math seems very difficult to implement on a pic.

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu

2004\08\03@180334 by Jan-Erik Soderholm

face picon face
Jason S wrote :

> I might be missing something with a rotary encoder.
> The only ones I've seen are cylinders 4" tall and 4" in diameter.

Just to show a few so you get an idea... :

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=3831784328

(No ! Not my stuff this time ! :-) )

Regards,
/Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2004\08\03@180748 by Jan-Erik Soderholm

face picon face
Hi !

I should have added :

http://dkc3.digikey.com/PDF/T042/1051.pdf

Which shows a typical "retail" price on the encoders...

Regards,
Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspam_OUTspammitvma.mit.edu

2004\08\03@182131 by Jinx

face picon face
> By those speeds do you mean 40MHz? I was planning on using
> 4MHz; with an upper speed of 1kHz, that still leaves me almost
> 1000 instructions during each off-period.  At least I have some
> 18F252's so I won't have to buy another pic for the project to do
> 40MHz

Perhaps I was over-stating the speed aspect - it's just that I rarely
run PICs at mid-range speeds. Usually 32kHz or close to or at
flat out

> If I'm using a coarse adjust and variable clock input, how will I be
> able to display the actual frequency with any more precision than
> the coarse adjust alone gives ?

To take one scenario -

The desired frequency is 748.73Hz, to match spinning blades

Say you can set the output frequency to within 1Hz (eg 749Hz) with
pushbuttons, CCP and a table, and an Osc1 (ie operating) frequency
of 20MHz, for the sake of argument. By being able to vary Osc1 by
just 0.5% (= +/- 100kHz) the output frequency would cover the range
745Hz to 752Hz, with whatever resolution you can vary Osc1 by

Timer1 is being incremented at 32kHz by its crystal, independently
of Osc1 (ie how fast the PIC is processing instructions), and can be
used to measure the output frequency

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-request.....spamTakeThisOuTmitvma.mit.edu

2004\08\03@183207 by Josh Koffman

face picon face
Couple of things. First off, the 8x2 LCD module by Crystalfontz is
just a hair over 2.25", and is priced at about $10 in singles, $5 in
quantity. Second, there are many encoders about the size of pots.
Digikey carries a bunch, and they are quite cheap. Enjoy!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On Tue, 3 Aug 2004 14:52:48 -0700, Jason S <TakeThisOuTpicKILLspamspamspamcanadaspeaks.com> wrote:
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamRemoveMEmitvma.mit.edu

2004\08\03@183208 by Olin Lathrop

face picon face
Jason S wrote:
> If I'm using a coarse adjust and variable clock input, how will I be
> able to display the actual frequency with any more precision than the
> coarse adjust alone gives?

You mentioned previously that you are trying to make an LED "strobe".  Is
this for measuring rotation speed?  If so, it might be easier to have a pot
control the frequency of an analog oscillator and have the PIC measure the
frequency instead of trying to generate it.  With a little filtering, you
can get much higher resolution for measuring a frequency than producing one.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu

2004\08\03@183754 by Olin Lathrop

face picon face
Jason S wrote:
> Anyway, I still don't know where I get the value to put in
> CCPRxH:CCPRxL if I have a frequency in Hz.

Period = 1 / frequency

All you need is a divide.  Since this only needs to be done when the user
changes the frequency, speed is not an issue.  Besides even 1mS would be a
long time for a divide, and that's instantaneous in human terms.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu

2004\08\03@183754 by Jinx

face picon face
> I still don't know where I get the value to put in CCPRxH:CCPRxL
> if I have a frequency in Hz.  There are too many values to use a
> lookup table

If you were to try and do the timing purely digitally, there will be a
practical limit. However, variable Osc1 is an analogue element

Starting with my previous example, you could set the coarse
frequency to within just 5Hz, and have Osc1 variable over a slightly
wider range. 100Hz to 1kHz in 5Hz steps is less than a page on
an 18F

Where you'd get the values from is quite simple. At a known Osc1,
you know how many instruction cycles it takes to perform a delay.
This is what you plug into the table. (centre frequency)/step is the
index to that table

> and the math seems very difficult to implement on a pic.

Are you aware of the maths code generator ?

http://www.piclist.com/techref/piclist/codegen/index.htm

If I were able to dish out medals, Nikolai would get one. It's a
fantastic utility and I use it often

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspammitvma.mit.edu

2004\08\03@213601 by Jason S

flavicon
face
From: "Jan-Erik Soderholm" <jan-erik.soderholmEraseMEspamTELIA.COM>
Sent: Tuesday, August 03, 2004 3:08 PM


> http://dkc3.digikey.com/PDF/T042/1051.pdf
>
> Which shows a typical "retail" price on the encoders...


Thanks for the links.  I didn't know such parts existed.  From what I've
heard of rotary encoders, optical is the only way to go, so I'm still
looking at $40 for the pot sized one.

That makes the ebay ones look like a great buy, even if they're mechanical.

--------------

From: "Jinx" <RemoveMEjoecolquittEraseMEspamspam_OUTCLEAR.NET.NZ>
Sent: Tuesday, August 03, 2004 3:21 PM


> Perhaps I was over-stating the speed aspect - it's just that I rarely
> run PICs at mid-range speeds. Usually 32kHz or close to or at
> flat out

I've never used one outside the 1-4MHz range, usually at 4MHz because I like
the 1 instruction = 1us speed.

> To take one scenario -
>
> The desired frequency is 748.73Hz, to match spinning blades

So I would be using the PIC to help the oscillator pulse the LED, and also
as a frequency counter?

> Are you aware of the maths code generator ?

I wasn't.  It looks very useful, but not in this application.  It seems to
only support multiply/divide by a constant.  In multiplication this isn't a
limitation, but for division I can only have the variable as the numerator.
For 1/x, I need the variable as the denominator.

--------------


From: "Josh Koffman" <@spam@joshybearRemoveMEspamEraseMEGMAIL.COM>
Sent: Tuesday, August 03, 2004 3:31 PM


> First off, the 8x2 LCD module by Crystalfontz is
> just a hair over 2.25", and is priced at about $10 in singles, $5 in
> quantity.

Those displays look perfect.  I have a 1x2.5x3.5" box I'd like to fit it
into.  It looks like the display would fit nicely across the 2.5" side.  The
$8.25 shipping brings the price over $18 for a single one, even in 10
quantity the price becomes reasonable, and in 500-1000 it's very cheap.
They just don't seem at all interested in small orders.  Do you know of a
more retail oriented site that would sell them at a decent price.


--------------


From: "Olin Lathrop" <EraseMEolin_piclistspam@spam@EMBEDINC.COM>
Sent: Tuesday, August 03, 2004 3:32 PM


> You mentioned previously that you are trying to make an LED "strobe".  Is
> this for measuring rotation speed?  If so, it might be easier to have a
pot
> control the frequency of an analog oscillator and have the PIC measure the
> frequency instead of trying to generate it.  With a little filtering, you
> can get much higher resolution for measuring a frequency than producing
one.

It's for measuring rotation speed and other periodic motions, yes.

With that idea though, how can I fix the on-time regardless of the
frequency?  I'm sure it is possible, but I haven't done any analog
electronics in a long time, and I never did much.  Also, with an on-time
measured in microseconds, it needs to have a very sharp squarewave, I can't
have it slowly turning on and off.

> Period = 1 / frequency
>
> All you need is a divide.  Since this only needs to be done when the user
> changes the frequency, speed is not an issue.  Besides even 1mS would be a
> long time for a divide, and that's instantaneous in human terms.

That much, I know.  I could use a division algorithm from the piclist
archive, but 1/x is probably easier than division, and there might be a nice
way to otherwise generate the pulses.  How would the division return
1/120Hz?  It's 8.333.... ms.

Jason

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestspam_OUTspam.....mitvma.mit.edu

2004\08\03@222255 by Jinx

face picon face
> I've never used one outside the 1-4MHz range, usually at 4MHz
> because I like the 1 instruction = 1us speed

Well, you can use your 4MHz crystal and enable the PLL (on the 252),
which will bump running speed up to 16MHz, or 0.25us IC

> So I would be using the PIC to help the oscillator pulse the LED, and
> also as a frequency counter ?

Yes. The vast majority of the PIC is running at a user-variable speed,
but one little part of it, Timer1, is running at a constant frequency

Olin's suggestion of an external oscillator for the LED and then use
the PIC to measure the frequency is a good and simple answer, but
this could be an opportunity to expand your knowledge of features
like CCP

> > Are you aware of the maths code generator ?
>
> I wasn't.  It looks very useful, but not in this application.  It seems
> to only support multiply/divide by a constant.  In multiplication this
> isn't a limitation, but for division I can only have the variable as the
> numerator. For 1/x, I need the variable as the denominator

One of my products is a controller for a variable-pitch propellor for
light planes and I obviously need to know rpm frequency. This can
be done with a division of Timer1 into 75,000,000. These are some
of my program notes. The propellor has 6 electromagnetic sensors,
ie each rev -> 6 pulses

; Timer1 counts to 75,000,000 with /2 pre-scale in 1 minute @ 10MHz
; = (10,000,000/4/2) * 60

; 200Hz = 5ms, x 6 = 30ms = 30,000us / 400ns = 75,000 IC
; Timer1 reading of 37,500 with / 2 pre-scaler, 50 updates / sec
;
; 300Hz = 3.333ms, x 6 = 20ms = 20,000us / 400ns = 50,000 IC
; Timer1 reading of 25,000 with / 2 pre-scaler, 75 updates / sec
;
; Divide Timer1 by 16 then divide into 4,687,500 ( = 75,000,000 / 16)
;
; Example - Timer1 for 30 IRQs = 37,500
;           Divide into 75,000,000 = 2,000 (rpm)
;           Timer1 for 30 IRQs = 25,000
;           Divide into 75,000,000 = 3,000 (rpm)

The division routine, as created by Nikolai's page, is (comments
removed for readability) below. Not very long, executes in around
240 IC => just 60us at 10MHz and works perfectly. Many of these
out in the field (air ?) for a couple of years now with not a hiccup.
The only restriction is that it doesn't kick in until 1700rpm, which
is far too slow to be airborne anyway

;================================================
;        Divide 4,687,500 by (Timer1 / 16)
;================================================

;Inputs:
;   Dividend - aargb0:aargb1:aargb2 (aargb0 = MSB)
;   Divisor  - bargb0:bargb1

div2416  movlw  .24
        movwf  loopcount

        movlw  0x8c          ;4,687,500d = 0x47868C
        movwf  aargb2
        movlw  0x86
        movwf  aargb1
        movlw  0x47
        movwf  aargb0

        movf   temp,w
        movwf  bargb1
        movf   temp0,w
        movwf  bargb0

        clrf   remb0
        clrf   remb1

lp2416   rlf    aargb2
        rlf    aargb1
        rlf    aargb0

        rlf    remb1
        rlf    remb0

        rlf    loopcount

        movf   bargb1,w
        subwf  remb1
        movf   bargb0,w
        btfss  carry
        incfsz bargb0,w
        subwf  remb0,w

        skpnc
        bsf    loopcount,0

        btfsc  loopcount,0
        goto   ok46ll

        movf   bargb1,w
        addwf  remb1
        movf   remb0,w

ok46ll   movwf  remb0
        clrc
        rrf    loopcount
        decfsz loopcount
        goto   lp2416

        rlf    aargb2
        rlf    aargb1
        rlf    aargb0

        movf   aargb2,w
        movwf  lo
        movf   aargb1,w
        movwf  hi

divend  return

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestEraseMEspammitvma.mit.edu

2004\08\04@021350 by Wouter van Ooijen

face picon face
> > http://dkc3.digikey.com/PDF/T042/1051.pdf
> >
> > Which shows a typical "retail" price on the encoders...

don't spend too much on a simple (mechanical) encoder:
http://www.voti.nl/shop/p/M-SW-ROT.html

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\04@040112 by Alan B. Pearce

face picon face
>> From: "Alan B. Pearce" <A.B.PearcespamBeGonespamRL.AC.UK>
>> > The hardware timer will ensure the led is not left with
>> > permanent high current drive, resulting in failure of the LED.
>
>>
>>  Do you mean an external device or something inside the pic?
>
>Hi. (I'm not Alan, but... :-) )
>
>I read "hardware timer" as using one of the TMR0-3 timers
>instead of using software timing loops (that could easily "hang"
>with the LED "on" due to some unexpected event). The TMRx
>timers could also hang, but that's a bit more unlikely...

No but I am :)))

What I was referring to was the suggestion to use a 555 or some other form
of monostable to get the 20uS pulse. It could be done with the CCP module,
but there would be difficulties in changing the frequency of the pulse then.

Later on Jason wrote
>How would the division return
>1/120Hz?  It's 8.333.... ms.

Well, remember that is also 8333uS and the PIC at 4MHz clock speed has a 1uS
instruction period, and others have pointed out that using the 18F series
with the PLL enabled can make this 0.25uS with a 4MHz clock. With 10MHz
clock and PLL enabled it comes down even more .... Don't get too hung up on
the units, convert them to other units more in keeping with the "internal
timing units" of the PIC.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\04@043512 by Jason S

flavicon
face
From: "Alan B. Pearce" <RemoveMEA.B.Pearce@spam@spamspamBeGoneRL.AC.UK>
Sent: Wednesday, August 04, 2004 1:03 AM

> What I was referring to was the suggestion to use a 555 or some other form
> of monostable to get the 20uS pulse. It could be done with the CCP module,
> but there would be difficulties in changing the frequency of the pulse
then.

That makes sense.  If I understand, then changing the duration of the pulse
would involve changing the passives in the 555 circuit.  I also wouldn't
have to worry about the duty cycle of the pulse with this situation because
no matter what the duty cycle of the PWM is, I will get a single 20uS pulse
for every complete PWM cycle, which is what I want.

I could even use the PWM module, but I remember a discussion a while about
about it not being useful for long periods, and I'd need 1Hz to 1kHz.

I suppose I could get away with a 556 and use one half in astable mode to
generate the frequency and the other half in monostable mode to generate the
pulses.

> Well, remember that is also 8333uS and the PIC at 4MHz clock speed has a
1uS
> instruction period

To the nearest uS is close enough, but then my calculation is 1/120 *
1,000,000 and round to the nearest integer.  I think what I'm getting hung
up on here is the need for a floating point datatype.

Jason

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\04@045757 by Alan B. Pearce

face picon face
>> Well, remember that is also 8333uS and the PIC at 4MHz
>> clock speed has a 1uS instruction period
>
>To the nearest uS is close enough, but then my calculation
>is 1/120 * 1,000,000 and round to the nearest integer.  I
>think what I'm getting hung up on here is the need for a
>floating point datatype.

Not necessarily. I suspect that you will do quite nicely with a 16 or 24 bit
fixed point integer arithmetic without the need to go to floating point.
Your display is going to be to a fixed resolution, so being able to measure
to about 1 bit better resolution will be plenty accurate, and then you only
need enough bits to get to the other end of your display range. Now 1Hz to
1kHz is only a 1000;1 range, or less than 10 bits, so I would look at using
16 bit numbers.

I think you are getting stuck on being able to stop the rotational motion
with your strobe. However if you use an analogue oscillator like you
suggested, and measure the frequency, then each step in the frequency
measurement is going to cover a range of shaft rpm. In some ways it may be
better to have the strobes go in steps, and then the operator will see the
motion turn slowly one way, but go to the next step and it turns slowly the
other way, so he knows the speed is between a & b, instead of assuming it is
x because that is what the instrument says, without realising the instrument
has a deadband which is x +/- y always displayed as x.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\04@045757 by Jinx

face picon face
> I could even use the PWM module, but I remember a discussion a
> while about about it not being useful for long periods, and I'd need
> 1Hz to 1kHz

There are problems using the PWM module as a one-stop shop. First,
as you say, it won't go slow enough. Second, at higher speeds you
lose resolution. Because it's tied to Timer2, which in turn is tied to the
operating frequency of the PIC, the only practical option, if you really
wanted to use the PWM module, is to change the PIC's frequency to
get the required frequency and resolution in several ranges. It could
be done, but messy and there are better ways

Your idea of a 556 would work, a 4-gate digital IC could do it too, so
could a function generator (ICL8038, XR2203 etc). But would you
want to miss the chance to explore the PIC a little ?

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\05@091953 by Chris Emerson

flavicon
face
On Tue, Aug 03, 2004 at 12:53:05AM -0700, Jason S wrote:
> The easy way would be to get a nice 10 turn pot and connect it to an analog
> input.  That might even be more intuitive for the user.  I could even have 2
> pots for coarse and fine adjust.

In that case can you take the on-time (or period) directly from the
analog input, instead of trying to convert from frequency to period?
Then there's no division needed.

Chris

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

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