Conway's game of life Pixel (First Project)

[skliffmueller]

Hello all! Been a long time follower of EEVBlog. But never invested time in making a full project.

I've come up with an idea as a small novelty project utilizing my 3D printer, basic logic circuits, and I want to work this up to being production ready for scaling. Generally I'm taking this as a learning experience and would like to publish my work afterwards.

The premise of the project is a modular circuit, that you can plug in as many pixels as you want to make a big display of conway's game of life. For the first project I'd like to do individual pixels. On further versions I'd like to see about having module LED matrix's, and some sort of serialized communication for alterations like 1-wire or I2C.

So far I have made a simple circuit using 4000 series logic, I use 4 IC's consisting of NOR, AND, and XOR gates that has the logic I'm trying to accomplish for each cell. Each cell will be driven by a 12v AC supply. The alternating current will be controlled by a 555 timer, and some mosfets. The frequency won't be anything more than 10Hz as this is the heart beat for the operations of each pixel. The rectifier will provide the DC power necessary for driving the pixel, and there is a pulse generator that fires every time the current alternates. There is an SR Flip-Flop to store the state of the pixel. And a 2-bit adder to count it's surrounding living neighboring pixels. There are labels on the schematic to describe this, and some info in the sketches.

But coming from a programmers background and not an engineer, I know this is just a rough concept, and I may be missing something when it comes to the workings of ohms law, and other things I may be unfamiliar with electrical engineering.

This is where I seek some help for someone to review my project, and provide some suggestions before I dive into purchasing some prototyping components.

Provided are sketches of how I came up with my schematic design (I substituted some inverters with some unused gates on other functions)

Edit: I just realized my Male and Female AC lines need to be flipped to be in correct phase on the other modules. Correction for later.

http://imgur.com/a/61liU

[T3sl4co1l]

Cute!

Hmm, should probably clean up the "AC power" clock a bit first (lowpass filtering + Schmitt trigger?).  For that matter, make sure the state change occurs consistently in two phases: the inputs are read during the rising edge, say, and the output is changed on the falling edge.  Otherwise -- consider what happens when all the neighbors change state slightly earlier or later than the others...

Not sure what you're doing with the transistors there; if U4C's input is low, then the bottom transistor (B-C) pulls the bases low.  If high, then U4C's output pulls the top transistor down.  It doesn't seem to do anything..?

I'd recommend using a D flip-flop (CD4013?) instead of building a latch out of gates.  It's a done deal, so much nicer to work with.

BTW, you still need a common ground pin in the connectors.  Rectified AC only carries a ground reference while the diodes are connected, which is only at the AC peaks.

RFI/EMI filtering and ESD protection on the pins might be a good idea, too.  Individual pixels might not have a problem with it, but you throw a hundred of these together and even just the switching noise from the AC rectifiers may throw off the logic levels!

Also, the diode from the LED doesn't have a pull-down, nor do any of the logic inputs... they're just floating...

Cheers!

Tim

[skliffmueller]

Cute!

Hmm, should probably clean up the "AC power" clock a bit first (lowpass filtering + Schmitt trigger?).  For that matter, make sure the state change occurs consistently in two phases: the inputs are read during the rising edge, say, and the output is changed on the falling edge.  Otherwise -- consider what happens when all the neighbors change state slightly earlier or later than the others...

I was hoping to reduce the amount of pins needed, as to include clock and power signals together. If a ground pin is needed, I may want to consider just DC and a clock signal at that rate. I guess it would reduce the need for a rectifier. Next, the mention of the time needed for state of change to occur, I was thinking the capacitor in "LED and Signal Output Circuit" would hold a charge up long enough to pass a signal over to the rest. But I can imagine this can be unreliable.

Not sure what you're doing with the transistors there; if U4C's input is low, then the bottom transistor (B-C) pulls the bases low.  If high, then U4C's output pulls the top transistor down.  It doesn't seem to do anything..?

I think the overlapping dotted line and junction may cause a bit of confusion, the bases of the transistors are not attached to U4C. And U4C is being used as an inverter to reduce the number of chips I need.

I'd recommend using a D flip-flop (CD4013?) instead of building a latch out of gates.  It's a done deal, so much nicer to work with.

I will consider the D flip-flop suggested below and utilize both functions for changing state based on rise and fall of the clock.

