problem with LCD + oscillator setup

[chevy6600]

Hi all, i have a problem with using the lcd on the ver3 development board. I am trying to run a 18F2620 at 32mhz int. oscillator, and getting different results on what is seen on the lcd dependant on the speed of the chip.
It appears that the choice of speed selected in the `expert setup` is not what you (me!) expects to happen.

Running a small test program which displays a few characters and increments a displayed No. which counts how many times the program cycles through. I have also got an `input` to zero the No. to be used on the ver3 dev board.
After 200 cycles the program ends, so i can then run and time the program choosing the different `chip speeds` and selecting different `expert setup`oscillator settings. Then timing the program until it ends. The results are attached . Incidently these results are from using the ver3 dev board not the flowcode program on the pc.
Q. why does choosing a FASTER chip speed result in a SLOWER running program.
Q. why does choosing the oscon fast setting setup for 32mhz internal oscillator, be SLOWER than the
HS setting.

Hoping that you can help me here as i am at my witts end . I need to be able to run the chip at 32mgz and run the LCD properly, it appears that the LCD will only run at its best at 10mhz...no more...if less i get corrupt data.
Q. Is it possible to run the LCD on the board at a different speed to the flowcode program
Q. How can i be sure i am getting the speed i thought i was setup for
I have not the use of an actual oscillascope.
Maybe you could put together a simple program for those of us that have a need, for us to run that you know that has a certain time span. It could then be used to make comparisons with.

[Steve]

Is it 32kHz, not 32MHz???

The selection of the clock speed must be consistent with the actual clock settings used in the hardware itself. The setting in Flowcode is used to ensure the delays used are accurate for the hardware clock. This is why a faster clock setting results in a slower program speed - you are telling Flowcode that the hardware is faster than it is in reality, so it makes the delays last longer.

The LCD module is sensitive to the clock speed, which is why it does not work when you use a different setting to the actual hardware. If your program does not work, play around with a simple LED flasher program to make sure the clock speed setting you are using is correct for your hardware first.

[chevy6600]

Hi steve, i am trying to run 32mhz (Not 32Khz) the 18F2620 uses a PLL multiplier to bump the speed up from the internal oscillator.

Am i right in thinking that the choice of the `clock speed ` setting has got to represent the crystal on the actual board ? and likewise in my case it has to be the same as the INTERNAL Oscillator?
bering in mind that there are more choices in the flowcode list than the chip has INTERNALLY.
In other words, the setting of the `chip speed` setting is NOT MY FINAL 32mhz `pic 18F2620 ` speed.
If i`m correct in the above i presume i have to set the `chip speed` setting by inputting 8mhz and use the oscon command as usual to activate the PLL multiplier in flowcode? and accept that whatever came out the other end was correct.

Can you comment on this please...good or bad.

Q. Is it possible to run the LCD on the board at a different speed to the flowcode program
Q. How can i be sure i am getting the speed i thought i was setup for
I have not the use of an actual oscillascope.
Maybe you could put together a simple program for those of us that have a need, for us to run that you know that has a certain time span. It could then be used to make comparisons with.

Thanks for your time.

[Steve]

You will probably have to set the osccon setting to the appropriate value - I've not used this chip so I don't know for sure, but other PICmicros work like this. You will also need to set the value in the "clock speed" window to the appropriate value.

So, if you want 32MHz, this is what you need to do:

1) Set the config to use the internal osc
2) Set osccon appropriately at the start of your program
3) Set the "clock speed" setting to the appropriate value (i.e. 32MHz)
4) compile and download your program

I must reiterate that need to set the clock speed within Flowcode to the value of your actual hardware (i.e. 32MHz in your case). If for whatever reason your hardware is not running at 32MHz, then your program will probably not run correctly. This is why I say to create a simpel LED flasher so you can confirm that the clock speed is working correctly.

[chevy6600]

O.K. steve. i have set the `chip setting` setting to 32mhz as this is to be my final speed of the chip.
i then sellected the `INT RC-Port on RA6` in the expert setting...i believe this is setting up the internal oscillator!. I then ran the program as is attached to my first post here and the program took 46 seconds to complete the 200 cycles at which it just stops.!! Surely the board should be doing more than 4.3 cycles a second??
I also noted that i was able to read the LCD ! which indicates that the board was running slow!
The board oscillator switches are set to `fast` and `xtal` incidently. I tried the other positions, not much difference.

[Steve]

And what happens when you create an LED flasher program? If the LED does not flash at the correct speed, then the setting within Flowcode is not correct for your hardware (which in your case probably means you have not initialised the internal oscillator correctly).

[chevy6600]

Hi again: Taking a step back and looking at the results i got (see attached `results`) and looking at the fastest speed i got which was 200 cycles in 1second, if i was to asume that this was the 32mhz ...it cannot go faster on the internal oscillator..the setup to get this speed was, 1mhz in the `chip setting` setup, and choosing the `HS` (Not HS-PLL) in the expert settings, both of these settings do not realy lend to anything that should be done! so i am at a loss realy, on what is going on.
I know that you mention putting together a flashing led but i still would not know what the correct speed of the flash should be!

[Steve]

I have looked at the doc and I don't understand exactly what is going on (nor do I really want to - I've got so much work on here you would not believe!). Also, I am not familiar with that chip.

The reason I keep banging on about an LED flasher is because is it a really easy way for you to determine if the hardware clock speed has been set correctly. Create a program such as the following:

loop forever
output 1 to B0
delay 1 second
output 0 to B0
delay 1 second
end loop

Set the clock speed to the value you think it should be (i.e. if you have set the internal osc up correctly at 32MHz, then put in 32000000) and download the program.

If the led's flash every second, then the hardware oscillator clock speed is correctly set to 32MHz. If the led's do not appear to flash (or flash very very slowly), then you know the hardware oscillator clock speed has not been set correctly and you need to work out why (e.g. is there a clock-changeover option you need to enable in the config word?).

The only thing that can go wrong with this led flasher is that the hardware oscillator clock speed has failed to be set to the value you intend.

Once you have found out how to correctly set the hardware oscillator, then you should work on the lcd program.

[chevy6600]

steve i`m sorry to of been a pest to you

