chipmusic.org is an online community in respect and relation to chip music, art and its parallels.
You are not logged in. Please login or register.
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.
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. 
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?
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 
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.
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...
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/
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...
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 
Last edited by friendofmegaman (Apr 25, 2014 3:50 am)
Conjecture:
I'm missing bits because the CLOCK handler for the previous interrupt hasn't finished executing.
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)
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.
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.
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?
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.
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)
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?