Offline
CA
Jazzmarazz wrote:

I was thinking that your baud was a little crazy. Care to reduce it to something more common?
No, I have not benchmarked a teensy.

4000000 is fairly common. But according to rvan you can use 1 and will go on maximum speed.

Offline
Michigan
friendofmegaman wrote:
Jazzmarazz wrote:

I was thinking that your baud was a little crazy. Care to reduce it to something more common?
No, I have not benchmarked a teensy.

4000000 is fairly common. But according to rvan you can use 1 and will go on maximum speed.

Is it common? I guess I just haven't dealt with it before. I normally work in the 9600 - 30K area. tongue

Offline
Melbourne, Australia
friendofmegaman wrote:

Guys, have you actually benchmarked USB serial in Teensy? I'm a bit worried because of this page http://www.pjrc.com/teensy/usb_serial.html. It doesn't show very high speed which means we might need to keep our data as small as possible.

Even the very worst case benchmark on that page of 639 kbytes/sec (654336 bytes) using your current frame size of 5760 bytes would still mean 113.6 frames per second, so what's the problem?

Offline
CA
uXe wrote:
friendofmegaman wrote:

Guys, have you actually benchmarked USB serial in Teensy? I'm a bit worried because of this page http://www.pjrc.com/teensy/usb_serial.html. It doesn't show very high speed which means we might need to keep our data as small as possible.

Even the very worst case benchmark on that page of 639 kbytes/sec (654336 bytes) using your current frame size of 5760 bytes would still mean 113.6 frames per second, so what's the problem?

There's no problem smile Just checking and pointing out that we need to pack our data and can't afford 144x160 byte array.
Also it's not 5760 bytes anymore. We need error-free frame delimiter so it's gonna be 7680, i.e. 85 fps. I'll share the code later, need to check it first.

Offline

I really, really want you to succeed in this.. I have a project where I need a DMG composit out thou. I'm resorting to the GBA/videothingie mod, right now. Not ideal...

Offline
Michigan

Well, we (friendofmegaman) has a long way to go, but this should be an easy build-in solution for it once taht time comes:
https://code.google.com/p/arduino-tvout/

Offline
CA

Can anybody explain me the following:

So I set up interrupts for CLOCK, HSYNC and VSYNC.

Inside the interrupt handlers I simply send data to PC.

Serial.write(pixel) for CLCOK,
Serial.write(0xE0) for HSYNC and
Serial.write(0xF0) for VSYNC

On the PC I count how many there are pixels per line and lines per frame.

There are 15 (in average) pixels per line
And 144 lines per frame.

Why is that?

Is it because I'm loosing bytes in the serial communication? But shouldn't all the data be buffered and the delivery guaranteed?

If that's the case, then even with the sketch so short it could be a T-shirt print we're missing 90% of pixels (15 our of 160). Which means that something is very wrong here.

Oh, I can actually check that by setting a counter inside the uC and receive only byte count.... be back in 10 mins...

Offline
CA

I can only detect 70 clocks between two HSYNCs...

The sketch:

#include <avr/io.h>
#include <avr/interrupt.h>

const int pVsync = 2;
const int pClock = 3;
const int pData0 = 4;
const int pData1 = 5;
const int pHsync = 6;


volatile unsigned char pixels_in_line = 0;

void setup(){
  Serial.begin(1);
  
  pinMode(pClock, INPUT);
  pinMode(pHsync, INPUT);
  pinMode(pVsync, INPUT);
  pinMode(pData0, INPUT);
  pinMode(pData1, INPUT);

  
  attachInterrupt(pClock, readClock, FALLING);
  attachInterrupt(pHsync, readHsync, RISING);  
}

void loop() {}

void readHsync(){
   Serial.write(pixels_in_line);
   pixels_in_line = 0;
}


void readClock(){
  pixels_in_line++;
}

The hex dump I receive on PC side:

000009a0  45 45 41 44 44 44 44 44  44 44 43 44 44 44 44 44  |EEADDDDDDDCDDDDD|
000009b0  44 44 44 44 44 44 44 44  44 44 44 44 44 41 44 44  |DDDDDDDDDDDDDADD|
000009c0  42 41 44 44 44 44 41 44  44 44 44 44 44 44 43 44  |BADDDDADDDDDDDCD|
000009d0  44 44 44 45 45 45 46 46  46 45 46 44 44 45 45 44  |DDDEEEFFFEFDDEED|
000009e0  44 45 44 44 44 44 44 44  44 44 44 41 44 44 44 44  |DEDDDDDDDDDADDDD|
000009f0  44 44 44 44 40 44 44 44  44 44 44 44 43 44 44 44  |DDDD@DDDDDDDCDDD|
00000a00  42 42 44 44 44 43 44 44  44 44 44 44 44 44 44 44  |BBDDDCDDDDDDDDDD|
00000a10  44 44 44 44 44 44 44 44  44 43 44 44 44 44 44 44  |DDDDDDDDDCDDDDDD|
00000a20  44 44 40 46 46 46 46 46  46 46 46 41 45 45 45 45  |DD@FFFFFFFFAEEEE|
00000a30  45 45 45 43 44 44 44 44  44 44 44 44 44 44 44 44  |EEECDDDDDDDDDDDD|