BTW, you still need a common ground pin in the connectors.  Rectified AC only carries a ground reference while the diodes are connected, which is only at the AC peaks.

Didn't think about this, another reason to go DC.

RFI/EMI filtering and ESD protection on the pins might be a good idea, too.  Individual pixels might not have a problem with it, but you throw a hundred of these together and even just the switching noise from the AC rectifiers may throw off the logic levels!

Also, the diode from the LED doesn't have a pull-down, nor do any of the logic inputs... they're just floating...

Cheers!

Tim

Noted and will do! Thanks a lot for the reply.

[Ian.M]

The 'classic' Game of Life rules require each cell to know the state of all eight of its direct and diagonal neighbours to  determine its new state, therefore if you want to avoid diagonal connectors, each side must have an output for the neighbouring state input of one of the two sides round a corner from it (see attached diagram).

It does seem over-complex.  If you use an 8 pin MCU, you could use one pin per side for bidirectional comms, relaying the adjacent cell and corner cell state, one pin for LED control and the remaining I/O pin as the clock input.  That would get it down to three electronic components per cell - the MCU, a decoupling cap, and a Neopixel LED.   Each side would need four connectors - distributed +5V Vdd, Gnd and Clk, + the bidirectional data link.  Initial state control could be done by a special command: Shift this bit N cells up then M left right then store it.  Each cell would pass the command on, to the appropriate side, decrementing one of first N then M each time until both are zero then storing it.  The setup commands would be provided by a computer interface connected to the bottom left cell.

[Brumby]

The 'classic' Game of Life rules require each cell to know the state of all eight of its direct and diagonal neighbours to  determine its new state, therefore if you want to avoid diagonal connectors, each side must have an output for the neighbouring state input of one of the two sides round a corner from it (see attached diagram).

This was the first thing that jumped up at me too.

Diagonal connectors are going to be next to impossible, since any plug in style at 45 degrees are going to prevent anything from plugging in to anything.  Also, I can see surface touching contacts on the corners aren't going to work too well.

I agree with Ian.M's idea of a neighbouring cell passing on the current state of the next cell 'around the corner'.  This way, each of the 4 adjacent cells provides 2 state values, giving you all the information you need.  In the diagram from Ian.M cell 3 passes the state of cell 2 'around the corner'.  So long as this direction of transfer is the same on all four sides, we have a winner.

This system will work in most cases.  If the matrix is a completed rectangle, then all is well - but if there are any diagonal edges, then things aren't quite right.

For example, let's say cells 3, 4 and 5 were vacant.  All the necessary information paths are intact, bar one.  The status of cell 2 cannot be determined by our central cell.  The value the central cell will use will be the default value that has been defined for an unoccupied neighbour which means it has a 50% chance of being correct.

For the complexity of doing so, I don't think this is an issue worth trying to resolve.  Just understand that this is the case - to be accepted as a foible.  Keeping complete rectangles will avoid this issue.

[skliffmueller]

I appreciate the comment, despite feeling like an idiot. Good thing I asked for help.

Out of reviewing the costs and development time of cmos logic vs something like a PIC16F54, I'm going with the microcontroller. To start I don't think I will worry about any type of serialized communication just yet, as I can't wrap my head around how exactly that would work without having sync issues when cycling the game.

I can understand having the MCU's pass initialization commands over from input source to destination, But when I tell everyone to start playing, it would have to take a few clock cycles to step over onto all the pixels, as commands are now passed onto one, to the next, to the next. In theory if everyone was in sync, sticking to assigned frames of data with static lengths, and keep operation cycles the same, there shouldn't be a problem. Need some time to think that one over.

In the mean time it's late over here. I'll come to revisit this project tomorrow. Again thanks for the input.

[Ian.M]

If you use a MCU, Brumby's objection to diagonal edges can be worked around.  Each cell can make a map of its neighbours and in addition to passing its own state to the neighbour its talking to, it can forward the states of all its other neighbours.   You could also do the cellular clock over the communications links.   Each clock command would have a sequence number and each cell would propagate it up and right.  If a cell receives the same sequence number again on its left or lower interfaces, there's a loop and that extra clock command must be ignored.   

You'll also want looping cables that let you connect two opposite sides of a cell matrix together to do stuff like forming a logically cylindrical surface or if you connect two pairs of sides, a logically toroidal surface.

