problem with chip speed after flowcode update

[chevy6600]

Hi all, it has been a while since i was here, been busy doing other things. But i recently took up my project again and found out that there was an upgrade to flowcode to ver.3.4.7.48 so i did the update then went on holiday. When i got back i began to do various alterations to my program and when i tested it using proteus i found out that the pwm signal (which is pwm as used in radio control) was far too long, 129mhz.
Now before i did the update and the few minor modes i did in my program the pwm was around the 12mhz if i remember correctly. Each channel was the correct size of 1 to 2mhz but now is around the 9mhz. i have tried all sorts of things thinking it was my program causing the slowing pwm, but i have just tried an old test program i did at the beginning of my project which i know worked back then, and when flowcode recompiled and tested with proteus it too was 129mhz pwm. So i now suspect that it must have something to do with the update, so can you please have a look at my prog, and explain what can be done to rectify this.
i am at my wits end trying different things, so much so, that i no longer can give a list of what i have tried.
Note that i am using a pic 18f2620 set up with a vref. I have found that the only thing that alters the chip speed is to select "HS-PLL enabled freq=4xFosc1" in the configuration settings, which will only double the speed, and i need about 10 times the speed. Selecting different "chip speeds" from the menu does not alter any thing.

[Benj]

Hi Chevy

Good to see you back,

I dont quite understand what you mean by PWMs of 129mhz and 12mhz. The PWM running flat out with a 19.6608MHz clock could only run at a possible speed of 1.6MHz and thats only if you have a period register set to 2. Not very useful.

Have you tried the HS oscillator setting in the expert chip configuration?
What crystal speed are you using?
What speed of PWM should you be expecting?

Also please could you attach your custom FCD file so I can open your program.

[chevy6600]

