Advice on internal OSC and MCLR module of P16F887 please?

[fotios]

Hello
1) From those i have read in P16F887 manual - included the timing diagrams - it is mentioned that this device offers enough internal RESET (or MCLR) modes included and an extra MCLR internal module. So, the pin 1 MCLR can be allocated as an extra digital input (e.g. for connecting a switch) instead to be used as external MCLR input, like in the old PICs. I use in my current project a P16F887 configured as follows: POR=enabled, BOD=enabled and MCLR=internal. Up to now, i have not any problem during power-up. The program starts and runs correctly every time, without hang-ups. But i am not sure (as a novice in PIC) how much reliable are all these internal RESETS executed automatically from PIC, to place the device in the correct start point of program each time. In old MCUs, the external reset R-C circuit was indispensable providing some times a large RESET time. I know that PICs and other modern (Harvard architecture) MCUs are much faster, but i need the advice of an expertised member: Can I always to trust the internal RESET circuit of P16F887?
2) The internal oscillator of P16F887 it is factory calibrated and it has a +/-1% tolerance. That means, if i select a Fosc=4MHz then the actual osc. frequency will fluctuate between 3,96 and 4,04MHz. That means, a time variation between 0,247 to 0,252μsec approx. There are applications where this time variation is not important. There are some others, where it is important. For example, i have read somewhere in the lot of instruction manuals of Matrix Multimedia, that when we use a LCD display it is better to we use as well an external XTAL instead the internal oscillator of PIC. To be sincere, i tried in my project the use of the internal oscillator of P16F887, and the LCD display it seems to be work just fine in all instances. I have not listed an error. But i can not be sure for the reliability of the internal oscillator - in the pass of time, because i experimented only for 2 - 3 hours - so i need again the advice of an expertised member for this.
Thanks in advance.
Fotios

[Benj]

Hello Fotios,

1) I would always assume that some registers and ram locations etc are not automatically reset on an internal reset. Therefore if you are using any ininitialised variables then it may be worth say setting them to 0 or a know value at the start of your program. Most of the Flowcode code should help to control the device no matter what the current state of the registers so this should also get you out of a lot of problems. Maybe adding a watchdog functionality incase anything does go wrong would allow for extra stability just incase a bad reset creeps its way in and cases a glitch in the system.

2) The LCD code is timing critical but it is also tolerant within a certain percentage so internal oscillator fluctuations should not cause you any problems. Again this is due to the intended bulletproof nature of the code created by Flowcode. I strongly beleive you will not have any problems regarding this.

[fotios]

Thanks for the precious advices Ben.
Yes, I know this issue related with the registers and the RAM. Moreover, as is referred in the manual of P16F887, there are enough bits of system configuration registers that get unpredictable values after an internal or external MCLR. Indeed, the Flowcode generated code resolves these problems as you refer. In addition - to I feel safe - if I need some initial values for variables, I do use always some locations of the PIC eeprom to store the corresponding values. Then, in my program flow are included some instructions which direct these variables to loaded with the stored values in eeprom after each new start-up. I know that this procedure is relatively time-consuming, however my project does not has the need of a very fast executable code. You know probably that it is a RC5 remote control receiver in conjunction with a manually operated (via 6 buttons) control circuit for an audio pre-amplifier. In such an application, execution of the correct command (with other words the correct sequence of the flow of executable code) it is more important than the speed of command execution. Consequently, the main issue is after powering of PIC the program counter to be placed always in the address "0x00h" of program memory - either thru the POR or thru the MCLR function -in which is found the reset vector that indicates the right address from which it starts the main program execution.
For the watchdog function that you refer, to be sincere I have not tried it so far. I know that the WDT has a time-out of 18ms approximately and that supervises if the program counter runs continuously. If not, then WDT resets the device. I will try it, but I am reserved by some way (from my ignorance about PICs in practice) because a part of my program is the "Signal Edge" macro which developed from Sean for the RC5 decoding. In this macro is used the TMR0 overflow interrupt. In the datasheet of P16F887 is referred that a prescaler is shared between WDT and TMR0. I have not study so deeply the corresponding chapter of PIC manual up to now, and I fear for possible conflicts.
After your confirmation, i will use the internal oscillator of P16F887 because I need, if it is possible, all the 36 available pins of PIC as I/O.
I have one more question. In the begining, i did use of PortB IOC interrupt so i had connected the 6 push-button switches from RB1 to RB6. Later, i replaced the IOC interrupt with a "Loop Until ..." inside the main "Loop While 1" of program because i had conflicts either with the continuously generated TMR0 interrupt or the RB0 interrupt caused from the IR receiver. My program it runs now just fine, without errors. The issue is this: in the manual of P16F887 is referred that only the RB3,5,6,7 pins have Schmitt-Trigger inputs instead RB1,2,4 not. Do you think that the 3 switches connected in these pins can cause glitches? In the active circuit, i have not noticed a such problem but i am reserved. I have draw my PCB already, but i can make some modifications like to move the LCD in PortB and the 6 switches in PortC which of all pins have Schmitt-Trigger inputs. Can you give me an advice on this please?
Thanks a lot again
Fotios

[Benj]

Hello,

I think that if you are simply using switches on the input pins then you should not have a problem. The schmitt-trigger simply means that if the voltage is between states then the current input value is retained. With a switch you are only ever momentarily in between states so this should never really cause any problems. If you are worried about this then simply take two or more readings with a small delay in between and then compare the results. If they match then you know you have a stable reading.

Hope this helps.

[fotios]

Thanks for the advice Ben.
I hope to i not became tiring with my repeated questions. Yes, you are right about schmitt-trigger inputs. Without doubt, when a switch is pressed or released its contacts cause bounces because they rubbed together. By looking again today in the FlowChart of my project (you may know that after 2 weeks from the finish of project, i have forgot almost everything of what i did ) i saw that indeed there are delays in the reading of switch state due to the program structure; for this reason i don't have errors. So, no problem with a tiring redrawing of my PCB.
As for the WDT, it seems that i was right in my doubts. I tried today my project with WDT enabled, and the program never starts. Because i had problems as well with the PortB IOC, i can suppose that the TMR0 overflow interrupt can not co-exists with WDT and PortB IOC activated. If you take a look in "RC5_INT_3.fcf" of Sean, you could see that the prescaler is assigned from WDT to TMR0 module, exactly as is described in the P16F887 manual, chapter 5.1.3.
So, everything is OK!
Thanks again for the assistance to my effort in this difficult project.