When choosing a MCU, *DON'T* choose something obsolete like a PIC16F54 - pick something with an accurate enough internal oscillator, on-chip debug support, an affordable debug capable toolchain and enough I/O pins that you can reserve the programming/debugging pins.

I have a vision of the cells as LEGO compatible, so you can simply clip them onto LEGO baseboards, with sprung side connectors similar to Denshi Blocks.

[Brumby]

If you use a MCU, Brumby's objection to diagonal edges can be worked around.

I realised that, but the OP had presented a simple gate solution - and I was speaking to that design.

Now that he is embracing the MCU idea, things have changed.

[Brumby]

I have a vision of the cells as LEGO compatible, so you can simply clip them onto LEGO baseboards, with sprung side connectors similar to Denshi Blocks.

If you can produce a solution that is orientation independent and Lego footprint compatible, you might have a market for this in the Lego world!

[Ian.M]

I reckon that's possible.  The cells can learn their orientation from the side they received the initial setup command on, and whether it was being passed horisontally or vertically at the time, and the power contacts could be arranged in symmetrical pairs so they are orientation independent.   If each MCU ran an interpreter that handled the actual cellular automation algorithm, with the firmware feeding it the multi-valued states of all neighbouring cells (and maybe the next ring out as well) you could do a lot of other stuff, including implementing logic functions complete with das blinkenlights, or neural networks.   

[Brumby]

The mind starts exploding with ideas at this point, doesn't it?

[Ian.M]

Yes, and as many MCUs have ADCs, PWM modules etc. and 1024 bytes of EEPROM isn't unusual, if you use two pins per side for the datalink, you could also run them as distributed computing nodes or node clusters, with each leaf node having up to six analog/digital I/O pins available. Functions that need more I/Os could be implemented by a pair or more of cooperating blocks. All that would need would be some sensor and actuator interface blocks, various types of dumb interconnect blocks and some interconnect to jumper cable adapter blocks + either a simple programming jig you clip each bock into to configure it, or some protocol for mapping a complex block network, then configuring each individual block from a single master block with a USB interface.  Blocks could be configured by sending them individual compiled bytecode programs, one of the example ones being Conway's Life.  Each block while in configuration mode would forward programs to its neibours - the furthest leaf mode being programmed first, working back towards the master block.

[Brumby]

Don't go away folks !!... stay tuned for Chapter 2:  Skynet.

[Ian.M]

Don't go away folks !!... stay tuned for Chapter 2:  Skynet.

Not likely unless you are dumb enough to add unsecured long range wireless connectivity.

The worrying one would be: How many blocks would it require to implement the control system for a real-world Von Neumann replicator, assuming it could parasite the wold techno-ecosystem by ordering parts and assembly online?

[Brumby]

Not likely unless you are dumb enough to add unsecured long range wireless connectivity.

Expect someone to do that as a hack.

The worrying one would be: How many blocks would it require to implement the control system for a real-world Von Neumann replicator, assuming it could parasite the wold techo-ecosystem by ordering parts and assembly online?

... and that's the sort of thinking that might inspire someone to try.

The intention might be benign, but the potential somewhat less so.

[NivagSwerdna]

I like the idea but it looks very expensive.  How about each module serving a small grid of pixels... 3x3?  You need need quite a few pixels to get a good effect.

Also... you will need a mechanism to load patterns into the grid so one node should be master and capable of setting an initial position to the whole net at time intervals or whenever some condition (e.g. total death + time) has been reached.

[Life was one of my first assembler programs for the Commodore PET]

[Ian.M]

If you are going down that route, why not simply make either 2x2 or 4x4 tiles so each cell has one LED per LEGO stud while still using standard block sizes.  2x2 can probably still be implemented in a small cheap MCU, as four timesliced threads, 4x4 is likely to need a more capable processor.

[tszaboo]

I've been thinking about this myself for some time. My conclusion was that sharing the information between the microcontrollers is the best to do analog. Simply because with a few placed resistors to the connectors, you can transfer more information without complicated code. I concluded that a 6 pin MCU with 2 ADC pins 1 clock and 1 output (used to transfer the information also) should be able to do it.
The mechanical part was the worst, since connectors are huge compared to the LEDs, so ultimately, I abandoned the project. Besides, it would cost a fortune to actually build a reasonable sized wall of it.

[NivagSwerdna]

