Offline
UK / FR

Wow, yeah well done, this is looking really good. I agree its maybe worth trying interrupts for the inputs? Also if i remember right the arduino bootloader does maybe add a bit of overhead to the code, which maybe could cause it to drop some bits?

Another thing could be trying direct port manipulation instead of sequential digitalReads. Think that's a bit faster, not sure how its done on teensy.

Sounds like you're on the right track though, thanks for sharing your progress and posting your code etc. Video capture without an FPGA is very exciting!

Offline
CA

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)

Offline

I wired up my board today and tried out my code.  I was getting bogus data, so I took a step back and connected Clock and HSync to two interrupts and wrote a simple program which counted the number of clock pulses between interrupts.  I was getting inconsistent numbers around 50 or less, whereas I would have expected a solid 160.  It seems that the Teensy simply isn't fast enough (i.e, calling the ISRs uses up too many clock cycles), at least when using TeensyDuino.  I was running at 96 MHz.

I think the best option at this point is to try writing some code which doesn't use the Arduino libraries.

Edit: I just had another look at Craig's NintendOscope page.  His XMega in fact only runs at 32 MHz, but he uses SPI.  It's probably worth trying SPI on the Teensy, even though Craig uses two SPI buses (one for each data bit) and the Teensy has (as far as I know) only one.

Edit again: Another option might be to use DMA to get the data into the teensy.

Last edited by rvan (Apr 19, 2014 6:02 am)

Offline
CA

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 sad

Offline
CA

The idea I'm going to look into once I get home from work is to reduce the baud rate. Maybe it's a stupid assumption but I think that 4M baud rate takes quite some clock cycles. I'll let you guys know... I'm writing it here in case someone more competent reads it and verifies I'm on the right track (or otherwise).

Offline
Melbourne, Australia

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."

Offline
CA

Nice. Where are we losing the clocks then... I mean, 96Mhz, how much time it takes to read data and send it to PC...

Offline
clovis CA

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

Offline
Melbourne, Australia
friendofmegaman wrote:

What else can be done to optimize the code I don't know yet sad

this might help?

http://www.seanet.com/~karllunt/bareteensy31.html

Offline
friendofmegaman wrote:

Nice. Where are we losing the clocks then... I mean, 96Mhz, how much time it takes to read data and send it to PC...

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;
        }
    }
}
Alley Beach wrote:

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

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)

Offline
CA
rvan wrote:

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.

Let us know the results, because in theory I don't see how this is faster. The Arduino sketch is merely a wrapper for what you've written. It puts contents of setup() to main() and the contents of loop() inside the  for(;;) loop in main. Of course I might be wrong smile

Offline
CA
Alley Beach wrote:

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

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

Offline
Michigan

I have another project using one of the Teensy's so once mine arrive, I'll jump in to this mess.

Offline
Michigan

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....

Offline
CA
Jazzmarazz wrote:

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....

Yah, it was just a quickly hacked PoC code (that didn't even work), but you're right I need to clean it up and comment.

Offline
Michigan

Pardon me for doing so, but I organized your program a tiny bit. It 'should' do exactly as it did before (working or otherwise). Can you verify this for me?
Have you changed it since this post?:
http://chipmusic.org/forums/post/206481/#p206481

http://pastebin.com/DFt5dEA3

Last edited by Jazzmarazz (Apr 24, 2014 10:46 pm)