kevtrisI received some of the displays today and decided to poke around with them a little bit.
There is quite a bit of activity on start up. The I^2C bus is read for a few seconds, the fan starts and stops, and various other things happen.
Watching the data bus to the RAM/flash, they are constantly hitting the RAM. At startup, you can see what I suspect is the I^2C data being written into RAM, presumably for the dot correction.
I hooked some wires up to the back side of the control PCB and brought them out and did a little messing around. It looks like pins 3/8 on the input connector is the clock. Feeding it a 1MHz differential clock results in a similar clock emerging out of the output connector (pins 4/7). When the clock is provided, a repeating synchronous data pattern is present on pins 3 and 6 of the output connector.
If the clock is provided on startup, the output pins on the input port (pins 4/5) spit out a pretty hefty string of data shortly after power is applied. I am not sure what data is coming out, but it definitely is something. There doesn't seem to be a repeating pattern looking on the scope but I am unsure what it is.
Whatever data is fed into the Din pins (5 and 8) of the output connector seems to simply be passed through to the Dout pins (4/5) on the input connector when it's sitting there during normal operation.
The passthrough appears to be combinatorial since I can feed nearly anything in and it comes out exactly the same. The data is not sampled on the clock or anything (i.e. I can feed it a higher frequency clock and it simply passes it through).
During the startup, it switches the outputs between passthrough and internal state (during the data it sends synchronous with the input clock) then it switches back to passthrough.
The output clock appears to shut off (on the output connector) when the internal state is being dumped, then it starts up again afterwards when it's in passthrough mode.
It seems that the FPGA basically passes clock/data through unless it wants to talk to the host. I guess this makes sense.
I was thinking the next step might be to make a small breakout board to replace the SRAM/flash on here and connect it to my ROM emulator device to start substituting data and seeing what addresses are being read/written (as well as being able to dump the RAM contents). This would also let me watch the bus to see what the CPU inside is doing.
The access speed seems to be pretty fast, 25 or 50ns, so I might have to swap out the 40MHz oscillator with a 10MHz one or similar to slow it down enough so that my ROM emulator (a RAM + FPGA basically) can keep up. We'll see.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Very interesting! How do you drive differential inputs? I would like to try this.
Are you sure? yes | no
I was doing it super-ghetto. I used some 74C14's to provide it, running off of 3.3V They have poor slew rate, poor everything but it did work reliably by the looks of the output signals. I just used three of the gates- 1 inverting and 2 making a non-inverting buffer then drove N/P off of those. The oscillator was made using one of the other gates in the usual R/C configuration.
Are you sure? yes | no
OK, sounds good. I guess I can also use a 3.3 processor and generate a clock and toggle a pair of lines in opposite directions. I thought it needed some magic drivers.
Are you sure? yes | no
Can you describe the activity of the status LEDs while you are feeding in this data? An early report suggested that the 'idle' blink pattern changed when the board was receiving proper data.
Are you sure? yes | no
The status LEDs never changed their blinking. I suspect there is some kind of signature that has to be present for it to accept the data. I am hoping this signature is sitting somewhere in the parallel flash. The data coming out from Dout to the next display was a bit telling. I might try to get a scope shot later.
Tonight I will connect it to my FPGA proper maybe if I get a chance and do some actual data capture and I will have the ability to send it any arbitrary data. I did try to loop back Din to Dout thinking it might trigger a test mode (and Dout from the output connector to the input one) but no dice.
Are you sure? yes | no