Any Electrical Engineers in the House?

[sandheaver]

I need advice on a way to turn the digital I/O of an arcade control panel into, basically, a combined digital connection where it would be turned back into discrete I/O for a JAMMA board on the other end.  The point is to create a much simpler harness-to-controls connection using a bit of automation.  Pulling power from the JAMMA harness is acceptable, this won't be a wireless solution.

At the moment I'm not interested in analog controls, such as trackballs or spinners; digital controls only.

Anyone know how I could do something like that?

[MonMotha]

Are you willing/do you want to write a little firmware, or are you looking for something you can just build out of chips?

Or, are you looking for an off-the-shelf solution?

[sandheaver]

Are you willing/do you want to write a little firmware, or are you looking for something you can just build out of chips?

Or, are you looking for an off-the-shelf solution?

I'm not one for assembly or C, but I can give it a go if required.  I don't know of an off-the-shelf solution.

[MonMotha]

You can do this with a couple microcontrollers that have enough IO pins and just connect them via the UART.  Full Arduinos or similar dev boards would work (and have a somewhat more beginner-friendly programming environment), but they're cost-wise total overkill.

You can also do it using a bunch of shift registers and a little state machine built using some counters and glue logic.  Basically, you're building something resembling SPI but without a programmable controller.  This has the advantage of being essentially infinitely extensible since you just need more shift registers to add more IO, rather than more IO lines on a micro.  Of course, you can use IO expanders on a micro, too.

Another decent approach (that I might use) is something of a hybrid: use a micro on one end as the master and a bunch of shift registers on the other end as the slave.  This means you don't have to design the clock/state machine in hardware and can use the MCU's SPI controller for that instead. I2C IO expanders work, too, but I2C can sometimes be a pain.

There's of course a ton of other options.  These are just what come to mind off the top of my head, which generally means things I could implement using parts from my junk bin.  Your junk bin probably differs.  Most of the options I've described require 3-6 lines between both ends.  Parallel mux options also exist that wouldn't reduce the IO count as much also exist that may be a bit easier to implement in low integration (e.g. 74 series) hardware only.

[sandheaver]

Will the dual microcontroller UART solution offer low enough latency?  hardware interrupts are probably the way to go if I know my interrupts.  Simple shift registers will do if they are fast enough, I suppose.

I don't know.  I'm in over my head a bit, here.

[drventure]

+1 on an arduino. Yeah, they're more $, but they'll be a lot easier to get into up front.

Besides, they aren't that much more. You can get em online for pretty cheap now. Mouser has this one for 23$

http://www.mouser.com/ProductDetail/Arduino/A000053/?qs=%2fha2pyFadugaOwpiwv5%2fjwz%2fYjKsnGtRcAA1pG9dhkw%3d

[MonMotha]

Will the dual microcontroller UART solution offer low enough latency?  hardware interrupts are probably the way to go if I know my interrupts.  Simple shift registers will do if they are fast enough, I suppose.

I don't know.  I'm in over my head a bit, here.

Depends on how fast you run it.  Without a transceiver in the middle (just running TTL level) you can usually get 1MBaud in async mode out of modern UARTs on 8-bit MCUs (faster yet on some e.g. ARMs).  If you've got, say, 48 inputs, that works out to somewhere on the order of 60 microseconds to move the data over the wire (maybe add on some time for message level framing).  That corresponds to a sample rate of ~16kHz.  A 16MHz CPU can probably keep up with this.

Most games only sample once per frame, but some do sample once every scanline, so you're just good enough.  You could potentially sync up the sampling to the horizontal sync (i.e. trigger off the video sync line) to keep things consistent rather than free running, but I doubt you'd notice either way.  Even extremely demanding applications like music rhythm games or fighters are fine at 500-1000Hz (and arguably lower).

Most SPI controllers can go a fair bit faster.  8MHz is common on the AVRs used on Arduinos, though the CPU can barely service the transceiver that fast, and you do need to move the data from the IO port to the SPI controller or vice versa.  The ARMs I use in a lot of designs these days can often do 25-50MHz on their SPI ports, but you essentially require DMA to actually keep up with that.  I'd expect you could get about 200-250kHz effective sampling rate using SPI and two back-to-back 8-bit micros if you really wanted to, but it's wholly unnecessary.

Shift registers can usually be clocked at at least 5-10MHz, depending on logic family.  AHC series can usually go upwards of 25-50MHz.

Note at at >1MHz or so speeds, so called "high speed" or "transmission line" effects can become significant.  At >10MHz, you're almost certainly going to run into problems if your cabling is more than a foot or two long, especially if it's a parallel bus.  Good power bypassing (0.1uF ceramic caps) on the ICs is imperative.