There are advantages to using an external crystal oscillator module in a case like this and PIC18F MCUs are designed to accept such arrangements by driving one side of their crystal oscillator pins.
If both PIC18F devices are driven from the same source clock, there will be slight differences in skew between changes in their outputs and the processing of their inputs. But they will be close and there will be enough remaining margin between them to possibly be useful to you, elsewhere.
Running them on entirely separate crystal oscillators means that you know nothing at all about how their pins behave relative to each other; only that they will be roughly using similar timing. But if separate, then you aren't even sure they are exactly the same rate and they will almost certainly drift, relative to each other. There will some beat frequency energy. Whether or not it matters to EMC testing isn't something I can help with.
Using an external oscillator does put some longer lines for radiation, perhaps. And that may be a consideration for you. But you can probably arrange things to have similar trace lengths. So it may not be much worse.
The PIC18F devices, memory serving, can be driven through either of the clocking inputs. I say this because I am in possession of an internal Microchip memo I received a few decades ago where they discuss the details across about 5 pages of closely typed text. In general, Microchip tries to design their class-A inverter so that it runs "hot." This is to avoid after-sale calls from idiots who don't know how to design for a lower-powered class-A arrangement. It's better for them to over-power the inverter and live with the excess dissipation, than to power it for a well-crafted layout that they know far too few of their end-users will achieve and then receive all kinds of calls and angry yelling and screaming about how bad their chips are. So it just makes sense to over-power it and live with it.
But their MCU is chained to the XOUT (the output of their class-A inverter), of course. It turns out that if you drive the XOUT instead of the XIN, then the class-A inverter doesn't have an input signal (you can do a few things at XIN to help here) and it will reach a low power quiescent operating point and will NOT oscillate at all and will also not much load your external oscillator, too. (Since this class-A inverter can, at times, account for almost half of the total dissipation of an MCU, shutting it down can be a big win.) On the other hand, if you drive XIN, instead, then the class-A will do its job, burning oodles of power, and drive the XOUT and all the chained internals to the MCU (and you will pay a [usually significant] power penalty for that.)
So my recommendation, keeping in mind that you care about EMC too, is that you consider and test the idea of using an external oscillator, tied to the XOUT pins of your MCUs. Perhaps use a relatively high (not too high) impedance divider at the XIN input or else just try and leave it floating. Then examine the power consumption and make sure the two PIC18F devices still operate fine. Now, change things. Drive the XIN of the two devices and check the operation as well as the power consumption. If you have a way to look at the emitted radiation, do that as well for both cases. Then, finally, do all of the above but now with your first thoughts about using two different external crystals and associated capacitors and see.
In other words, use your imagination and test. See what works best for you. I don't think any of us can give you a "bright line" answer here. But it is not very hard to set things up and test these ideas. And since you are worried about EMC, this tells me that you have the project time and tools needed to do this properly before committing to a final design.
This isn't rocket science and it doesn't require a lot of work. I say that because there is really no excuse for not doing this testing. You just insert it into the planning schedule and execute on it. The output of this testing then feeds, trivially, the schematic editing (which can in any case proceed in parallel because the costs of an edit change based on the results are minor [so long as you didn't delay the testing so long that the schematic went to layout.]) Seriously, just do it. You'll not only have an answer for your case in short order, but a quantitative one with numbers making the decision well-documented and easy. Projects often include much, much more difficult and far less easy to resolve issues ahead. This one is a no-brainer.
Those are my thoughts off the top, for now.
You have added the following points:
- "There is no communication between two PICs on the board." But then you also added, "Based on the wireless activity, first PIC drives a few transistors and the second PIC would poll the status of these pins at about every 100 mS." Given the long time you mentioned for polling, I take this point and agree that it may not matter which way you go here. Except possibly for EMC reasoning.
- "The main reason for me to consider even a second PIC is to make use of more IO pins and divide the software overhead." Those are two different issues. There is a wide variety of options for the PIC18F family and if you are using the largest parts already and need more I/O, I can't fault the idea of using two.
- However, you say you are using the PIC18F46K20 and so your only real reason for going to two parts about your latter point; the one regarding software overhead. I would strongly suspect this is more about possessing a smaller set of software design tools in your programmer skillsets, than really about a need. Chances are, in that case, it's a matter of hiring someone who has more skillsets to apply. I've rarely met a case (only one time in 45 years) where that argument would be correct in 20/20 hindsight. In almost all cases it's possible, with the right design and with the right tools applied, to get the job done without two. It's like the difference between the abilities of two different carpenters; one who only knows a few tools and must solve every problem with those, and another who knows hundreds more tools and can develop excellent approaches to solving the same problem more efficiently and more cost-effectively because of their broader and deeper skillsets.
- Yes, I get the point about software changes at this stage in your game. You can't go to a larger part, supposedly, for these reasons. No, I don't buy the argument. Been there. But I'll leave it here and just say that I don't accept the point from you.
- I get the requirements to support 9600 bps (not baud, as that is a term with a different meaning.) That's just a matter of the available divisors in the MCU and the allowable error specifications for the 9600 bps communications. Easy to work out.
- I'm not at all considering the idea of an external RC oscillator. Instead, there are crystal modules (usually with 4 pins.) These come as cheap (but often excessive power consumption) devices, or as TXCO's with temperature stability (and excessive power consumption), or else something like the old Harris HA7210 low power oscillator IC (now probably obsolete.) To add even more, there are still some spread-spectrum oscillator chips available to those looking for a "quick fix" to their EMC troubles. So there are several approaches here. Again, creativity and imagination apply.
In the end, I think you are barking up the wrong tree. I think you need better embedded software programmers. Not a Rube Goldberg fix in hardware and two sets of software to maintain. But that's just me.