Besides, it would cost a fortune to actually build a reasonable sized wall of it.

Yeap.  If using monochrome then 8x8 matrix seems reasonable cheap so that might make a reasonable unit.  To get a good effect with gliders etc you need a good sized screen.

[Ian.M]

However, as you go up in unit matrix size, you loose the point of it being a physical implementation of a Cellular Automation - it just becomes another pure software implementation with a display device that offers a particularly poor price:resolution ratio.

[T3sl4co1l]

Would be interesting to do it in analog -- which isn't insane at all, but is merely a matter of summing the neighbors together and using a window comparator and latch.

I think it would end up using about as many pins though (as ICs, transistors, resistors, etc.).

Tim

[NivagSwerdna]

However, as you go up in unit matrix size, you loose the point of it being a physical implementation of a Cellular Automation - it just becomes another pure software implementation with a display device that offers a particularly poor price:resolution ratio.

From an aesthetic point of view.... I agree.

[skliffmueller]

Alright, I need help selecting an MCU, and some design input. Sure I can be given suggestions on what I need to look for, but having my options reduced from 100k to 5k, doesn't really help me. Here are some design ideas on what I'd like to accomplish per cell.

LED Matrix spec: 4x4 resolution, I think a 16-bit packet to define what is on and off per address is a reasonable size for serial communication
LED Matrix Driver options:
a.) 8 I/O's, directly from MCU driving matrix across 4x4 grid
b.) 5 I/O's, 4 across matrix column, 1 clock signal for multiplexing.
c.) 2 I/O's, 1 signal for 16 LED's, 1 clock for multiplexing.

When it comes to serial communication, I think something like I2C would work out well cause it doesn't really matter how many nodes you have as long as you can handle the address lengths. But there are some things I'd like that are kind of unique from the standard I2C implementation.I would like to have all nodes listen on a global address. Lets say the master node broadcasts on the global address for the children to announce their current pixel status. They will each know they have to go in order of their address cue. so 0x0001 announces first, and address 0x0002 knows it has to go after 0x0001. At the same time, each node is listening for the addresses top, bottom, left, and right of themselves of their current state, so they may store it for the next cycle. This will also come in handy when the next step command comes through, I don't have to send a command to each node individually for reading and exchanging. So what kind of MCU would allow me to adjust the I2C protocol at this level to listen for multiple addresses?

I'd also like to implement something unique, auto location identification. By default the MCU has all ports disconnected except two ports, lets say the left and bottom port. Master will connect to the left port of the bottom left most node, master will broadcast on global address something to the effect of (Who hasn't initialized). Since the node by default has the communication lines cut to everyone, the child node responds to master. Master assigns address, then tells child node to open right port communication. Master continues same cycle again for next node opened on right port. This would require 2 additional I/O's to control top and right ports. Bottom and left will be open to receive when top and/or right has opened.

So when it comes to I/O's needed anywhere from 4-7-10, not including 2 more for I2C.

Any thoughts?

[Ian.M]

There is no good way of routing an I2C bus to implement your idea - you cant effectively switch it as the switch on resistances daisychaining through the array would add up to the point where it would compromise the logic 0 level.   This could be worked around by hard wiring the I2C to all four sides then using some sort of handshaking on seperate I/O pins for discovering neighbours, but even if you do that,  I2C doesn't scale well for large numbers of devices on the same bus.  You run into problems with load capacitance which reduces the maximum possible bit rate and leakage currents which compromise your logic levels. 

On the subject of selecting a MCU, well what development tools do you have for fairly low cost MCUs?   Your existing investment in programmers/debuggers and what you are already familiar with coding on will probably dominate at least until you have a proof of concept running.  If you were intending to commercialise this as a mass-market product, you'd need to prune every cent possible from the BOM e.g. by porting it to a cheaper MCU, but before you do that you really need the specification set in stone which is not a good idea before you have the proo of concept running.

If you don't have any existing MCU development tools, one low cost approach to a proof of concept would be to use a ten pack of cheap chinese CH340 Arduino Nano clones.

[skliffmueller]

Alright, well screw it, I don't understand enough. I was hoping to utilize  something that is efficient, and only to the needs of running serial communication and simple logic. If I'm going to the scale of an arduino, I may as well say fuck it and buy a raspberry pi and an LCD monitor. The reason why I originally suggested things like a PIC, and heck I'd be fine running off an 8051 or something, sure it's old, but do I really need anything more? I'm not building a rocket.

