Offline
CA

I thought about interrupts as well. I don't see any difference in terms of performance between two ways of processing the signals, however I'm a bit concerned with cascading interrupts. It will probably work out fine, not sure though.

As for dead time I though to put the condition something like if (line<144 && offset<160)

Sending frames or pixels does not make big difference either with teensy. It's rather matter of taste. I just prefer taking as much as possible from the microcontroller. On the other hand, we may need to save clocks and outsource frame building to the PC.

Anyways experiments will show what's better.

Offline
Michigan

bump

Offline
CA

My Teensy will arrive tomorrow and I can finally start experimenting. I ended up purchasing Teensy 3.1 because it's the most powerful one. We'll see how much I'll be able to do with it.

In the meanwhile I prepared this breakout port:

It basically provides LCD pins 3 to 19. I decided to take out all the pins required to drive the the front PCB display and get input from buttons (already tested and it works).

Last edited by friendofmegaman (Apr 16, 2014 4:09 am)

Offline
Michigan

Nice. I got a 25pin Sub connector mounted to one of mine at the bottom. It is just for external button control.
Keep us updated.

Offline
CA

So, my first experiment was a failure.
The objective was to capture a screenshot of LCD. What I did:

1. Checked how FlashingLEDs guy processed bit data to build the screenshot (here)
2. Implemented it in the Teensy
3. Collected frame data via serial
4. Tried to visualize it

And here's the result:

and it was supposed to be Tetris sad

I receive consistent data on the PC - each frame has 144*160 pixels, which is a good sign. Now I need to analyze the results thoroughly and double check everthing. I definitely am missing something here.


My Teensy code (rather dirty since I was too eager to see the result, didn't have time to do it by the book):
http://pastebin.com/1GUhf2nR

On the PC  side I used pyserial to collect data:

import serial

port = '/dev/tty.usbmodem34521'
speed = 4000000
buflen = 100
ser = serial.Serial(port, speed)

fd = open('screen_data.bin', 'wb')

try:
    while True:
        data = ser.read(buflen)
        fd.write(data)
except KeyboardInterrupt as e:
    print 'Shutting down'
    fd.close()
    ser.close()

Then I parsed it and built a scatterplot using matplotlib: http://pastebin.com/AS4uesLh

Hopefully I'll find some time this week to play with it more, but currently I'm a bit loaded with my actual work. Anyways if you guys have ideas what is wrong with my code I'd appreciate if you shared. Cheers!

Offline
CA

Here's also a fragment of hex dump:

00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000a0  00 c0 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 c0 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000110  00 00 00 00 00 00 00 00  00 c1 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000140  00 24 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |.$..............|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 c0 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000190  00 c2 03 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001e0  00 c0 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

This is why I get black screen (apart from the stripe on the left). Almost all the pixels are zeroes. I think the problem is timing. The clock signal is falling edge, but maybe I'm reading data bits too soon... EDIT Nah, it's a stupid assumption - falling edge is falling edge. Ass!

Last edited by friendofmegaman (Apr 17, 2014 10:37 pm)

Offline
CA

Ok, I had spare 10 minutes at work and started analyzing the problem.
First things first I downloaded the dataset provided by FlashingLEDs (here) and tested my algorithm ont it. I found a couple of minor errors, but for the most part it works fine.

So the problem is either I don't read correct data from the Teensy for some reason or my uC code has some error I haven't noticed yet. We'll see...

Last edited by friendofmegaman (Apr 18, 2014 12:04 am)

Offline
CA

I confused pins in my Arduino code. However simply fixing them didn't solve my problem so I started in depth analysis smile

I threw together a dirty script that would turn a Teensy in sort of a logic analyzer.

Here's the result:


Data looks pretty reasonable. We see CLOCK, DATA0, DATA1 go high pretty frequently
HSYNC on each new line, VSYNC on each new frame

It appears that I was getting most of 0 bytes because of the way I pack data in the Teensy. Now I need to resolve that and hopefully I'll get a frame. If it won't work after that I'll get into state of demoralization.

Offline
CA

In the previous pictures actually CLOCK should be swapped with DATA1, but that doesn't change the point.

I double checked the way my bits are packed - it's fine. Now I tend to think that I push data to serial when the frame is not ready yet. I have no idea why is that...

Offline
CA

Well... I see that Teensy only reads 5-6 pixels of each line. As if bloody HSYNC comes too frequently. Don't know what the fuck can I deduce from that sad

Last edited by friendofmegaman (Apr 18, 2014 5:18 am)

Offline
Melbourne, Australia

You could try ignoring HSYNC and just start a new line manually every 160 pixels? I also wanted to suggest sending the data after the 144th line where it looks like there is a nice gap in the timing, rather than on VSYNC?

Offline
CA
uXe wrote:

You could try ignoring HSYNC and just start a new line manually every 160 pixels? I also wanted to suggest sending the data after the 144th line where it looks like there is a nice gap in the timing, rather than on VSYNC?


Good point, however I'm receiving the full frame all right, so this part seems to be fine.

As for ignoring HSYNC... not sure it's a good idea it should work as is. It seems that Teensy clock can't handle it. But hell it's 96 MHz, it should suffice to take care of 4MHz data.

Offline
CA

So when decrease the clock speed on Teensy I observe worse readings of HSYNC... It appears that clock speed is still not big enough...

Last edited by friendofmegaman (Apr 18, 2014 6:44 am)

Offline
CA

Currently I see two directions of research:
- Writing C code directly without Arduino
- Optimizing or overclocking the board

But right now I'm demoralized so fuck it me goes to bed

Offline

Good work so far, friendofmegaman.

I've started writing some Teensy code which uses interrupts, and hope to have my DMG wired up tomorrow.  I'll also test your code on my setup once the hardware side is ready.

Offline
CA
rvan wrote:

Good work so far, friendofmegaman.

I've started writing some Teensy code which uses interrupts, and hope to have my DMG wired up tomorrow.  I'll also test your code on my setup once the hardware side is ready.

Awesome! I'm curious to know how interrupts will do smile