next topic »

[on:]

Here's 2 ATMega168's sharing one 16mHz resonator, one reset switch, two 10k resistors, one 220ohm resistor, and two LED pilots.

Both chips were supplied with RBBB kits sold by The Modern Device Company http://www.moderndevice.com/RBBB.shtml.

I used a mini USB adapter and uploaded the LED blink test to both chips, and as Paul suspected, they are perfectly synchronized - I've tested numerous resets, and the start up blink sequence and blink demo on both, are identical.

I don't need synchronized chips, but I happen to have a use for 2 168's connected via i2C - not sure if anyone else does but it adds a lot of pins and a second serial buffer for an almost next to nothing outlay. This can be put together using 1 RBBB and a second chip with the boot loader installed, so that's quite inexpensive, so long as you've got got a mini USB adapter laying around

The video can be viewed here (it's scratchy but you'll get the idea)



Here's some pix too.

[Reply #1 on:]

That is awesome!

Now all we need is a couple of water colling systems and overclock the chips.

Seriously though, a great idea.

[Reply #2 on:]

That is awesome!

Now all we need is a couple of water colling systems and overclock the chips.

Seriously though, a great idea.

They've been running non stop for the past 4 days to see if anything "flaky" happens, the chips are cold to touch and both are in perfect synchronization.

I'm interested to know - why would a water cooling system be needed?

This hasn't been done before, so all input is welcome

[Reply #3 on:]

I think they were making a hilarious joke regarding PC overclocking culture inspired by the "Dual Core" name of this thread. Although, arguably it's more of a dual-socket device then dual-core.

Still a very cool project. I'm curious what more advanced applications clock sharing could be used for?

[Reply #4 on:]

Ah yes, we use mainly mac's here but now have vague recollections now of the old 150's being cranked up to 166? - that would have been over a decade ago?

And yip, it's a dual 168 / dual chip / dual IC / dual socket, but we're going to call it our "Dual Core 168" because it sounds cooler.

Applications, ummmm - dunno really, we're only using it for [ serial --> master --> slave <---> serial ] so in that regard, it's an inexpensive  plug-in solution for adding a second serial buffer, which means we're not having to wrestle with software serial anymore, nor do we need to use a wiring board which solves the same problem, but is bulky and costs a lot. We've had one of those here gathering dust for over 3 months, but we like this idea better because it uses a lot less real estate.

The no-frills design is an elaboration of this:-

http://art364.pbwiki.com/Standalone+Arduino

And Paul Badgers RBBB design.

[Reply #5 on:]

The pcb, with enough room at the top for a water cooler  :o

[Reply #6 on:]

how would you control each individual atmega's with one usb connector?
and wouldent it be better to make digital pins range from 0-26 instead of  2 sets of 13 pins? that way coding would be esier, same goes for analog inputs...

[Reply #7 on:]

SW1 and SW2 provide IC selection, so the chips can be programmed individually without rewiring the USB pins.

When they're not being reprogrammed, the dips are turned off - or, one can stay connected to the USB by moving it's dips to the on position.

The board has an inline i2c connection between both IC's, that's how they communicate. There's three sets of i2c pins on the bottom right hand side of the board, just in case we want to add extra devices.

It's still "two" 168's, but on one board sharing a few components, so the pin numbering is the same as a single, but one lot on each side.

We're using it for [ serial --> master --> slave <---> serial ] anything beyond that is a bonus, because what we're using it for, doesn't need anymore than 6 digital I/O's - we kept the rest, just in case we find something else useful to do with it

[Reply #8 on:]

a Siamese Arduino great concept it may have many uses

[Reply #9 on:]

"Siamese" sums it up quite nicely, Siameseduino is a bit of a mouthful though ;D

I'd say the boys here will be knocking out a 128 Arduino in the not too distant future, so this design will be irrelevant as far as we're concerned if it's not too expensive. But if it inspires creativity in the meantime, then that's not a bad thing.

[Reply #10 on:]

While an Arduino128 or the SiameseDuino is an excellent option for new purchases, I think an IO expanding shield with a second I2C slaved Atmega128 on it and a second set of IO pins might be a good option for existing Arduino owners.

[Reply #11 on:]

Yip, we probably could have done it as a "slave 168" shield. But didn't, because this design in total uses less components than say, an NG - and can be as small as two RBBB's end to end.

A shield also wouldn't allow certain components to be shared, like the resonator - although, two 168's as a shield would.

But I'm not sure how you'd program the chips if it was a shield, I think you'd still need the mini-USB adapter - if anyone thinks up a way that this can be a shield in the next 24 hours, then let me know, we've got a hundred pcb's on order that won't go into production for another day or so.

[Reply #12 on:]

Very nice and very useful idea.

Will you be selling the PCB's?

[Reply #13 on:]

Thanks sidgug.

Yes, once we've tested the PCB's we'll put some out for anyone else who wants to buy them

[Reply #14 on:]

A shield also wouldn't allow certain components to be shared, like the resonator - although, two 168's as a shield would.

As an IO shield, I don't know that you'd need a resonator, the AtMega should be OK at 1/2 speed on it's internal RC clock; otherwise, they're a matter of a dime or so.

But I'm not sure how you'd program the chips if it was a shield, I think you'd still need the mini-USB adapter - if anyone thinks up a way that this can be a shield in the next 24 hours, then let me know, we've got a hundred pcb's on order that won't go into production for another day or so.

If you did it right, the shield would only need to be programmed once, with generic I2C code, and never again. This could either be done by programming the micro in another board (a ZIFDuino?) and transferring it to the shield, adding an ICSP header and using a programmer, or adding a TTL-serial header and using something like the Arduino Mini USB Adapter or the FT232 cable.

I have a fair portion of the slave I2C code written, I'll see if I can write the master library and design a shield proof-of-concept in the morning.