This is off-topic and I apologize, but i2c should be fast enough to pass events. I would have probably gone with the UART interface because you have a little more over sampling which can reject noise. i2c can get into a "locked" state if the signals are detected as being in an illegal state during certain parts of the transaction. I would be a little bit worried about noise from the solenoids affecting the i2c enough to get it into a bad state. Events are really slow in pinball compared to most "real-time" events.

The only difference is that I've been hacking at this slightly longer than you guys have been hacking away at this stuff. My first projects all had things that I would improve, and Van Halen continues in that line of...I wish I would have done it this way instead of what I chose. If you aren't learning something new, there is little reason to do it in my opinion.

Just to set the record straight, OPP isn't an arduino project. It is based off a PSoC4200 card which you can buy for $4. At the time (2015 era) it was the cheapest board that had 32 I/Os, plus extra I/Os for tx/rx, and some out of band communication.

I sort of dislike arduino's principally because they simplify coding at the expense of performance. Ben Heck has a video where he has some arduino code blinking an LED. I can't 100% remember the context (it is his pinball kit), and he times the frequency of the polling loop, and it is running at 44 Hz. Last time I timed the OPP main loop, it was operating significantly faster than 1KHz. I absolutely love some of the processors that the arduino code uses. (I think of arduino as the code framework, not really the hardware itself). I considered using arduino hardware back in 2015, but they couldn't hit the price point I was targeting at that time.

I agree with Jeremy. The Pi should be left out of any real time stuff. The one strange part of that is playing sounds. I have had good luck with my Pi playing all the sounds. The Van Halen machine has the equivalent of a slightly under powered Pi zero. (It is using a Raspberry Pi, Model B, v1. Same memory as a Pi Zero but with a much slower processor. ) The analog output from my Pi is atrocious, so I bought a USB to audio dongle (costs about $3). The driver for those set up a DMA channel to move the music to the dongle, so it only slightly affects the performance of the processor. Using pygame as the basis I can play about 5 sounds concurrently, and have a background track going continuously.

In the OPP pinball framework, I believe that I use 3 threads. 1 thread deals with the serial communications. 1 thread updates the backglass by blitting as small of an area as possible. (If only updating the second players score, don't redraw the whole backglass, but simply blit the rectangle that contains the score portion.) The last thread runs the rules for the pinball machine. (Timers, looks at the last read values of inputs, posts flags to send new serial commands, etc.). Python suffers from a global interpreter lock, but that separation of processing has served me well.

A Pi 2 and certainly a Pi 3 should have enough horsepower to do what you are trying to do. I assume that none of your communication is bit banged. If it is bit banged, it can take a lot of time.

On the lamp matrices, some machines have them, and some do not. Dolly did not have a matrix, but each lamp was individually brought to a low side switch to turn it on/off. In the old Bally hardware, an I/O expander (similar to your bit shifter), was used to turn the lamps on/off. The I/O expander had a parallel interface to the processor with a chip select to update the values, so it could happen very quickly. With the arduino, it probably uses a parallel to serial converter in hardware in the processor, then the shift register just converts it back to parallel.

If you want, you can look in the OPP repository at repos/Python/PinballFramework. It might give you some ideas. It uses PyGame to do all the graphics, then runs the multiple threads as previously discussed. It is a very simple pinball framework. If you want to do anything more graphic intensive than showing static slides and scoring, MPF is the best bet. They moved away from pygame to speed up their graphics using openGL which is a far better solution than pygame.

I fully agree. By switching from Arduino methods to C, all of the speed can be regained? It seems it is easier to simply write the code in C from the get go, and you get the speed for free. The downside is you need to read the processor manual which is probably around 2000 pages long, but in reality you simply pick and choose what you care about.

@thatonedude You can probably just use the 12V rail without adding capacitance to the ATX supply. ATX supplies have a good amount of capacitance built in for that rail because it is normally supplying voltage for a PCIe based GPU. GPUs have large instantaneous current draws and while they do add some capacitors on the motherboard and some within the GPU board itself, the big capacitors bulk capacitors are normally in the ATX supply itself. (I'm not sure what the 12V DMD instantaneous change in current is, but my guess is it will work without a problem without extra power filtering).

@legtod2 You can easily drop the dedicated power to the Pi. That just needs 5V which you can grab from your PC power supply. If you want the Pi to be on all the time, use 5VSTDBY. It's pretty easy to add a MOSFET to turn the PC power supply on and off from the Pi itself. The powering of the Pi's USB depends on which version of the PI.

Guess it means that you have to pony up the cost of more bulk filtering caps....Good information on the 12V DMDs. If doing that, you can probably buy caps with a lower voltage rating to save some coin. 16VDC is the next "standard" cap voltage. (Everybody loves to save some coin and the lower voltage caps are under $2 each).

You might be able to use something like this to turn the AC to the transformer on/off. https://www.aliexpress.com/item/1Pcs-5V-Low-Level-Trigger-One-1-Channel-Relay-Module-DC-AC-220V-Interface-Relay-Board/32803522724.html There are scant specs on it such as how much 5VDC current that you need, but it looks like the input is to a MOSFET to enable/disable the 5V to enable the AC, so it should take almost no current from the processor itsefl. If you have the arduino or pi control it, it should be pretty easy to insure that your startup/shutdown sequences are correct. (and hey, it is 93 cents so how wrong can you go). That might be an easy way to go.

You might want to consider driving the input of the relay through a MOSFET. It is listed as 4mA which is definitely achievable by any of the 5V arduinos on a per pin basis (at least the ones that I know of), but it is a high enough current that you start pondering about it. Hmmm, do I really need to drive 4mA directly from my arduino? Maybe I'm just being too conservative.