PDA

View Full Version : HPWM10 Frequency Updating



duncan303
- 7th January 2008, 14:41
Hi

This week I are been mostly working on HWPM.......... to produce undetermined fixed frequencies on CCP1 between approx 10,000Hz and 500,000Hz for durations of approx 10 seconds. For the moment the dutycycle is a secondary consideration. I am testing using a 16f628A at the moment but I may have to change to an 18 series. It must use HPWM

As this is a broad range and to achieve better resolution at the higher frequencies I am running at 16mhz and introducing prescaling at the lower frequencies.

The frequency required is received HSER as a WORD and the code calculates PR2 etc. My own code sort of works Ok but it is very ugly and limited ( I upgraded to 2.5 to use LONGS etc but have yet to been unable to get PBL to compile with anything significant :( )


However,

I have also had an constant eye on HPWM10 By Darrell Taylor (Peu and Mister E whose Pic multi-Calc I use as de facto: thankyou Mister E) considering that I may have certain frequency ranges dedicated to different channels.

HPWM10 works beautifully to update the dutycycle of given frequencies, smooth and glitch free and very easy to use. However I would be using it the other way round ie to update the frequency for a given dutycycle. Given the fact that 10Bit resolution is not always available over the ranges I am working with, I set the variable _DutyCycle = 100.

There are stages in my frequency range when the BYTE value of PR2 overflows and the prescaler is incremented. For the purpose of this post I have the prescaler set 1:1

A bit long winded but I have captured the value of PR2 with respect to frequency as output from HPWM10 and inconsistencies start to occur around 35940Hz , PR2 recovers at 36140Hz but as can be seen in capture1.txt the trend occurs more regularly thereafter. The inconsistencies are as compared to Mister E's Pic multi-Calc.

I should be able to work out why this is happening rather than just observing, however I am confused......... could this be to do with parsing during the maths calculation?

Duncan

Charles Linquis
- 7th January 2008, 21:04
I don't know if it will help you, but some time ago I wrote a little routine for an 18F8722 running at either 20 or 40Mhz that lets you enter the PWM frequency and then increment and decrement the duty cycle with the UP and DOWN arrow keys on a keyboard.

It doensn't allow for infinite frequencies, but is a good test tool.

<CODE>

HSEROUT [13,10,10,"1. Test PWM ",13,10]



HSEROUT [13,REP 10\4]
HSEROUT ["Pick PWM Frequency 1 = 312Khz,2 = 156Khz, 3 = 78Khz, 4 = 39Khz "]
HSERin [Char]
IF Char < "1" or Char > "4" THEN
HSEROUT [13,10,10]
GOTO SpecialUse
ENDIF

IF Mhz40 = 1 THEN
Select CASE Char

CASE "1"
PWMFREQ = $1F
NumBits = 7
MaxPWM = 127

CASE "2"
PWMFREQ = $3F
NumBits = 8
MaxPWM = 255

CASE "3"
PWMFREQ = $7F
NumBits = 9
MaxPWM = 511

CASE "4"
PWMFREQ = $FF
NumBits = 10
MaxPWM = 1023
END SELECT

ELSE
Select CASE Char

CASE "1"
PWMFREQ = $F
NumBits = 6
MaxPWM = 63

CASE "2"
PWMFREQ = $1F
NumBits = 7
MaxPWM = 127

CASE "3"
PWMFREQ = $3F
NumBits = 8
MaxPWM = 255

CASE "4"
PWMFREQ = $7F
NumBits = 9
maxPWM = 511
END SELECT
ENDIF


CCP1CON = %00001100
CCPR1L = %00010000
CCPR1H = %00000000 ' Initialize to 0, PWM register
PR2 = PWMFREQ
T2CON = %00000100 ' Prescale 1, Timer2 ON - Needed for PWM
PORTC.2 = 0
TRISC.2 = 0
PWMVal = 0
Gosub WritePWMreg
HSEROUT [13,10,10]

HSEROUT ["PWM Value (",#MaxPWM," Max)",13,10]
HSEROUT ["0",8]
NewChar:
HSERIN [Char]
If Char = 27 THEN
HSERIN 50,NoArrow,[Char2,Char3]
IF Char3 = 65 AND PWMVal < MaxPWM tHEN
PwmVal = PWMVal + 1
ENDIF
IF Char3 = 66 AND PWMVal > 0 tHEN
PwmVal = PWMVal - 1
ENDIF
HSEROUT [#PWMVal," ",REP 8\7]
GOSUB WritePWMReg
ENDIF

goto NewChar
NoArrow:
Break = 1
PWMVal = 0
Gosub WritePWMReg
CCP1CON = 0 ; Shut off the PWM controller
GOTO Begin



WritePWMReg:
CCPR1L = PWMVal >> 2
CCP1CON.5=PWMVal.1
CCP1CON.4=PWMVal.0
RETURN

</CODE>

Darrel Taylor
- 7th January 2008, 21:11
Hi Duncan,

I'm not sure how you're getting frequencies between 10,000 and 500,000 in a word var, but for sure, the HPWM10 macro will have problems with frequencies greater than 32,767.

The calculation from frequency to TimerTicks uses the DIV32 command, and the Divisor has a 15-bit maximum (32,767). The limitation is the same for PBP's HPWM.

Since you have PBPL, it's possible to modify the macro to use LONG's.
Then it won't have the DIV32 problem anymore.

But if you're having problems getting PBPL to work. That may not help out either.
<br>

BrianT
- 8th January 2008, 02:11
I need a ten bit HPWM so I searched for "HPWM10 macro" as mentioned in the prior post.

No joy.

Here is the error message.........

Did you mean: HPM 10 macro

No standard web pages containing all your search terms were found.

Your search - HPWM10 macro - did not match any documents.

Suggestions:
Make sure all words are spelled correctly.
Try different keywords.
Try more general keywords.
Try fewer keywords..........

Where can I find a 10 bit HPWM command?

Cheers
BrianT

Darrel Taylor
- 8th January 2008, 02:27
I'd like to be able to explain the search engines..... but I can't. :(

Good thing there's People around. :)

37805
<br>

Charles Linquis
- 8th January 2008, 02:44
The code that I posted does a 10bit HPWM.

Darrel Taylor
- 8th January 2008, 02:51
The code that I posted does a 10bit HPWM.

Glitch Free to 500khz ?

Yeah, mine neither. :)
<br>

Charles Linquis
- 8th January 2008, 05:07
A PIC can't do 10 bit PWM to 500Khz, since it would need a counter running at 500KHz * 1024 = 512MHz.

Darrel Taylor
- 8th January 2008, 05:24
A PIC can't do 10 bit PWM to 500Khz, since it would need a counter running at 500KHz * 1024 = 512MHz.

Absolutely Correct!
As the frequency increases, the resolution decreases.

Follow that all the way to the highest frequency, and with OSC=16, you should have 2mhz PWM at 1-bit resolution (essentially on or off).

@ 500 khz, you should have 4-bits. And if all you ever want is 50% dutycycle, then it's a piece of cake.
<br>

BrianT
- 8th January 2008, 08:52
Hi Darrel & Charles.

I need 50% duty cycle at 32767 Hz on CCP2 to drive an Intersema pressure sensor - easy - even I can do that with 8 bit HPWM.

I also need a variable duty cycle to drive an AGC circuit. With 8 bit HPWM, my AGC is sudden death and one count goes from not quite enough to a little bit too much. 10 bit HPWM would be much less sensitive. The frequency must stay at 32767 Hz to suit the Intersema sensor.

Can I get 10 bit HPWM at 32767 Hz?

Cheers
Brian

Darrel Taylor
- 8th January 2008, 09:49
As long as your OSC is 20 or more, then Yes.
@ 4mhz OSC you only get 8-bit resolution with that freq.

HPWM10 should work fine with it.
<br>

duncan303
- 8th January 2008, 11:56
Thanks everyone,

I have had to be away for a couple of days, I did have to manipulate and condition the frequency values several times to obtain suitable results from the DIV32 operation, to provide a usable value for PR2.

But it is very messy, maybe now not so bad after all.

will follow up when I am back

I should also try again to get PBL to compile, from memory I could not immediately find any solution to the error codes and did not wish to be sidetracked, considering LONGS was one of the features that prompted me to upgrade I should review.


Thanks again

Duncan

duncan303
- 11th January 2008, 17:53
Hi Back again

I have changed from 16F648A to a 18F1320 to allow the use of PBPL, the pin allocations are different for the CCP and the USUART but that is now sorted.

I am looking now at Darrel Taylor’s macro HPWM10, there are two uses of DIV32 the first calculating the value of PR2. The DIV32 multiply is within the PR2 ASM routine

With Darrels' permission.. could the next lines be something like?

HP_Long = (resultant of Multiplication) / HP_Freq
HP_Temp = HP_Long.WORD0

in which R register does the resultant reside?
or remove the PR2 ASM altogether and just use PBPL.


and the second use of DIV32 for the CCP section

HP_Long = HP_Temp * HP_Duty
HP_Long = HP_Long / 1023
HP_Duty = HP_Long.WORD0

long winded and compiles into 1624

I would very much wish to contribute but I find it very difficult when there are so many people who know soooooo much more than I.

Thanks also for the help Charles, I do not have any PICs hooked up to a 108 type keyboard, I presume that it is easier on is the older type rather than the newer PS2 type. Actually I have a couple of old magnetic swipe card readers and some old keyboard inline barcode readers as well in the same box, trouble is I could not begin to remember where the box might be :(

I am also reminded that I used to know all the barcode symbologies once.......... now I regret all gone................ come to think of it quite glad really. maybe it made space for something more exciting :)


Duncan

Charles Linquis
- 11th January 2008, 18:38
Actually,

My code does not connect directly to a keyboard. It receives data from the PICs serial port which is connected to a PC. The PC is running HyperTerm or TerraTerm. When you press the "UP" and "DOWN" arrow on a PC keyboard, HyperTerm actually sends out 3 ASCII characters (the first one being an <ESC>).

So, on a HyperTerm session, when the program starts, the PIC asks what frequency you want the PWM to be -
312Khz,156Khz,78Khz or 39Khz. It uses a table to set PR2 to the correct value, and then writes the desired PWM Value into CCPR1L and CCP1CON. You increment or decrement the
PWM value by pressing the UP and DOWN arrow keys.

duncan303
- 11th January 2008, 19:26
Hi Charles,

Having had a much closer look I can see how you have used CASE to determine the BIT resolution across the four fixed frequencies, and the use to be able to vary the duty cycle across as much of the range as possible.

it should be fairly easy to adapt this to operate on an PIC (possibly with an LCD) and six buttons(or less) . It is handy, and I am glad you posted it.
I am at the moment working on varying frequencies with fixed duty cycle dependant on resolution, but I do note your use of CASE. The IF...GOSUB can be very compile hungry.

Thankyou for your help

Duncan

Charles Linquis
- 11th January 2008, 20:09
This is part of a test program I wrote that writes/reads any pin - analog, digital, PWM, etc.

Since it was written for an 18F8722, the fact that it took up quite a few code words made very little difference.

Darrel Taylor
- 11th January 2008, 21:41
Duncan,

Now that you are using PBPL, things get very easy.

PBPL does not have the 32767 upper limit like PBPW.
The resolution is only 8-bit max. But you don't need resolution, just frequency @~50% duty.
And, it's not glitch free, but if you only change the frequency when you need to, it shouldn't be a problem.


Freq VAR LONG

Freq = 500000

HPWM 1, 127, Freq

Should do it. I think.
<br>

duncan303
- 19th January 2008, 12:30
Thanks Darrel for directing me back away from HWPM10.

Unfortunately using PBP’s HWPM even with LONG has noticeable inconsistencies across the range I am interested in,exactly as you suggested, so I have gone back to calculating PR2 myself, which is so much easier without DIV32.
I have also chosen to make use of the listing file which I have set to create at compile time, from which I hope to learn more how PBP creates assembly, as it is made so much easier by the explanation comments.



I would like to add some personal observations concerning another post today elsewhere on the forum.

Earlier in this thread I asked permission to alter code created by others for my own use. I personally do not feel comfortable cutting and pasting other peoples routines into code, I always know it is there, especially if I know I could never have written it myself.

This is a complex forum with diverse users and some big contributors are understandably feeling that they are being taken advantage of. I do not doubt for one minute that this is not true, as I believe that there are strong commercial undercurrents in the mix.

A little while ago this forum was down for a day or so, I can remember staring at the screen like a frightened rabbit……………perhaps if I had actually joined in…………….so I have started to post.

Anyway guys and gals please don’t stop helping, in whatever frame of mind. I have actually found some of the recent interchanges very funny, and on behalf of those a bit timid to post...
thank you all collectively again.

Perhaps I can help out a little by referring to our old friend the DATASHEET and in particular Section 26.0 Emotional Characteristics, paying special attention to page 232 ABSOLUTE MAXIMUM RATINGS. :D

HTH

Duncan