I have looked at the doc and I don't understand exactly what is going on (nor do I really want to - I've got so much work on here you would not believe!). Also, I am not familiar with that chip.

i know from the past you have appeared to be posting all kinds of hours and i have appreciated the times you have answered my queries, i guessed that you could have quite a work load to cope with and because of this i do not post questions unless it is the last resort for me, i post a question after trawling the internet, reading the half dozen pic programing books, then sorting through the 393 pages of the microchip data manual specifically on the one 18F2620 chip, then often spending a number of days experimenting, it is only then that i would consider posting a question.
If i may, i would like to add that this situation of having to post questions in the hope that they may get answered is not my ideal situation either i would much prefer a proper instruction manual to work from. maybe you could pose the question to your management?

I did try a `flashing led` program just for completeness, though in my mined timing only delays is not as good as timing a mixture of coding running in a loop as per a real life situation.
I found one setting that appeared to be running with the correct 1sec intervals, out of the 10+ clock speed settings, and 12 expert settings for the oscillator = 120 choices to get through.! it was the 19.66mhz external crystal setting using the HS expert setting. I won`t go into all the details on all the options i went through to try and transpose that setting over to what i was trying to accomplish, i just can`t get the led to flash correctly using the other settings. I am also aware that various other options in the expert setup need to be disabled when using internal oscillator.
The other suggestions as

Set the clock speed to the value you think it should be (i.e. if you have set the internal osc up correctly at 32MHz, then put in 32000000) and download the program

i had already mentioned i had done in the previous posts.
This i already realise !

The only thing that can go wrong with this led flasher is that the hardware oscillator clock speed has failed to be set to the value you intend.

