Searching \ for 'Variable pulse generation' 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/index.htm?key=variable+pulse+generation
Search entire site for: 'Variable pulse generation'.

Truncated match.
PICList Thread
'Variable pulse generation'
1997\04\15@081952 by FrankT

picon face
I want to generate a pulse with a constant ON time of  50 micro seconds the
OFF time should be variable. The frequency of the signal should be variable
from 1Hz up to 10kHz the resolution at 10 kHz should be 100 Hz.

Anybody HELP please

Frank Temmerman

1997\04\15@210844 by Steve Hardy

flavicon
face
> From: FrankT <spam_OUTgymnaTakeThisOuTspamCOMPUSERVE.COM>
>
> I want to generate a pulse with a constant ON time of  50 micro seconds the
> OFF time should be variable. The frequency of the signal should be variable
> from 1Hz up to 10kHz the resolution at 10 kHz should be 100 Hz.

If you are using a PIC16Cxx with a CCP module, you can configure it to
operate in the way you suggest.  There are at least 2 possibilities
if you don't want external hardware.  The first possibility does not
really do what you want, but may be an inspiration.  The second
possibility will do it, if you code carefully.

1. PWM module

Normally, you change the duty cycle by changing the value in CCPR1L, and
set the overall frequency using the value in PR2.  You can generate
a constant ON-time while varying the frequency by making CCPR1L a constant
value and varying the value in PR2.

If you set CCPR1L to '1', and arrange for the TMR2 update rate to be
once every 50us, then changing the value in PR2 from 2 to 255 will
result in an output frequency of

       PR2     Freq (KHz)
       ----    ----------
       2       10
       3       6.666
       4       5
       5       4
       ....
       255     20/256 = 78Hz

Actually, the above might be a bit wrong because I can't remember exactly
when TMR2 is reset (on match or after matching PR2).  Anyway, I think
you get the idea.

2. Compare module

Now if you really need the very low duty cycle of 50us in 1Hz, then
you will have to generate this at least partly in software.  You can
configure the CCP module in compare mode, which basically allows the
16-bit timer (TMR1) to be used.  To make this practical, you would
need to get interrupted when TMR1 reached the 16 bit value in CCPR1H
and CCPR1L.  The interrupt routine would set a port pin high for 50us.
You would need to configure the CCP module so that it automatically
reset TMR1 to zero when the interrupt triggered ('special event trigger').

To get a minimum frequency of 1Hz or thereabouts, you would need to
ensure the update rate of TMR1 is every 1/65536 second.  The resolution
would, as always, be better at the low frequency end.  The high end
resolution would be about 1500Hz, which is not as good as what you
want.  In order to achieve this, your software will need to increase
the update rate of TMR1 at the appropriate point, and compensate the
value in CCPR1H/L.  E.g., at the 100Hz point, increase the TMR1 update
rate by a factor of 16, and multiply CCPR1H/L by the same (shift left 4).
This would improve the resolution at 10KHz to better than 100Hz.

Regards,
SJH
Canberra, Australia

1997\04\17@030457 by Wolfram Liebchen

flavicon
face
At 11:07 16.04.97 EST, you wrote:
>> From: FrankT <.....gymnaKILLspamspam@spam@COMPUSERVE.COM>
>>
>> I want to generate a pulse with a constant ON time of  50 micro seconds the
>> OFF time should be variable. The frequency of the signal should be variable
>> from 1Hz up to 10kHz the resolution at 10 kHz should be 100 Hz.
> <snip>
>1. PWM module
>Normally, you change the duty cycle by changing the value in CCPR1L, and
>set the overall frequency using the value in PR2.  You can generate
>a constant ON-time while varying the frequency by making CCPR1L a constant
>value and varying the value in PR2.
>

Might this method yield to unpredicted switch phenomena?
As I think, the CCPR is double-buffered, to avoid a change of the real
counting
register. But if you reduces PR2 to a value less than the value of the
counter,
it may count a very long time. This occurs only once, but that might be too
often?

-- Wolfram


+-----------------------------------------------------+
| Wolfram Liebchen                                    |
| Forschungsinstitut fŸr Optik, TŸbingen, Deutschland |
| liebchenspamKILLspamffo.fgan.de                         |
+-----------------------------------------------------+

1997\04\17@211152 by Steve Hardy

flavicon
face
> From: Wolfram Liebchen <.....liebchenKILLspamspam.....FFO.FGAN.DE>
> >1. PWM module
> >Normally, you change the duty cycle by changing the value in CCPR1L, and
> >set the overall frequency using the value in PR2.  You can generate
> >a constant ON-time while varying the frequency by making CCPR1L a constant
> >value and varying the value in PR2.
> >
>
> Might this method yield to unpredicted switch phenomena?
> As I think, the CCPR is double-buffered, to avoid a change of the real
> counting
> register. But if you reduces PR2 to a value less than the value of the
> counter,
> it may count a very long time. This occurs only once, but that might be too
> often?