Please tell me there's an error in my code that gives me this discouraging results sad

Last edited by friendofmegaman (Apr 25, 2014 3:50 am)

Offline
CA

Conjecture:

I'm missing bits because the CLOCK handler for the previous interrupt hasn't finished executing.

Offline
Michigan

There is nothing inside of loop. I don't think...your code does anything at all right now. :S

The 4's could be some high-impedance / capacitance on the serial wire or some nonsense like that. Then again, I could be well off-base.

Last edited by Jazzmarazz (Apr 25, 2014 4:45 am)

Offline
CA
Jazzmarazz wrote:

There is nothing inside of loop. I don't think...your code does anything at all right now. :S

The 4's could be some high-impedance / capacitance on the serial wire or some nonsense like that. Then again, I could be well off-base.


Loop is empty because the workflow is based on interrupt handlers. And they work fine otherwise I wouldn't get any data. In fact I tried to put some constant value there and I can see it appear in my hex dump. So this is not the problem. The code works just fine. And it seems that the only explanation of missing clocks is one I mentioned in the previous post.

Offline
Michigan
friendofmegaman wrote:
Jazzmarazz wrote:

There is nothing inside of loop. I don't think...your code does anything at all right now. :S

The 4's could be some high-impedance / capacitance on the serial wire or some nonsense like that. Then again, I could be well off-base.


Loop is empty because the workflow is based on interrupt handlers. And they work fine otherwise I wouldn't get any data. In fact I tried to put some constant value there and I can see it appear in my hex dump. So this is not the problem. The code works just fine. And it seems that the only explanation of missing clocks is one I mentioned in the previous post.

Oh! I need to learn about interrupts still. I have yet to need to use one, so I never read about them. tongue

Offline
Michigan
friendofmegaman wrote:

I can only detect 70 clocks between two HSYNCs...

Do you mean between two Vsyncs? Looking back at your "logic-analysis" vsync seems to offer more of a set pattern than the clock or hsync. How many clocks should you be detecting?

Offline
CA

So my final report for you (because after that I'm entering demoralized state again):

I wanted to determine how many clocks I can detect at very best.

I set up two interrupts VSYNC and HSYNC.

When VSYNC comes I just write frame delimiter to serial.
When HSYNC comes I run a 160 step loop (that's it, no checks, no conditions just a loop) and send data to PC.

And I get no more than 15 clocks between VSYNC signals. So unless I find better explanation I consider Teensy (for whatever reason) simply not to be able to handle the data. Because I've no idea how can I optimize that.

Offline
Michigan

1am...time for the demoralized to go to bed....
Maybe someone can shed light on this in that meantime since you shared all of your various bits of code. The Teensy code is so "dumb" (having only a few dozen lines) it can't possibly be wrong!

good luck

Last edited by Jazzmarazz (Apr 25, 2014 5:24 am)

Offline
Melbourne, Australia
friendofmegaman wrote:

I can only detect 70 clocks between two HSYNCs...

The sketch:

#include <avr/io.h>
#include <avr/interrupt.h>

const int pVsync = 2;
const int pClock = 3;
const int pData0 = 4;
const int pData1 = 5;
const int pHsync = 6;


volatile unsigned char pixels_in_line = 0;

void setup(){
  Serial.begin(1);
  
  pinMode(pClock, INPUT);
  pinMode(pHsync, INPUT);
  pinMode(pVsync, INPUT);
  pinMode(pData0, INPUT);
  pinMode(pData1, INPUT);

  
  attachInterrupt(pClock, readClock, FALLING);
  attachInterrupt(pHsync, readHsync, RISING);  
}

void loop() {}

void readHsync(){
   Serial.write(pixels_in_line);
   pixels_in_line = 0;
}


void readClock(){
  pixels_in_line++;
}

the Serial.write might be slowing down your interrupt - maybe try storing those values in an array or something instead, and then Serial.write them out once you've collected a certain amount to see if that has any effect on the count?