DMG/Pocket video capture with Arduino or Teensy? (Page 3 of 16)

I counted the average number of clocks between HSYNC's. It's approximately 800 and 800/144 = 5.5 which is exactly how many (in average) pixels I read for each line.

Little piece of hope is that there's something wrong in my code/setup because the picture I get doesn't make sense even for these 5 pixels per line (it's supposed to be the piece Tetris' frame).

As rot suggested I could optimize the thing by using plain C without Arduino overhead. I've no idea yet how much of overhead Arduino's ARM compiler puts there, but for some AVR chips it slows down up to 10 times.

Last edited by friendofmegaman (Apr 18, 2014 10:38 pm)

I briefly looked at direct port access to read pin value like so (PIND & (1<<2))?1:0;
In terms of the .hex size it's no different from digitalRead(). What else can be done to optimize the code I don't know yet

Baud Rate isn't going to change anything with a Teensy:

"Data is always transferred at full USB speed. This is merely the setting selected by the PC or Macintosh software, which is not used by USB. You do NOT need to constrain your transmission to this rate. However, many serial communication programs are coded very inefficiently because the programmer assumes "slow" data. You can easily overwhelm these programs, even when running on very fast machines, if you sustain full USB speed transfers!

Likewise, the host does not enforce this baud rate upon the software that is sending data to you. However, unlike real serial communication where you could lose data if you do not read fast enough, USB will always buffer data until you have read it. If the software does not implement timeouts, you may read at any speed and never lose a byte."

a pi wouldnt work?
I have a beaglebone and an XMOS pcb i can donate if you think you can make it happen on one of those

With my simple testing code (as follows) I think it was the ISR being called which took too many clock cycles (I recall reading 10 cycles of overhead somewhere).  Getting away from the Arduino code will hopefully reduce this.

#include <WProgram.h>

#define CLOCK_PIN 23
#define HSYNC_PIN 21

volatile char clk_cnt = 0;
volatile bool got_hsync = false;

void ISR_clock() {
    clk_cnt++;
}

void ISR_hsync() {
    got_hsync = true;
}

int main() {
    Serial.begin(1); //Always runs at Full Speed.
    pinMode(CLOCK_PIN, INPUT);
    attachInterrupt(CLOCK_PIN, ISR_clock, RISING);
    pinMode(HSYNC_PIN, INPUT);
    attachInterrupt(HSYNC_PIN, ISR_hsync, RISING);
    
    for(;;) {
        if(got_hsync) {
            got_hsync = false;
            Serial.write(clk_cnt);
            clk_cnt=0;
        }
    }
}

If any of these have two SPI buses, I am quite sure it would be doable (at least with the Raspberry Pi or BeagleBone; I'm not familiar with the XMOS).  Even without, the extra clock speed would probably make things magically work, at least when not running an OS (or if using an RTOS and a low-level API).  I would like to eventually have this running on something quite small, though (not that a BeagleBone / Raspberry Pi is that big).

At least at first glance, this seems like almost exactly what I've been hoping for, thank you.  It is for a Windows system, but should be easily adaptable.

Last edited by rvan (Apr 23, 2014 9:36 am)

It probably would, but until we know why exactly a 96MHz microcontroller cannot handle LCD data it's just trial and error
Thanks for an offer though

Looking through your code and ... I have a few comments.
1. Not naming your pins drives me nuts and I worry that just having them numbered could mix them up with variables.
2. Pins default to input, so your for pinMode for-loop is unnecessary. 
3. And as always, COMMENT UR SHIT! haha....