[Ian.M]

An entry level Arduino is really just a development board for the 20 pin ATmega328P 8bit MCU, + an on-board USB <=> serial chip for PC communications + a toolchain and U/I that's aimed at users with no prior experience of embedded development.  If the 'Arduinoness' offends you, you can ignore the Arduino libraries and simply code in 'raw' GCC C for an ATmega target, or you can throw out the whole software toolchain and use Atmel Studio.  For your application a ten pack of Nano boards would just be a cheap way of getting enough boards to do a small 3x3 segment of your final concept, all with PC interfaces so the perimeter boards could exchange data with a PC emulating the rest of a larger matrix.

Any of Microchip's debug capable newer 8 bit PICs could also do the job, but that will cost you a lot more if you don't already have a PICkit 3 or ICD 3 and some USB <=> logic level serial interfaces to handle the PC comms.

An 8051 would  be fairly crazy unless you've already got the development tools and know how to use them.  Some of its successors with compatible cores in lower pin count packages would probably be suitable, but if you've used 8051s seriouly you should already know that and we wouldn't be having this debate.

There is little point in building hardware cellular automatia unless you have a strong interest in the details. IMHO it starts to become less meaningful as soon as you put more than one cell in a single MCU.  If its just the aesthetic result you are interested in, a large LED matrix controlled by a single reasonably fast SBC running a cellular automatia smulator will be cheaper and far easier to get working.

[skliffmueller]

I am completely interested in the full development process. I'm just getting bored of the adruino build, and implementation of proof of concept. I understand the idea, but if I'm only going to learn a single framework, and not the inner workings of electronics, I kind of feel like what's the point? I'm not learning anything, and if I'm looking to getting price points down, why would I spend $2 on an arduino chip, if I can get a 40 cent chip that does the job. When it comes to assembly language? I'm not afraid of it. I've written for z80, 68k, and some really basic x86. C? proficient at it. Scripting languages, mostly what I do. USB interfaces for programming devices? They don't seem that expensive. Development tools, how much help do I really need when I have a datasheet? I'm not afraid of the investment part of the learning experience.

As I stated on the original post, I am looking to learn the process of making a production ready device. Proof of concept, you can goto youtube and find someone making conways game of life with an arduino.

[Ian.M]

The devil is in the details of the inter-processor communications needed for each cell to see the state of its neighbours.  As you have pointed out, there are plenty of Arduinos running cellular automatia simulators, but I believe you'll find that scalable expandable multiprocessor ones are vanishingly rare.   You cant design for production without a firm specification, and that's what the prototyping gets you - at the moment you don't even have a firm idea what you need for minimum connectivity per side without compromising functionality.  *EVERY* additional plated sprung contact costs money . . .
Then there's the cost of the MCU, a $0.40 chip is only cheaper if it can do the job.  If you run out of pins, memory or MIPS, you will deeply regret locking in to a 'cheap' MCU.

[skliffmueller]

Which is why I'm asking for suggestions on what are practical applications of multi node serial busses, but I don't want to sound like I'm not coming up with ideas so I throw I2C out there, but then I'm told it's not going to work without any further suggestion of an alternate solution or ideas, so I'm back to square one to throwing ideas on the wall with no real practical knowledge of the options available, and their pro's and cons of usage. Once I can get an idea of what is required for communication, I can come up with the pin configuration, select an MCU appropriate to I/O availability, real-estate, and cost. I can come up with some small list of options. Then when I do prototype, I can dig up some arduinos out of a box and prototype within those known constrains to see practicality of my selected device implementations, and if things look promising, buy up some MCU's from the selected list and develop again. Once price point is within reason, scale, and prototype some more.

So for now, lets just say I will select whatever MCU. The current problem. Communication. What are some options that would allow multi node serial communication for 1,000+ nodes, with minimal impact to number of communication pins.

[MattHollands]

I know that you've changed from an analog implementation to a micro controller - but I have been having a bit of a play and I've found a way to get your design into two very cheap chips. My design basically uses a latch, 4 comparators and a bunch of resistors. A quad comparator costs less than 30c on digikey and similarly does a latch.

The circuit basically uses a resistor ladder to produce a voltage n/8 volts where n is the number of neighbours that are alive (ie a logic high). Then, 3 comparators are used to generate three logic bits:

