question about using two microcontrollers in the same circuit...

[maark6000]

I have an application that I'm thinking will require two PIC microcontrollers. For the first µC, it is important that it work every time, it's clocked at 4 MHz and is a timing sensitive device. The next µC is not as important... it will be updating an LCD screen, which obviously moves a lot slower. The question I have is I've noticed weird issues when I've hooked two circuits that both had external (Crystal / cap) oscillators together. What is the proper protocol for designing a circuit that will have two µCs, both externally clocked? Should I use one external crystal & caps to clock both units?

Thanks!

 

[bigdogguru]

I have an application that I'm thinking will require two PIC microcontrollers. For the first µC, it is important that it work every time, it's clocked at 4 MHz and is a timing sensitive device. The next µC is not as important... it will be updating an LCD screen, which obviously moves a lot slower.

Typically, for a successful design, all sections must function properly and reliably. If it is not important for the PIC driving the LCD screen to function or perform its required tasks reliably, why include it in the design in the first place?

The question I have is I've noticed weird issues when I've hooked two circuits that both had external (Crystal / cap) oscillators together. What is the proper protocol for designing a circuit that will have two µCs, both externally clocked? Should I use one external crystal & caps to clock both units?

Can you elaborate on the specifics of your design application and its components?

What are the specific PIC microcontrollers you are considering for your design? What is the specific LCD that you are considering for your design?

And what is this "sensitive" device to which you are referring?

You might want to consider employing a more advanced PIC with can then perform all the required tasks of your design application. While there are certainly exceptions to the guideline, from an economical standpoint, it is often advantageous to employ a single microcontroller, rather than divide the tasks amongst two microcontrollers.

However, after reevaluating your design application, if employing two separate microcontrollers still makes sense, then are are some commonly used techniques often utilized to sync the two microcontrollers to a single clock source.

1. Utilize an oscillator for the required clock source which can then drive both microcontrollers.

2. Some devices can be configured to utilize a crystal to generate its clock and then pass this clock signal to another microcontroller.

3. Time critical sections of code can sometimes be synced by the use of signally lines emanating from the master device, which then trigger the interrupt in a slave device, essentially syncing the execution of certain time critical code sections.

There are of course other scenarios, however without further details, by answering the questions above, it's difficult to make any specific recommendations.


BigDog

 

[maark6000]

The timing sensitive device reads serial MIDI words (9600 baud) and outputs an 8 bit "note" value, it also has to filter out a ton of other possible MIDI commands which are not supported in the software I wrote (because I don't need them). I would also like this note value to be displayed on the LCD (a small 2x8 would do), but as you can play MIDI notes faster than the LCD can update, yes... it will be sloppy, not every note value that shows up on the output ports will make it to the LCD screen... that's fine... the LCD screen is more for diagnostic purposes when you simply need to know what value you're playing or what value the µC thinks you're playing. I'm sure one could write code for a faster device that could both do the timing hoop-jumping that is necessary to receive and filter the MIDI signal and still send the necessary info out to the LCD screen, but for this purpose, and in my mind at least, it would seem easier to just have one µC do the one task (for which I've already written, debugged, and tested the code), and have the other µC do the LCD portion with it's own set of clunky timing delays. As far as chips, I wrote the original code for a PIC16F84A because I wanted the challenge of programming for that chip in its somewhat cramped quarters, but going forward I would probably update the code to work in a PIC16F628. As far as the LCD chip, I would go as small as I can... I'd probably use a CMOS parallel to serial chip to cut down the pins needed to receive the 8-bit note value, and then whatever I would need to drive the LCD...