Well it is now 1:30 in the morning and i have just about drained all my patience trying to solve this and looks like i`ll have to think of a plan `B` in doing the project i hoped to do.
Unless anyone else on the forum can offer any suggestions (not directed to matrix, be good to recieve any input from others here in the forum as well) it looks like i have out grown flowcode already!

[Steve]

Sorry if I seemed a little short with you before - it's a very stressful time here at the moment...

At least we know what the issue is now - you have not configured the internal oscillator in the correct way. This is not an "outgrowing Flowcode" issue - you would have this problem in any language you are programming in.

I had a peek at the datasheet for the device and it looks non-trivial to set up a 32MHz internal clock. Can you please post the C code here that you are using to set the OSCCON and OSCTUNE registers. Also, please post your configuration data. Posting a simple flowcode program (plus the generated C file) should contain all of this info.

[Sean]

The expert setup screen for the PIC18F4620/2620 running at 32MHz from the internal oscillator and pll is in the original servo control topic on the forum

http://www.matrixmultimedia.com/mmforum ... ervo#p8164

The additional C code required in the Flowcode program is:

osccon = 0x70;
osctune = 0x40;

These settings have been tested in the time critical program 'MultiServo2_Fx620.fcf'

[chevy6600]

Hi steve/sean, thank you for taking another look at this problem of mine. looking at the `osccon=0x70` and
`osctune=0x40` made me think to have another look at my value i had for the osccon + osctune, sure enough i had got the osccon down as 0x72 but i had input it in binary as in `osccon = 0b01110010;` and not `osccon = 0b01110000;` thinking back, i had put the extra `1` in after reading the pic chip manual and as can be seen from the red ring on the attach picture that i believed i was doing the right thing choosing the internal oscillator!, but as sean has pointed out i should of selected the `00` for the `Primary oscillator`...well it just goes to show there is more to this programing lark than meets the eye.
So i have now run the test prog flashing a led on then off in one second intervals as per steve suggested, and it now runs in one second intervals, while being setup with 32mhz in the `clock speed` setup and the `expert setup` using the INT RC . So with much great relief i think i am back in business.
Steve, as it appears that it may be o.k. now, i have not attach programs, `C` code files etc. I trust this is in order, but if you still want me to , i will.
Thanks.

[Steve]

I'm really glad the problem has been fixed - no need to post any files.

[chevy6600]

Hi all, Steve i think you jumped the gun a bit there......i had the flashing led working.

Before i replied i thought i had better get my facts right and do some more testing, when i try to run a program as in the first post here, i do not get a correctly running program even though i have transposed the settings from the led flasher prog.
So i decided to start from scratch again, by using the HP488 development board together with a 18F2620 chip, your program `multiservo2_FX620 which was a fresh download from sean`s link.

Well the setup as above does not produce a PWM correctly for me and i have not altered ANYTHING at all.
i have a box of servo`s and all work o.k. tested by other means, but do not work even though i went the extra mile and connected the servo sig to the `C` port of which is a `D` connector on the HP488 board. The servo would not `hold` a position so it was not receiving a correct signal. Although i did run it through proteus,... i do not know how much faith you have with it.. but for what it is worth it reckoned that a complete pulse cycle (not width) was 159ms, this should be around 20ms!. The pulse width was just a glitch! could of been around .1us!
So i know you guys are really busy, and i can understand that not every thing you put together is tested...i ask this in the nicest way...did you test this program of yours in the same way as i have done in a real life situation?

I did then try a few things, i noted that your program, in the expert setup, there was a number of items that were not `deselected ` and reading the 18F2620 manual some of these selections may interfere with the chip speed, so i disabled pretty much every thing that was possible then selected 32mhz, and having the osccon + osctune as usual together with the `expert setup` as INT RC port....the only difference to the pulse as per proteus, was a longer pulse WIDTH of 18ms.. the pulse cycle was 159ms.

I then tried using your program on the HP488 board with the external xtal, so i deleted the flowcode macro containing the osccon+osctune, then changed the `chip speed` setting to 19.66...mhz (to match the board) then selected `expert setup` to have HS . I still could not get the servo to work. same result, a non position-holding servo.

Now way back when sean posted this program in the first place, i did have a problem then, but i believed at the time it was to do with the maths in working out the pulse width and i had come up with some of my own maths that appeared to work, all be it in proteus. But as i am having trouble with the chip speed maybe it was not the maths that needed changing at all, but changing some thing else instead.?
I guess i may have to accept this as a dead end as i can`t expect you guys to carry on just on my problems, i thought i would post this in case at some time you might think that "it fixed my problem so it should work for someone else" . I have to go away for a few days anyway so it will give me time to get any fresh idears/thoughts.
Thanks for you time any way.

[Sean]

I still have the hardware and software used to develop the 18F2620 servo code (using an 18F4620). It was fully tested before I posted the program and all the maths seemed to be ok. I should be able to re-test it over the next few days and let you know the results.

The fact that your pulse cycle is 160ms instead of 20ms (8 times longer) suggests that the program is running directly from the internal clock again, but with it set to 4MHz instead of 8MHz (i.e. OSCCON = 0x62). Alternatively the clock source for Timer 1 might be incorrectly selected.

[Sean]

Problem solved (I think).

The system clock was ok, but Timer 1 was being set up with the wrong prescaler value in the two interrupt enable codes, causing it to run 8 times slower than expected. This has now been corrected (t1con = 0x01). I have attached the new program MultiServo3_Fx620.fcf along with the external curve_data.h file.

MultiServo3_Fx620.fcf

(10.73 KiB) Downloaded 360 times

curve_data.h

(1.24 KiB) Downloaded 351 times

[chevy6600]

Hi sean, i`m afraid to say that changing the `t1con` is not going to help me as i had already altered this some months ago as per my program....http://www.matrixmultimedia.com/mmforum ... =26&t=4937.... changing the `t1con` was part of my alteration to the maths i did. I have had some success using the osccon 0x70 instead of osccon 0x72, and have managed to get a pulse on the proteus oscilloscope from the chip pin RA6, this pulse being the clock output, i believe this is also divided by 4, can you confirm that ?. So using the `clock setting` set to 32mhz, osccon 0x70, osctune 40, config H1 set to 0x09, i then get RA6 pin that outputs 1.1us for 10 clock pulses = .11us/clock pulse.
This setup running on the HP488 board now gets my servo to see a pulse, it now locks the servo up against it`s stop, from what i can deduce from it`s behaviour is that it seems as though this pwm pulse appears to be about twice as long as it should be, while proteus shows that it is correct, I am now thinking that proteus may be showing the pulse width half what it actually is and the only way to find out is for me to get a proper oscilloscope. So i am now looking to see what i can get as cheap as possible for a xmas present for my self.

