Timing problems pic16f887

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 7.

Moderator: Benj

Post Reply
kjstech2
Posts: 6
Joined: Thu May 24, 2018 9:06 pm
Has thanked: 3 times
Contact:

Timing problems pic16f887

Post by kjstech2 »

Hi I'm new to V7, having used V5 some 3 years ago to programme the pic16f887 for a battery powered navigational beacon. We've decided to drop from the original 4Mhz external timing crystal to a 32.768 KHz crystal as this reduced the quiescent current from 2.5mA to under 1mA. Having just copied the original V5 project across to V7 & set the project/configure options to LP mode & 32768Hz, we are not getting the required timings - a programmed 2 second delay/flash is actually giving us 3.8 seconds, so the whole chip seems to be running at just over half speed.
We are using saving the c/hex file in V7 & importing into MPLAB IDE V4.15, using a Pickit 3 to download to the chip, having ditched our purpose build PCB in favour of Pickit 44 pin demo board to eliminate any PCB errors. Scope confirms crystal is running at the correct frequency.
I'm sure there's going to be a option I've not selected/changed somewhere, but has anyone any ideas?

kjstech2
Posts: 6
Joined: Thu May 24, 2018 9:06 pm
Has thanked: 3 times
Contact:

Re: Timing problems pic16f887

Post by kjstech2 »

OK, I've gone back to basics, with a new 44 pin demo board, new 32.768Khz oscillator, I have just created a new simple programme to flash an LED on/off with 1 second delays. all works fine with the simulator, but actually flashes a 2 second cycle at 3.68 seconds. Can anyone help? Am I looking at a V7 software glitch?? - the pull down menu for the frequency offers 3276800 hz, which doesn't match any crystal I've come across so I'm beginning to wonder if there's something amiss here!

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Timing problems pic16f887

Post by Benj »

Hello,

Please can you post your program or a simple program that exhibits the problem and we will look into it for you.

kjstech2
Posts: 6
Joined: Thu May 24, 2018 9:06 pm
Has thanked: 3 times
Contact:

Re: Timing problems pic16f887

Post by kjstech2 »

Many thanks for taking the time for us - most appreciated, a screen shot is attached for now - what's the best way to post the programme?
Attachments
Screenshot 2018-06-01 12.24.35.png
(180.56 KiB) Downloaded 2587 times

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Timing problems pic16f887

Post by Benj »

Hello,

Please can you post your project .fcfx project file via the attachments tab below the posting window, screenshot doesn't provide all the detail we need to look at to determine the cause.

kjstech2
Posts: 6
Joined: Thu May 24, 2018 9:06 pm
Has thanked: 3 times
Contact:

Re: Timing problems pic16f887

Post by kjstech2 »

Appreciate that, I just didn't know which file to attach!

Flasherldf3 is the main programme, flowcode1 is the test programme.

Many thanks
Attachments
flasherldf3p.fcfx
(59.29 KiB) Downloaded 216 times
Flowcode1.fcfx
(7.69 KiB) Downloaded 197 times

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Timing problems pic16f887

Post by Benj »

Hello,

I can't see anything specifically wrong with your program, the clock speed and config settings all look fine.

I've changed the program to use the INTOSC instead so you can do away with the crystal. Can you see how you get on with this and let us know.
PIC16F887_INTOSC.fcfx
(8.54 KiB) Downloaded 216 times

kjstech2
Posts: 6
Joined: Thu May 24, 2018 9:06 pm
Has thanked: 3 times
Contact:

Re: Timing problems pic16f887

Post by kjstech2 »

Hi, thanks for keeping going with this one!

Now I know how to set the intosc - thanks to the forum pointing me in the direction of the intosc helper tool! I've tried the 1on 1off programme at various frequencies, with the cycle time as follows:
31000hz = 4.03s
125000 hz = 2.44s
1000000hz = 2.06s
4000000hz = 2.01s
8000000hz = 2.01s

My timer only goes to two decimal points, with the readings taken after 1 cycle, they do creep up if left to run.

Any thoughts on what's going on? Are looking at losses due to time taken to excecute code? does flowcode allow for this when calculating delays?

Many thanks Kerry C.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Timing problems pic16f887

Post by Benj »

Hi Kerry,

Yes that sounds right to me, the delay calculations simply count how many instructions are required to achieve the delay period, no other surrounding code is taken into account. This would be really nice but is very tricky to do well even with purpose made hand written code.

You also likely have the Free XC8 compiler which is known to add extra instructions which may be also having a bigger impact at the slower clock speeds. You could try the free 60-day trial of the pro XC8 compiler from Microchip to see if this makes a significant difference.

hackinblack
Posts: 26
Joined: Mon Apr 17, 2017 9:55 pm
Has thanked: 2 times
Been thanked: 14 times
Contact:

Re: Timing problems pic16f887

Post by hackinblack »

the 32,768xxx is a standard 'wrist-watch' timing xtal; maybe the drop down just replaces the least significant digits with zeros (to make it easier to read?)
The reason for using these xtals is they can be divided down to achieve exactly 1hz ticks (hence the 'watch' tag..)
with the PIC family 32,768Hz divided by 4 (the actual speed of the 'sytem' clock) = 8,192Hz , using a prescaler of /256 to give 32Hz ticks,which when counted 32 times, give 1 second 'ticks'.about.
However the intenal clocks on some PICs are just slightly 'off' as far as generating exact frequencies;there accuracy is quite poor,and the error is cumulative; each time round the loop causes more 'drift'.only a fraction of a percent can change a 24Hr time by 14 minutes...expect a lot of 'trial and error'!!
Frequency drift caused by temperature, chip variations, and power supply voltage all add ther tuppence worth too!
All this is compounded by the free version of XC-8 adding redundant code to the loops before converting it to hex; and as its built into the XC-8 compiler (in FREE mode only) working round it isn't an option;if you get code that is exactly right...frame it! 8)
As a point of interest, i did some code for a PIC 10F200 to toggle the pins, at different frequencies, depending on which button was pressed...it managed to do it with 0.1% accuracy! on its internal osc...
Attachments
2trickPony.PNG
(145.88 KiB) Downloaded 2405 times

kjstech2
Posts: 6
Joined: Thu May 24, 2018 9:06 pm
Has thanked: 3 times
Contact:

Re: Timing problems pic16f887

Post by kjstech2 »

Many thanks for all your input into this, as a relative novice it's very much appreciated.

For further info, having downloaded the trail xc8 pro & built to hex using it (it took a while to get V7 running again, as soon as I tried to change the path in compiler options this just caused flowcode to feeeze & had to re-boot the computer to get anything working again! I had to overwrite everything in the complier directory in the end) The resultant memory usage went down from 86% to 28% & timing error from 201% to 171%!

At least I now know where to go with this - it's going to be a case of calibrating & adjusting each delay interval, time to fork out on a frequency/period meter!

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Timing problems pic16f887

Post by Benj »

A timer interrupt might be a better way to produce a known regular timing and maybe avoid having to mess around with delays.

Post Reply