Serial communication bandwidth is “precious” in the OPP environment. The serial commands are designed to reduce the amount of necessary commands that are needed to control the pinball machine. The two big heavy hitters are reading status, and controlling lights. Both of those things happen all the time so efforts were made to reduce this traffic if possible.
Right now the status of the inputs are polled constantly. There has been a request to change the firmware so that it only sends updates when an input changes. That would certainly reduce the amount of traffic, but it may come at a terrible price. Right now, if a message gets corrupted, it is simply dropped. (all serial messages contain a CRC, so that they can detect if an error has occurred and just ignore those messages with bad CRCs). If there is a parameter that configures the boards to create messages only when inputs are changed, there is the possibility that a change message could get corrupted and dropped. At this point, I have not seen any evidence of any serial communication corruption that has not been caused by overflowing the serial port buffers. That may mean that my fears are unfounded, and I can just ignore them. Of course, it heavily depends on how people wire their machines.
Back to the other heavy hitter on the serial port line. It is turning bulbs on and off. To reduce that bandwidth, the OPP firmware supports commands that tell lights to blink slowly or blink quickly. After a blink command is sent, the firmware makes the updates automatically so the pinball framework processor doesn’t have to bother sending those commands. Here is where the problem is…how to synchronize all that blinking because each OPP board has its own processor with its own crystal running at its own frequency. The blinking became very noticeable as the pinball machine ran for a half an hour or so and the state machines drifted apart between the different cards.
Predicting that this would be a problem, the hardware supports a Synch pulse that goes between the boards. (Synch of course stands for synchronize). Here is a description of how the synch pulse works with the new firmware.
When the inventory command is sent, the first OPP board suddenly realizes it is the first board and starts driving this signal. (Nobody can drive the signal before because of the possibility of two processors driving the signal. That’s not good because one may be trying to drive a high value, while the other may be trying to drive a low value, and that forces the processor driving the low value to sink the maximum amount of current that the other processor can source). The first board drives the signal high for a short period of time. All other boards read this signal and can use the rising edge of the signal to synchronize their internal LED state count, so all of the boards are at the same state in their state machines. Even if the crystals are off by 60 ppm, or so, the processors continuously re-adjusts to the signal produced by the first board. Nice and simple.
In the repository, this will be image version Gen2.rev0.2.0.2.cyacd to support this new functionality. On to the next item on my list.