It’s time to start the ball rolling. The Disaster project has been completely idle for the past couple of months. I’m starting to run out of pinball machines to fix up, so it seems like I have more time to put back into Disaster. Here’s the current status of the design.
As you may remember, the design is modular and split into three different types of cards: solenoid drivers, input boards, and LED driver boards. The LED driver boards use the SPI interface with a latch signal. No processor and all the code is on the main controller, so essentially they are done.
The solenoid driver boards drive eight solenoids, and can use the eight inputs on the board to kick the solenoids. This gives them very little latency since it is all on the same board. They can be configured to report back to the main controller when a solenoid has been kicked. This allows the main controller to poll the solenoid boards at its leisure, and add up the score. The main controller can also send commands to get the solenoids to kick. This allows auto re-injection for multiball, let’s the main controller hit the flippers for ball search, and all sorts of other cool features. (It also increases testability since a test can be run to kick all the solenoids.) Each solenoid can be configured so when it kicks it clears itself (one-shot style), or continues to be held with reduced power using a PWM. The control bits sent from the main controller can be persistent, or can be automatically cleared to reduce the amount of communication needed. The input switches use a software filter to insure that “noise” doesn’t cause inadvertent triggers of the solenoid. That firmware is complete.
Last card is the input card. It has sixteen digital inputs that can be read from the main controller. This board also uses software filtering. That firmware is complete.
The main controller sends a command to discover the boards. This allows the main controller to verify the cards are correctly attached and reduces the chance that something is misconfigured. This is also complete, and the design can support up to 16 of each type of these boards.
I’ve decided to completely drop the main controller and implement it on the Raspberry Pi. Since I last visited the Pi, it turns out that many of the functions that I needed can be supported by the base hardware. This would reduce cost even further. My design requires an RS232 interface and a SPI interface. Both of these are provided on the external interface pins. The last thing that I need is a 3-axis accelerometer. The Raspberry Pi also brings out an i2c interface, so I should be able to make a small board for the accelerometer, and to switch between 3.3V logic and 5V logic.
The only thing that I worry about is the real-time features that I need, but since my design moves most real-time aspects to the embedded controllers on the input card/solenoid driver cards, that should not be an issue. It should also reduce my coding cycle because I don’t need to write one more large piece of code, and move the information from the Pi to the main controller.
What is the next step?
- Solder the boards that I have in my backpack
- Test the firmware that I’ve already written. This can be done very simply using a serial port from any PC.
- Start writing the specification for the pinball programming language (PPL). This past weekend, I sketched out the required features, but I’m sure that I’ve missed some stuff. I need to write up a couple of examples using the PPL and see if it holds together. Nothing shows weaknesses in a language better than trying to use it to implement things. My next entry will probably be on that.
That’s it for this week. As soon as I get the beginning of the PPL down, I’ll be hoping that somebody will comment on it. It is meant to be used by people who are not “programmers” but are enthusiasts. I think I have some good ideas, but it needs to make sense to other people, not just me.