A = 3 or more neighbours alive
B = 2 or more neighbours alive
C = 3 or less neighbours alive

The final bit is the current state: S = 1 if alive or 0 if dead.

These four logic bits are then combined via another resistor network to create a voltage that is above 2Vcc/3 if the new state should be alive and less than 2Vcc/3 if the new state should be dead. A final comparator is used to turn this into a logic bit.

Stick a latch on the output of this and clock it with your AC and you're done. Pictures attached.

You can basically see that, if the current state is dead, then the pixel will only become alive if there are exactly 3 neighbours alive. If the current state is alive then the pixel will only stay alive if there are 2 or 3 neighbours alive.

[Edit] I haven't looked at exactly how accurate the resistor values need to be. Probably best to do some kind of Monte Carlo simulation if you want to make sure this will work with 5%+ error in values. But my intuition at the moment is that it wouldn't be overly sensitive to this. [/Edit]
[Edit] Also would have to make sure the input impedance of your comparators was not significant, but that just comes down to component selection, and you can always scale the resistor values down by an order of magnitude if you like [/Edit]

[kwass]

I thought about this problem years ago and decided that I would use short range IR optical coupling between elements, with cut corners for the diagonal ones.  The clocking would be done from overhead, also IR optical.  Each cell would have it's own battery power and, of course, visible light LED state indicator and a button to initialize it's state.

I never constructed this as the expense and tedium of building enough cells for interesting patterns would be no fun.

[skliffmueller]

I know that you've changed from an analog implementation to a micro controller - but I have been having a bit of a play and I've found a way to get your design into two very cheap chips. My design basically uses a latch, 4 comparators and a bunch of resistors. A quad comparator costs less than 30c on digikey and similarly does a latch.

The circuit basically uses a resistor ladder to produce a voltage n/8 volts where n is the number of neighbours that are alive (ie a logic high). Then, 3 comparators are used to generate three logic bits:

A = 3 or more neighbours alive
B = 2 or more neighbours alive
C = 3 or less neighbours alive

The final bit is the current state: S = 1 if alive or 0 if dead.

These four logic bits are then combined via another resistor network to create a voltage that is above 2Vcc/3 if the new state should be alive and less than 2Vcc/3 if the new state should be dead. A final comparator is used to turn this into a logic bit.

Stick a latch on the output of this and clock it with your AC and you're done. Pictures attached.

You can basically see that, if the current state is dead, then the pixel will only become alive if there are exactly 3 neighbours alive. If the current state is alive then the pixel will only stay alive if there are 2 or 3 neighbours alive.

[Edit] I haven't looked at exactly how accurate the resistor values need to be. Probably best to do some kind of Monte Carlo simulation if you want to make sure this will work with 5%+ error in values. But my intuition at the moment is that it wouldn't be overly sensitive to this. [/Edit]
[Edit] Also would have to make sure the input impedance of your comparators was not significant, but that just comes down to component selection, and you can always scale the resistor values down by an order of magnitude if you like [/Edit]

Really neat idea, One thought though, don't you only need 4 steps of voltage, everything after could be just Vmax resulting in death?

I thought about this problem years ago and decided that I would use short range IR optical coupling between elements, with cut corners for the diagonal ones.  The clocking would be done from overhead, also IR optical.  Each cell would have it's own battery power and, of course, visible light LED state indicator and a button to initialize it's state.

I never constructed this as the expense and tedium of building enough cells for interesting patterns would be no fun.

I'm beginning to notice this.

[MattHollands]

I know that you've changed from an analog implementation to a micro controller - but I have been having a bit of a play and I've found a way to get your design into two very cheap chips. My design basically uses a latch, 4 comparators and a bunch of resistors. A quad comparator costs less than 30c on digikey and similarly does a latch.

The circuit basically uses a resistor ladder to produce a voltage n/8 volts where n is the number of neighbours that are alive (ie a logic high). Then, 3 comparators are used to generate three logic bits:

A = 3 or more neighbours alive
B = 2 or more neighbours alive
C = 3 or less neighbours alive

The final bit is the current state: S = 1 if alive or 0 if dead.

These four logic bits are then combined via another resistor network to create a voltage that is above 2Vcc/3 if the new state should be alive and less than 2Vcc/3 if the new state should be dead. A final comparator is used to turn this into a logic bit.

