I am thinking of a project with 2-3 ATMEGA328 chips tied in parallel with a single 16 MHz crystal for all.
The question is, will this work and will they all clock synchronously so that their output/input pins will track the same clock cycle??
Has anyone tried this?
RPCoyle:
The question is, will this work and will they all clock synchronously so that their output/input pins will track the same clock cycle??
No they won't clock synchronously in the manner you describe. There will be a phase delay associated with the trace lengths being slightly different. Also how the microprocessor comes out of RESET will vary how the code operates.
You can't hook the same crystal to three processors. To have them use the same clock you can re-program the fuses to use an external oscillator and then provide a clock signal to the correct input pin.
"To have them use the same clock you can re-program the fuses to use an external oscillator and then provide a clock signal to the correct input pin."
Which I have been trying to do quite unsuccessfully!
Finally ditched the effort and just used a crystal per chip.
I think running N-mcu's all with one external clock must work (provided all N-mcu's have got the same fuse settings). And all mcu's must do the same with a clock cycle precision (all events finish in a given clock cycle). The exception might be writing to internal EEPROM or using the watchdog timer (an RC oscillator) or mcu's with different die revisions. I cannot imagine the reason why they may not work synchronously. Mcu's are not the SDcards..
The another question is how to synchronise their operation (from the sw point of view)..
Using two crystals may lead to starting delays as each crystal starts differently (crystals are lazy, blocking capacitors differ in value) - so I would bet many thousands clock cycles difference is possible..
So I would suggest you to place a canned 16MHz oscillator on the board, connect to all mcus and try harder.. 
p.
You may try following experiment - take two 328ps, the same fuse settings, same hex, connect them piggy-back (pin on pin). And run your code - what happens?
OK, I got this working with two Unos:
The lower Uno has its low-fuse set to 0xBF, which sends the buffered clock signal to CLKO (pin 8 ).
The upper Uno has its low-fuse set to 0xE0, which configures it to receiving an external clock on XTAL1 (orange wire).
NB this does not work if you connect master-XTAL2 to slave-XTAL1 -- probably because the clock is programmed for a low-power crystal which generates a low-amplitude signal. If configured for a full-swing oscillator it may not be necessary to use CLKO (freeing up pin 8 ).
Apart from the low fuse both Unos are configured identically and run Optiboot v4.5. The two reset pins are wired together to ensure synchronised startup, although the start of the slave Uno is delayed for reasons I don't fully understand.
To check the relative clock stability I ran pulse generators on both Unos and monitored the output on an oscilloscope. For comparison I then re-separated the clocks and ran the same test.
Synchonised clocks, right after startup:
Synchonised clocks, after 10 minutes:
Un-synchonised clocks, right after startup:
Un-synchonised clocks, after 10 seconds:
Un-synchonised clocks, after 20 seconds:
Technically, getting the uC to work with other clock besides a crystal/resonator is possible.
Getting the fuses set to do it is not easy. Installing the normal bootloader via the IDE with those fuse settings takes away those problems.
@tim7: nice experiment!
There is 4ms delay, right? The delay probably comes from the Start-up time xx CK/ 14 CK + yy ms, try setting with lowest xx and 0ms.
You cannot drive one Uno from clkout of the second one, as the 328p needs above number of clocks to start and there is a question when the Uno actually enables the clkoutput. The lowest I can see is 6 CK/14 CK +0ms from external oscillator.
Take a canned oscillator and feed both Unos with the output from that oscillator. It would be good to have the xtal capacitors removed. Set both Unos with SAME fuses - ie C0h low fuse (External osc 6CK/14CK+0ms)..
Reset - of course both Unos have to be reset at the same time - this might not be easy if there are capacitors connected to reset..
I'll stick with crystals. Oscillators are not cheap
7x the price of 33 cent crystal.
I think I'll stick with CrossRoads. My idea was to have one chip monitoring all of the sensors and sending the info to the second chip that would process the data and do logging and control functions. Of course there will be two different programs running on each chip, so the hex aint going to be the same. Sounds like I can do this much, but can't expect an accurate timing sync between them.
There is 4ms delay, right? The delay probably comes from the Start-up time xx CK/ 14 CK + yy ms, try setting with lowest xx and 0ms.
does this mean that if the first thing you did in setup()on both boards was get the millis() that I would be max off by about 4Ms?
Pito, the resets were wired together (green wire) and in theory the delays were programmed to be the same 65ms + 16 clocks (1us). The initial 65ms corresponds to 8192 watchdog ticks (128kHz) and doesn't run off the 16MHz clock.
It turns out that the de-synchronisation is due to the error in the watchdog oscillator. One board consistently starts up 6% faster than the other, no matter how the main 16MHz clock is generated. Since optiboot uses the watchdog for its timing, even without a reset delay the sketches still get started at different times. The difference is 95ms for the pair of boards I tested.
It would still be possible to run synchronised software on two or more processors, but the bootloader would need to be modified (or eliminated), and some kind of external power-on reset circuitry would be needed.
RPCoyle:
does this mean that if the first thing you did in setup()on both boards was get the millis() that I would be max off by about 4Ms?
If the first thing you do is run millis(), the answer will always be zero. If you have two boards reset at the same time, one could start running 100ms or more before the other.
