HPWM10 Frequency Updating

[duncan303]

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]

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]

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]

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]

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]

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]

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.

HTH

Duncan