Stick a latch on the output of this and clock it with your AC and you're done. Pictures attached.

You can basically see that, if the current state is dead, then the pixel will only become alive if there are exactly 3 neighbours alive. If the current state is alive then the pixel will only stay alive if there are 2 or 3 neighbours alive.

[Edit] I haven't looked at exactly how accurate the resistor values need to be. Probably best to do some kind of Monte Carlo simulation if you want to make sure this will work with 5%+ error in values. But my intuition at the moment is that it wouldn't be overly sensitive to this. [/Edit]
[Edit] Also would have to make sure the input impedance of your comparators was not significant, but that just comes down to component selection, and you can always scale the resistor values down by an order of magnitude if you like [/Edit]

Really neat idea, One thought though, don't you only need 4 steps of voltage, everything after could be just Vmax resulting in death?

Well that is true but I don't see any advantage in finding some way to make the steps non-linear.

[Edit] Another reason I like my design is that it is basically a neural network in physical implementation. Each comparator is a neuron which sums it's input with weights and then outputs something. [/Edit]

[T3sl4co1l]

Note that the above merely solves the state transition -- but additional hardware is necessary to sequence the states.

To do that, you could use a dual analog switch, so that the current state is passed to a capacitor, and then the capacitor state is brought to the outside world (via logic buffer).  The switches alternate (with dead time to prevent the "new" state bit from surging straight ahead), thus acting as a master-slave type D flip-flop.

