Electronic – Use PIC internal oscillator

As others have said, accurate frequency and frequency stability are reasons to use a external ceramic resonator or crystal. A resonator is several times more accurate than the internal R-C oscillator and good enough for UART communication. A crystal is much more accurate, and necessary if you are doing some other types of communication like CAN, USB, or ethernet.

Another reason for a external crystal is choice of frequency. Crystals come in a wide range of frequencies whereas the internal oscillator is usually one frequency with maybe a choice of 4x PLL enabled. Some newer 24 bit core PICs have both a multiplier and divider in the clock chain so you can hit a wide choice of frequencies from the single internal oscillator frequency.

There are of course various applications that inherently require accurate frequency or timing other than communications. Time is the property in electronics that we can measure most accurately cheaply, so sometimes the problem is transformed into one of measuring time or producing pulses with accurate timing.

Then there are applications which require some long term synchronization with other blocks. A 1% oscillator would be off by over 14 minutes per day if used as the basis for a real time clock. Accurate long term time may also be needed without having to know real time. For example, suppose you want a bunch of low power devices to wake up once every hour to exchange data for a few seconds and then go back to sleep. A 50ppm crystal (very easy to get) will be off no more than 180ms in a hour. A 1% R-C oscillator could be off by 36 seconds though. That would add significant on-time and therefore power requirements to the devices that only needed to communicate for a couple of seconds every hour.

This is some pretty old advice, and I don't know if it will be relevant for your micro, but about 4 years ago I did a project with a PIC18F which encountered strange spurious resets. After reading the report and re-jogging my memory here is what seems to have solved it:

Do you have the Low Voltage Programming Enable configuration bit enabled? Is your PGM pin on PORTB? If so, you may want to consider disabling both Low Voltage Programming Enable and Port B A/D Enable to digital inputs on reset. According to my old report, what was happening was we left PORTB floating while they were analog inputs and triggered the PGM pin. Looking back I don't know if this diagnosis was correct, but we did end up finishing that project successfully so it may be worth a shot.