Q. am i right in thinking the RA6 pin setup as above outputs the 32mhz divided by 4 = 8mhz?
Q. programs seem to run faster if i select a lower `clock setting` ie. 1mhz, the clock pulse width does not seem to alter though. steve explained that it was to do with changing delay times in the coding, can i run the programs at this fastest `1mhz` setting? even though i should be selecting 32mhz or will it cause problems ?
Q. i`m looking at oscilloscopes in the range of : 40mhz bandwidth, 200ms/s sampling rate. Any idea if these would suit my needs?

[Sean]

Can you post your current program with an explanation of what you are trying to do and what seems to be going wrong. I should be able to test the program on a V3 dev board using a PIC18F4620. If the program seems to run faster with a slower clock, there is obviously a problem!

[chevy6600]

Hi sean, i am using a test program to get the timing, it has no pwm signal code, it uses the osccon + osctune. The test program is the same as the one at the top of this thread which also has attached the results that i found with the setup as of that time using config H1 = C8.
here is attached the same program using config H1= 09 and only altering the `clock speed` to get the different results.
The program does 200 cycles then stops, it has the lcd connected. It has a button on the board `LA0` to zero the counting on the lcd but not as a flowcode macro.
i zero the count holding down the `LA0`, I press the reset button on the board, holding down the reset button (not the pin LA0!) then release button to run, and i time the flashing leds until they stop.
at `clock speed` setting 40mhz...program otherwise not altered.= 11 sec
at `clock speed` setting 20mhz...program otherwise not altered.= 5 sec
at `clock speed` setting 1mhz...program otherwise not altered.= 0.5 sec

[Sean]

I have tested your program and found everything to be working, or explainable.

The PIC chip was working correctly, as configured. The posted program configures operation at Fosc = 16MHz (OSCCON = 0x60). The corresponding clock signal on RA6 was approximately 4MHz (Fosc/4). The Flowcode clock speed setting was 20MHz?

Afrer modifying the OSCCON value to 0x70 (Fosc = 32MHz), and setting the Flowcode clockspeed value to 32MHz, the chip performed the 200 cycles in approximately 5s. The clock on RA6 was approximately 8MHz.

The reason that the execution time of this type of program can be changed significantly by changing the Flowcode clockspeed setting is that the LCD component contains several delay operations that are executed as predictable program loops. The compiler determines the number of loops that will provide the required delays a compilation time, based on the clockspeed parameter passed to it.

If the chip running at 32MHz requires 1000 loops to produce a 1ms delay, but you inform the compiler that it is being clocked at 16MHz, it will only program 500 loops and the delay will be halved to 500ms.

The test program spends most of its time in delay loops because of the number of LCD blocks being executed in each program loop, so the significance of the delay timing accuracy is far greater than the execution speed of the remainder of the code.

The delays in the LCD component (and others) are necessary to allow for the response times of some peripherals. Although some programs may appear to run faster with lower clock speed settings, the shortening of component delay may lead to unreliable operation (serial baud rates are also affected).

One of the best program to test the setup of a target device is still the 1s LED flasher.

If you are selecting an oscilloscope, its sampling rate must be a minimum of twice the highest signal frequency you want to measure, but preferably much higher.

[chevy6600]

Hi sean, thanks for explaining what was going on and clearing things up for me, i can now use this info with confidence and i`ll have a go at redoing my algorithm + maths to alter the pwm signal.
Thanks.

[chevy6600]

Hi all, i think i have inadvertently damaged my original 18F2620.fcd file while altering it to have a `vref` voltage setting, and while looking at my version and the original version the two appear to be totally different! they are both correct for the chip and i wonder if i have got a new version and an old version somehow. So just to be sure i have the correct one could you please post up here the current 18F2620.fcd version for me?
thanks.

[Benj]

Hi Chevvy

Here is the current version hot off the generator tool.

[chevy6600]

Thanks benj.