This is correct.  In order to get glitchless operation, you have to use
a simple software trick:  before changing the PR2 register, wait for
the PWM output pin to go high.  Slightly better performance could be
obtained by reading TMR2 and waiting (if necessary) for it to become
less than the proposed new value for PR2.  In fact, you don't have
to wait.  If TMR2 is >= new PR2, then just zero TMR2 and load PR2;
otherwise leave TMR2 alone.

Regards,
SJH
Canberra, Australia

1997\04\21@050233 by FrankT

picon face
Steve Hardy wrote

> 2. Compare module

<snip >
>the high end resolution would be about 1500Hz, which is not as good as
what you >want.  In order to achieve this, your software will need to
increase >the update rate of TMR1 at the appropriate point, and compensate
the >value in CCPR1H/L.  E.g., at the 100Hz point, increase the TMR1
update >rate by a factor of 16, and multiply CCPR1H/L by the same (shift
left 4). >This would improve the resolution at 10KHz to better than 100Hz.

sorry for this late response.

I think I will forget the 505s pulse width, this I can solve with a
monostable multivibrator. It will cost me some more hardware but it will
take a load of the software complexity.

I don't understand why the compare is needed  together with the Timer1 to
generate the wanted signal.

I now use the timer register without the compare and I see some problems
when trying to load the timer registers. When I load the registers, by
sending via I2C another value to the timer registers for example with
0xFF,0x9B I can generate a signale with a frequency of  exact 10.000 hz.
Sometimes when I try to change this value, the generated signal starts
acting strange, sometimes the generated signal disappears for some time
etc.. when I keep transmitting the same values over and over again via I2C
somethimes the signal get stable again.

I suppose it has something to do with the intterupts that I use. Besides
the TMR1 and the I2C I will also be needing TMR0 interrupt and maybe an ADC
interrupt. Is there something I should take care of.

greetings Frank Temmerman

1997\04\21@202532 by Steve Hardy

flavicon
face
> From: FrankT <EraseMEgymnaspam_OUTspamTakeThisOuTCOMPUSERVE.COM>
>
> Steve Hardy wrote
>
> > 2. Compare module
>
> <snip >
> >the high end resolution would be about 1500Hz, which is not as good as
> what you >want.  In order to achieve this, your software will need to
> increase >the update rate of TMR1 at the appropriate point, and compensate
> the >value in CCPR1H/L.  E.g., at the 100Hz point, increase the TMR1
> update >rate by a factor of 16, and multiply CCPR1H/L by the same (shift
> left 4). >This would improve the resolution at 10KHz to better than 100Hz.
>
> sorry for this late response.
>
> I think I will forget the 505s pulse width, this I can solve with a
> monostable multivibrator. It will cost me some more hardware but it will
> take a load of the software complexity.

Well the software shouldn't be all that complicated.  To get a precise
50us output, you can code a software loop which runs while interrupts
are disabled (e.g. in the interrupt handler itself).  Of course this
depends on whether the rest of your application can tolerate this.  If
you are using slave IIC at 100KHz, 50us should not cause you to lose
any data, since a byte will take about 80us to receive.

>
> I don't understand why the compare is needed  together with the Timer1 to
> generate the wanted signal.

Compare mode allows timer1 to free-run as a divide-by-anything counter,
so long as you set the flag which resets timer1 to zero when the compare
'hits'.  If you set it up correctly, timer1 starts at zero and counts
up at a rate set by the processor clock and a prescaler.  When it reaches
the 16-bit value in ccpr1h/l, timer1 is automatically reset to zero and
and interrupt will be triggered.  The interrupt service routine will
immediately set a port pin high for 50us.

>
> I now use the timer register without the compare and I see some problems
> when trying to load the timer registers. When I load the registers, by
> sending via I2C another value to the timer registers for example with
> 0xFF,0x9B I can generate a signale with a frequency of  exact 10.000 hz.
> Sometimes when I try to change this value, the generated signal starts
> acting strange, sometimes the generated signal disappears for some time
> etc.. when I keep transmitting the same values over and over again via I2C
> somethimes the signal get stable again.

Probably your interrupt handler is not working correctly.  The solution
to your problem depends on how you are deciding when to reset timer1.
Obviously, the best way is to use the hardware (compare mode).

>
> I suppose it has something to do with the intterupts that I use. Besides
> the TMR1 and the I2C I will also be needing TMR0 interrupt and maybe an ADC
> interrupt. Is there something I should take care of.

Just make sure you prioritise your order of handling each type of interrupt.
Process the most time-critical first.  Also, with the PIC, it is important
for you to explicitly clear the interrupt flag bit before 'retfie'.


Regards,
SJH
Canberra, Australia

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