Or, of course, you can simply use a flip-flop.   (This is, more or less, what a CMOS D-f/f does internally -- bidirectional switches are used to shuttle the internal state forward.  Set and reset gates are added, obviously, to realize the full function, but those aren't needed here.)

Tim

[MattHollands]

Note that the above merely solves the state transition -- but additional hardware is necessary to sequence the states.

To do that, you could use a dual analog switch, so that the current state is passed to a capacitor, and then the capacitor state is brought to the outside world (via logic buffer).  The switches alternate (with dead time to prevent the "new" state bit from surging straight ahead), thus acting as a master-slave type D flip-flop.

Or, of course, you can simply use a flip-flop.   (This is, more or less, what a CMOS D-f/f does internally -- bidirectional switches are used to shuttle the internal state forward.  Set and reset gates are added, obviously, to realize the full function, but those aren't needed here.)

Tim

Well I did say in my explanation that you need a latch. So yeah put a d type latch on the output... Obviously have to make sure setup and hold times are satisfied but again that's just component choice

[Ian.M]

Back to the digital MCU implementation:

Which is why I'm asking for suggestions on what are practical applications of multi node serial busses, but I don't want to sound like I'm not coming up with ideas so I throw I2C out there, but then I'm told it's not going to work without any further suggestion of an alternate solution or ideas, so I'm back to square one to throwing ideas on the wall with no real practical knowledge of the options available, and their pro's and cons of usage. Once I can get an idea of what is required for communication, I can come up with the pin configuration, select an MCU appropriate to I/O availability, real-estate, and cost.
<snip>
So for now, lets just say I will select whatever MCU. The current problem. Communication. What are some options that would allow multi node serial communication for 1,000+ nodes, with minimal impact to number of communication pins.

Although you may have thousands of nodes (if you win the lottery ), why do you think they should all be on the same bus and why do you think that bus needs to be switchable?

The basic requirements are: to communicate bidirectionally with all neighbours to exchange local state maps, to distribute a clock or other sequencing signal,  to discover the local mesh topology, and to forward commands, either selectively along a particular route via a particular side, or broadcast out of all sides except the one it came in on.

Obviously, there's got to be something to stop commands being passed node to node in an infinite loop, and the easiest solution to that is a command sequence number, which gets stored in a buffer so duplicates of recent commands can be ignored.

You want to eventually implement this to commercial design standards, so all off-cell I/O is going to need ESD protection, + good interconnects are not cheap, so there is a strong incentive to minimise the number of interconnects per side.  If you can use a single pin bidirectional bit-banged serial link per side it will be a lot cheaper than a design that needs a UART or other hardware serial comms peripheral per side or needs some sort of switching matrix.  Additionally, by implementing the state clock as a broadcast command, you save a pin per side.

I think it can be got down to four I/O pins for comms and three contacts per side in a vertical row - ground at the bottom, power in the middle and data at the top.

[oPossum]

This has already been done with a microcontroller....

https://www.adafruit.com/products/89

[Ian.M]

I'm not surprised its been done as a tileable 8 bit MCU implementation, as cellular automata have been popular with computer hobbyists almost as long as there have been computer hobbyists,

The challenge would be to do it better^* or cheaper, and its certain the O.P would learn a lot from the development process from first principles to something that would be ready to put on Kickstarter.

Perhaps the analog version deserves further study - e.g. what would be the minimum component set to implement a 2x2 tile, and would it be significantly less than those needed for four single cells?

* the Adafruit version is really quite limited - if you want to change the algorithm you would have to flash it with new firmware, and there is no way of interacting with or controlling it other than to reset the tile.

[Brumby]

The question of processing states is, indeed, a primary concern - but with any analogue or other non-MCU implementation, what about setting the initial states?

[T3sl4co1l]

A button to toggle each bit would be cool.

Tim

[djacobow]

I did this several years ago on a 16x16 led matrix driven by an atmega328 ana shift registers.

It's really a clock, but it has Conway mode ... Because.

Happy to send the code to whoever is interested.

By the way, it runs much faster than in this video. I just slowed it down so it's more fun to watch.

[Sigmoid]

Well if you have an interconnected 2 dimensional array of programmable nodes, you might want to look into Cellular Neural Networks, as that's what you really have on your hands...

https://en.wikipedia.org/wiki/Cellular_neural_network

[FrankBuss]

Any of Microchip's debug capable newer 8 bit PICs could also do the job, but that will cost you a lot more if you don't already have a PICkit 3 or ICD 3 and some USB <=> logic level serial interfaces to handle the PC comms.

The original PicKit3 costs EUR 46: http://www.digikey.de/product-detail/de/microchip-technology/PG164130/PG164130-ND/2171224 And probably the $15 clones from eBay are fine, too. So such a programmer and a bunch of low-cost PICs are much cheaper than a bunch of Arduinos.

In this video, Mike explains an interesting project with lots of LEDs, and how they are controlled and connected:



Besides the communication, which is controlled from a central controller in this case, the power distribution is critical. If you are going to connect lots of these dots, the connectors won't handle the high current, so you might need high voltage and locale voltage regulators for each pixel, or some structural base with big power supply rails.

[Ian.M]

A ten pack of CH340 Arduino Nano clones can be found on Ebay for as little as $21.50
e.g. http://www.ebay.com/itm/10PCS-Arduino-Nano-V3-0-ATmega168-16M-5V-Micro-controller-CH340G-MINI-USB/182314708074

By the time you've got a PICkit 3 clone, enough PICs and some matrix board, it will almost certainly have gone over that price, and if you run into any problems you wont know whether to blame Microchip, your PIC supplier or your PICkit 3 clone supplier.

I'd go with PICs, but I already have the toolchain and over 15 years experience with them . . .

For someone less comfortable with modern single chip 8 bit MCUs the pack of Arduinos is likely to be a better entry point, and faster + cheaper to get running - stick them down on a boad with double sided foam tape and wire the test matrix point to point.

I agree power distribution is going to be an issue once one tries to reduce the concept to plug&play blocks - pushing more than 1A through sprung side contacts is asking for trouble.  Smaller matrices can be fed from the edges - if you run power and ground bus bars all the way along the longest edges, depending on your unit module current, as many as 25 modules daisychained may be practical, allowing a matrix of 50 across.  Larger matrices would have to be back-fed, one feed module in the middle of each 5x5 block, with a local regulator for it under the baseboard.

Of course if you want 5W pixels visible outdoors in direct sunlight, that's a whole different ballgame

[FrankBuss]

Nice, the CH340 Arduinos are really cheap, thanks for the link (on German eBay: http://cgi.ebay.de/272308424805 ), I might buy a pack. How can they do this for this price? Just the ATMEGA168 costs $1.50 (if you buy 2,000) and the CH340G with crystal etc. might cost another dollar, and then the cost of the board, connector, jellybean parts etc. has to be added.

You are right, you can't build it cheaper, unless you build a lot of it. A custom board, soldering it and even a cheap PIC would cost more. If size and elegance doesn't matter, use a bunch of these low-cost Arduinos, stick it to a base plate, and interconnect it with jumper wires, at least for a prototype.