Dual core… Arduino?

[John Ryan] posted his dual core Arduino rig on the Arduino forums. These two ATMega168 chips share the same 16Mhz resonator and I2C bus – allowing them to run in semi-parallel. The uC’s don’t actually communicate with each other, but they run rather nicely as concurrent circuits. It’s a pretty interesting method of adding I/O pins to a project for a minimal cost.

Post navigation

11 thoughts on “Dual core… Arduino?”

He wired the chips in parallel – this doesn’t seem to be a good idea. Resonators are usually driven by a not gate – one pin is an input, the other is an output. It’s wired so that the two outputs are driving each other — bad practice! This will waste energy and stress the parts. It’ll also create a lot of electrical noise as the power supply is repeatedly asked to supply the short circuit current every oscillation.

The better solution is a master/slave setup. One device will control the oscillator (connect XTAL1 and XTAL2 as usual) – this is the master. The other device is set up in “external oscillator” mode, with its input driven from the first. I looked at the spec sheet quickly, and it looks like XTAL2 is the output and XTAL1 is the input – this means you should connect XTAL2 of the master to XTAL1 of the slave. (you can verify this with an oscilliscope – the output waveform should be the squarer one)—On another note, I’ve thought it would be fun to take a 10 x 10 array of these tiny 100 MHz processors and make a 10GHz-equivalent computer on a 4×4″ pc board:

The dCore was conceived to add a “second” hardware serial, not just I/O pins because (yes) a 595 is one of a number of simpler solutions.

Back in 08, the 168’s were the only Arduino compatible processor severely limited by its “single” USART. The Software serial library also took another year of developing before it became a viable alternative. This hardware solution is still by far the best and cheapest solution for increasing the number of USART’s for your (hobby) electronics project.

Dual USART is accomplished using a switch between both processors allowing either chip to be selected for programming. The two chips then communicate using the wire library, and the board I designed and manufactured has the i2c lines etched in with two inline 1.8k resistors. A sketch can be designed to run on one processor which utilizes both USART’s, or two sketches can be run that share USART device data.

@morcheeba

I had several dCore boards running for over a year (on and off, 7 days was initial constant trial period) and no problems with parts failing. Others that received boards reported no issues either, the processors remain syncronized and didn’t over-heat, cook, fry, cry, or burnout.

I also tested two RBBB’s and the power consumption was more or less the same as the single dCore.

So “if” your info is correct, then none of the characteristics you described presented themselves and that’s probably because the scale of the characteristics you described are inconsequential.

@Lupin

If it were as easy as joining two bulbs then I wouldn’t still be getting requests to this day from people asking for a copy of the sch and brd files. But it’s nice to minimize other people’s accomplishments, especially ones that are so conceptually simple that your kicking yourself for not having thought of it first.

Now I have a 328 version in production. That board will be shield compatible. The boards are for “my own use” as were the 168’s, and if someone has an issue with the concept then I suggest you invent your own better solution.