Hi benj, to make things a bit more understandable ignore the attachment i gave in the post above, i have attached a pwm prog that sean had put together in helping me with this post http://www.matrixmultimedia.com/mmforum ... a&start=25
It is a lot easier to follow his prog than to understand my prog (i`m having trouble following my own prog Ha!), i have the same problem with a slow pwm signal with sean`s prog.

The following prog "multiservo2_Fx620.fcf " ....which uses the pic 18F2620....i have compiled using the setting in the chip "configuration" setup, using the setting " INT RC-Port on RA6,Port on RA7 ", i then took a screen grab of the proteus oscilloscope showing the pwm signal, as per jpg file ` 1proteus oscilloscope reading `. There are no inputs to the chip causing the length of signal.
The signal consists of 8 channels, each channel should be between 1ms and 2ms to be used in radio control purposes, channels 1 to 4 are only shown on the oscilloscope because proteus only has 4 signal oscilloscope inputs, the big blank area between the channels on the oscilloscope are where the channels 5 to 8 would be if they were included on the oscilloscope.
The yellow channel having a width of 13ms is about 10 times too much.
From the yellow channel to the next yellow channel, being one complete cycle should not really alter, as you can see that the width of this is 158.95ms, which again is about 10 times too much.
Next, i changed the " configuration " setup using the setting " HS-PLL enabled freq=4xFosc1 ", i again took a screen grab of proteus oscilloscope, as per jpg file ` 2 proteus oscilloscope reading `. You can see that the width of the yellow channel is now 6ms and the width of one complete cycle to the next yellow channel is now 79ms.
I do not know what the implication is but it is the only thing that i can change in the chip configuration setup that has any effect on the pwm speed/channel width.
I am trying to setup the 18F2620 with internal clock/oscilator running at max speed possible. So i suspect that for some reason the chip is not running very fast.

Note that sean`s prog requires the file ` curve_data.h ` to be able to run.

I do not think that the ` HS ` setting is correct for using an internal clock, though i did try it and it shows the width of the yellow channel as 488ms, i guess it is a setting for an external oscillator.

I have just found out that i can only attach 3 files so i have added the next post to contain the other 2 attachments .
thanks

[chevy6600]

This post contains the other 2 attachments for the above post, these are the proteus oscillator screen grabs.

[Sean]

I compiled the program using the latest version of Flowcode and can confirm that thwe servo timers are running 8 times slower than expected.

When I checked the program I found that I had missed one of the steps required in converting from the original 16F877a version to the 18F4620/18F2620 version, and I have solved the problem. But now i can't explain why it seemed to work correctly with the older version of Flowcode!

The original program, running on an 877a at 19.6608MHz, was written in a way that only used small cout values, the simplest maths functions (addition, bit shifting, etc.) and a timer prescaler of 8:1. For the 2620 version, running at 32MHz, I decided to use larger count values, an advanced maths function (multiplication), but did not remove the timer prescaler - the reason why the timers appear to be running slowly.

Both the CCP1 isr and CCP2 isr Enable Code sections contain the line t1con = 0x31. Change these to t1con = 0x01. This will remove the 8:1 prescaler from the timer clock source and restore the correct servo timings.

The reason for using large count values and a multiplication (x48), in the pulse width calculation in the CCP1_isr macro, is to allow the pulse range to be adjusted if required. With a starting value of 48, the range can be increased or decreased in steps of approximately 2%.

[chevy6600]

Good Afternoon sean, i appreciate the you looking into this so quickly for me. I also thank you for explaining the smaller details on why, as although i may not fully grasp the reasons in full at the moment , i am interested in how and why things are done, it also helps me learn about the ` wider picture ` as it were, and as time goes on i can better understand these things.
just as a matter of interest is this `query` only of interest to this particular program code ie. just a maths function in the program code. or should i need to bear it in mind when changing from one chip to another chip? ie. a quirk of flowcode, as you pointed out that it worked in the old flowcode and not in the new flowcode.

I was up last night until the early hours of the morning with my program and i found out about a few things of interest to me, and i would be interested in you commenting on them.

A) When you helped earlier this year on this program you suggested i setup the osccon = 0x70, and looking at the pic chip data file i think i should use osccon = 0x72 if i was to use the internal oscillator running at the required 32mhz. Can you confirm this please? as changing it to 0x72 does not seem to make any difference.

B) I eventually found some thing that i could change the speed of the signal , i made changes to the
ccpr1h = 0x07 and the ccpr1l = 0x20 and i was unsure that although the signal was now ok, would the pic 18F2620 be running at 32mhz ?. I guess from your explanation you gave above what i had done was to bring the maths back in line, in a round about fashion.

C) I want to have a +vref of 3v which i can sort out, but from what i have gathered from various posts, i may need to have the -neg side or earth, not at vss but at its own -vin pin ? and is this the -vref pin.?

D) I need to have my `sensor` to span from 2v to 3v in 255 (or so) steps. As i understand it, i need to input this lower side of 2v into -vref. is this correct? and if so is it the `adcon1 = 0x?? .
Thanks for any help you can give.

[Sean]

I have tried to write these programs in such a way that the hardware does most of the work, and the calculations are kept to the minimum amount of simple, integer operations and bit manipulations. In the original 877a version, running at 19.6608MHz, the timing values were derived very easily from the timer1 clock, prescaler and simple calculations.
Unfortunately, being so dependent on the hardware meant there was little scope for variation, so the 32MHz 2620 could not work in exactly the same way .

32MHz / 19.6608MHz = 1.6276, which is not an easy scaling factor to achieve with integer maths. If the 2620 was run at 40MHz the scaling factor would have been approximately 2, which would have been easily achieved by shifting all timer values one bit to the left.

Due to the higher speed of the 2620 I included a multiplication operation in the pulse width calculation, to act as a more flexible scaling factor, and to make all the timer values as large as possible (by removing the prescaler) to increase the resolution of any scaling factor adjustments.

It should be possible to convert this program to run on most devices, at a range of clock frequencies, by scaling the values sent to ccp1 and ccp2 by the ratio of their clock frequency to 32MHz.

A
OSCCON = 0x72 selects the internal oscillator directy. I think this would bypass the pll, so you would only achieve 8MHz.
OSCCON = 0x70 selects the primary oscillator, which has been set as the internal oscillator by the config options, and includes the pll option.

B
An option would have been to keep the 8:1 prescaler, change ccp1h to 0x09, ccp1l to 0xc4, and change the mltiplier from 48 to 6. In this case, if you had wanted to adjust the pulse range, nearest options would have been multipliers of 5 or 7 (17% change). With an initial multiplier of 48, selection of 47 or 49 represents a minimum change of only 2%.

C and D
There are limits to the absolute and differential voltages that can be applied to Vref+ and Vref- (check the data sheet). It might be better to keep Vref- as Vss, supply 3v to Vref+, sample the A/D with 10-bit resolution, remove the 2v offset mathematically (subtract approximately 682), and scale the result (0 to 341) to represent 0 to 255 ( multiply by 3 then divide by 4).

[chevy6600]

Thanks for the info sean, it will keep me busy for the weekend.
Have a good weekend.