Let's Talk Pinball

Status
Not open for further replies.

Geomancer

Active member
I'm embarking down the road (I hope) of building a pinball machine. I'm planning on using a Teensy 3.6 as the heart of the project. I've never done something as complex as this before though and could use some advice on potential pitfalls or better solutions.

So, first of all, the general requirements:
- Play two .WAV files simultaneously. One is the music (couple minutes), the other is sound effects (couple seconds).
- Drive a DMD (Dot Matrix Display). For pinball, this is a 128x32 monochrome display that is driven similar to a video feed. There is no memory and no buffer. You have to refresh the display constantly at a rate of 70+ Hz. It is not a 'standard' interface (as far as I know) like I2C or SPI. See Vishay part number LEE-128G032B-1 if curious. Part of it does look like SPI, but I don't know if I could sync up all the other signals up to using the built-in SPI modules.
- Read in an 8x8 switch matrix. The simple way would be just a shift register setup. However, it's important that switch closures never get missed. I'd love to offload this to a TCA8418 ... but I'm unwilling to go down the road of soldering QFN's. There are other chips that are similar (like TCA8418E) but they're BGA's which I'm also not going to touch. Surprised I can't find anything similar in a QFP.
- Drive an 8x8 LED matrix. These will likely be > 3.3V in order to get the brightness needed to show up through the playfield inserts. That means high side and low side transistor switching. Like the switch matrix, probably use shift registers to drive power FETs.
-Drive solenoids. 50V, high power solenoids. Probably at least 16 of them, but I'm not sure if I'll need that many. Still, again, probably shift registers driving power FETs.

That's mostly it, I think.

I've already played with and have working a sketch that plays two wav files off the built-in SD card going to an I2S audio chip.

For the DMD I'm concerned though on the feasibility of the Teensy being able to handle everything. This seems like it would be the most processor intensive of the tasks. Or is it a lot easier than I'm picturing? I'd plan on storing bitmaps on the SD card and reading them in. Animations would be a series of bitmaps played at a relatively low framerate (but the display still needs refreshed at 70+ Hz). I'd also have to create an alphanumeric font.

The other thing I worry about is reading the switches. You really can't afford to miss any switch reads. They'll also be pretty 'quick', at least in human terms. Millisecond range? Plus also have to deal with switch bounce.

I've thought about 'offloading' one or more of these functions to either a co-processor or an FPGA. Digilent makes a nice Spartan 6 FPGA in a DIP form factor. Think of a Teensy, but with an FPGA instead of an Arm (but no easy to program software like Arduino). It would be great if I could keep it in one chip though.

The coils also have to be treated with respect. They absolutely need to be turned off in a short period of time (milliseconds) or they'll burn up. I'll probably enable the watchdog timer.

Anyways, any glaring red flags or things I can look into that may simplify implementing these features?
 
Given the $ cost of the total project a couple of co-processors is probably the way to go. The Teensy3.6 can probably do all these things (see the C64 emulation project) but theere will be a whole bunch of interaction and contention going on that would need worst case modeling and testing done to keep sound clashing with the display and vice versa.

Another advantage of co-processors is that you can break the project down into chunks, get the baseboard working, get the inputs working and then leave that hardware along and then that code/hardware is left alone while sound/display gets added.

Physical build wise all the wiring back to a single Teensy is hard. If you have core CPU plus one/two slaves you can greatly simplify the wiring of it all, and hopefully have some simple low pin count plugs holding it all together.

When building a one off project always be careful heading down the path of the right answer for mass production (lowest part count/cost) over the better path for a 'just for fun' project where you want to spend time playing it rather than iterating through designs to swap a 10c IC in place of $1 one.

Re matrix inputs, see https://www.pjrc.com/teensy/td_libs_Keypad.html

That said having built a couple of matrix input and outputs, the wiring for this can become a nightmare quite fast so anything you can do to keep lighting/solenoid/switch inputs short and easy to work with is a good thing. In a perfect world each field object would have a slave micro controller embdedd managing the IO and everything would connect via a generic power and data bus making wiring a case of buying a whole bunch of generic cables in the right lengths.
 
Thanks for the tips!

I'm more and more leaning towards using a couple PICs or the FPGA.

One PIC for the switch matrix, and the other for the display interface. Having one for the display interface would allow me to emulate having a video buffer so I wouldn't have to keep generating a frame 70+ times a second when the information is not changing anywhere remotely close to that fast. I'd use PICs because I already own a PicKit 3 for programming them. Using more Teensy's would just be extream overkill.

The FPGA would make for a nice single chip solution for the peripherals, but my VHDL is a bit rusty.
 
I have example code for generating DMD signals mimicking various pinball platforms up on GitHub. These were for debugging and aren't at all efficient, but might help as a proof of concept. You'll want to use one of the SPI ports to send the dots out in a real implementation.
 
I ended up going with a pair of 64x32 RGB LED panels. The price was right on Amazon at only $26 each. The Vishay panels would of been 3x the cost. The Vishay panels do have advantages though. One being their power usage is vastly lower. The other is being monochome it doesn't take as much effort to refresh the screen.

These LED panels are the same kind sold by Adafruit, but you can buy everywhere else for a lot less. The main issue with them is they have 6 data lines making offloading the shifting of those bits to a SPI bus not possible (that I know of). I found a library for the panels, but it's real rough. May be enough to do what I need though. Problem is whenever the Audio library loads a new WAV file there is a visable glitch on the display. As of now, I'm planning on just using two Teensy's for this project. One will run the game and audio, the other will do the display. With double the pins avalible, may have the display teensy do some other functions too like read the switch matrix.
 
The SmartMatrix library is as good as you're going to do for those panels. It uses chained DMA transfers to fill the data and address lines. I'm not shocked to hear you're having stuttering trying to play audio at the same time though, even if you're using that already, it's a lot of data if you're trying to update quickly enough to have 8bit per channel color and a decent frame rate. Depending on your needs you might want to reduce it to 5 or 6 bits per channel.

I have a lot of experience using the LED panels for pinball if you have any questions.
 
Status
Not open for further replies.
Back
Top