To add more functionality to the Propeller an ATMega168 was added to the design. The Propeller communicates via I2C (on the same bus as the EEPROMS) to the ATMega168. The ATMega168′s function is to provide dedicated servo control and analog input for the propeller. Since servos have to constantly PWM controlled the Propeller has to dedicated an entire cog to just maintain servos. Using the ATMega168 to off load this tasks frees up lot of resources for the Propeller which will allow for better animations and smoother kernel cycles.
Category Archives: Pinball
Tommy System Schematic Update #3
Tommy System Schematic Update #2
I fixed the EEPROM addressing issue. Since the EEPROMs are addressed via I2C protocol you have to set there addresses via the pins A0, A1, A2. Previously I had these all to VSS or GND which would mean all there addresses where 000.
Added the SD Card to the Parallax Propeller to store audio files. Took longer then expected to make the footprint and get the part correct in eagle.
Power will come into the board via 4-Pin Molex connectors much like on a PC power supply.
Currently have TLC5940 16 channel LED drivers on the board but these will be changed to WS2803 Chips as they use 3 less I/O lines (5 vs 2). These will be used exclusively for RGB LED lighting. I am planning on being able to hook up 18 RGB LEDs to the board.
Tommy System PCB in the works.
OPTO Transmitter PCB Done
Tommy Pinball System Update
For those that don’t know, Tommy is the code name for a propeller based pinball platform. It will be an all in one system that is designed to be modular and easy to use.
Ben has been working on the code and is getting the test hardware going.
He has most of the system working now. In the picture, Ben is working on the switch matrix and DMD driver part of the code as there where conflicts earlier.
This weekend I will be starting the PCB design. I should have rough version of the prototype PCB drawn up by Monday.
Pinball OPTO Receiver PCB
Tweaking the 128×32 LEDDMD Verilog
There was a few problems with the code for the 128×32 LEDDMD. Every so often there was flickering at random spots on the screen. This was because of the way the display memory was updated. I already fixed it by putting a dummy state at the end of the display memory update. Doing so actually increased the speed that data could be sent to the FPGA. There is no waiting between the Latch pulls.
The last problem is that there is some slight ghosting on the screen. Due to the way the screen updates it looks like the Column data is updating slightly before the rows are updated. Because of this you get a ghost effect on the opposite side of the screen that is up one row.
I think the reason why is because there is a slight delay in the rows caused by the decoders. The current plan of attack is to buffer the Column data a couple cycles before outputting.
LEDDMD 128×32 Complete
So I finally finished the prototype of the 128 x 32 Light Emitting Diode Dot Matrix Display V1.0 (LEDDMD). The protocol to write to the display is almost exactly like a shift register. There is a clock, latch, and data lines. It works in either 1 bit mode or 8 bit mode data line modes.
In 1 bit mode there is only 1 data line and in 8 bit mode this is 8 data lines. 8 bit mode enables you to clock in an entire byte of data at a time speeding up the transfer process by a factor of 8. In either mode you can do animations smoothly. All processing of the data is done on the microcontroller. The Display stores the data and takes care of running the display.
The bulk of the hardware is in the FPGA. I am using a Cyclone II EP2C8Q208C8N FPGA breakout board. There are some darlington transistor arrays that sink the current from a single row. To expand the I/O of the FPGA some decoders are used.
Here are the links to all the code:
FPGA:
Main Routine
Memory
Propeller:
Transmission Protocol and Test








