Forum Replies Created
-
Posts
-
Hey needle,
This new Chumby device that allows internet content on the TV is getting a lot of attention:
http://hackaday.com/2011/09/12/chumbys-new-netv-makes-almost-any-tv-into-an-internet-connected-device/I’m going to Maker Faire in NYC this weekend and I see that these Chumby guys are going to demo tweeting to a TV using their device.
I hope you can blog about your project soon because I think it’s way more awesome to tweet to a TV using a cheap Arduino, Ethernet shield and Video Experimenter. Way more retro and cool!
Oh, I see. That sketch you tried is an original example from TVout and doesn’t have overlay capability. Glad you are up and running now. Have fun.
If you only had one board and it was behaving this way, I’d say you had a bad solder connection, but since you have the experience with two boards, something else is going on. And you’ve tried it on several TVs….
Your sketches have both of these funcitons, right? And you are calling initOverlay() from your setup function?
// Initialize ATMega registers for video overlay capability.
// Must be called after tv.begin().
void initOverlay() {
TCCR1A = 0;
// Enable timer1. ICES0 is set to 0 for falling edge detection on input capture pin.
TCCR1B = _BV(CS10);
// Enable input capture interrupt
TIMSK1 |= _BV(ICIE1);
// Enable external interrupt INT0 on pin 2 with falling edge.
EIMSK = _BV(INT0);
EICRA = _BV(ISC11);
}
// Required to reset the scan line when the vertical sync occurs
ISR(INT0_vect) {
display.scanLine = 0;
}
Hmm. That looks like a window on a computer screen….not using a TV? How are you getting the composite video output to your computer?
This is intended for use with TVs which are much more tolerant to the imperfect sync generated by the TVout library. Some people have reported problems with USB-based video-to-computer adapters.
Sorry for the slow response. There are several things I needed to do in order to get your application working. Nice application, and nice coding! The updated code is attached.
First, add and remove layers from the draw() method like this. Keep track of the colorWheel Layer in a variable so you can find it later. Your mouseReleased() method can simply set the colorWheelDisplayed variable appropriately, then draw() will act on it.
void draw() {
if ((colorWheelDisplayed) && (colorWheel == null)) {
colorWheel = new ColorWheel(this);
layers.addLayer(colorWheel);
} else {
if ((!colorWheelDisplayed) && (colorWheel != null)) {
// need to remove the color wheel layer.
ListIterator li = layers.getListIterator();
while (li.hasNext()) {
Layer l = (Layer)li.next();
if (l == colorWheel) {
li.remove();
colorWheel = null;
}
}
}
}
...
Secondly, your buttons need to draw themselves on the ColorWheel layer instead of on the main drawing surface. So in the ColorWheel draw() method, call display() like this:
redb.display(this);
greenb.display(this);
...
And display() becomes this:
void display(Layer l)
{
l.stroke(255);
l.strokeWeight(0);
l.fill(currentcolor);
l.ellipse(x, y, size, size);
}
One more thing to worry about. To avoid a race condition with event processing, add this to the beginning of your mouseClicked() method:
void mouseClicked() {
if (!setupDone) {
return;
}
…where setupDone is a boolean that you set to true at the end of ColorWheel setup.
The Propeller Backpack is not for use with Arduino. It is Propeller-based and is a standalone solution. Propeller chips have video ability built-in. The downside is that you have to program them in the goofy SPIN language instead of C/C++. I think this has prevented Propeller from really taking off in the hobbyist world like Arduino, even though Propeller is a more powerful MCU. Other thoughts?
I don’t know anything about the PAL constants — I didn’t write this code. It’s TVout written by Myles Metzer. I just added the overlay.
VCC (5 volts) and GND. So the middle pin measures 0-5V depending on position.
I used analog pin 2 because the Ethernet Shield uses analog 0 and 1, and I wanted the VE to be compatible with it.
Yes, thanks Andrey for finding this bug. I will do some more testing of the example projects to ensure that they all still work — I think that this bug explains why I always found closed captioning data on line 13 instead of line 21 where it should be. The line count was being reset over and over again until the vsync line went high.
Then I can correct all the example code.OK, I think I know what you meant by the frames not being counted and TV.millis() not working. Since the INT0 interrupt fires whenever vsync is low, then that interrupt handler fires over and over during the whole vertical blanking interval (instead of firing only once on the falling edge). So no other code is being run during the VBI. If this is the case, it’s amazing that anything worked well at all….
Andrey,
Nice catch. So the code should be:
// Enable external interrupt INT0 on pin 2 with falling edge.
EIMSK = _BV(INT0);
EICRA = _BV(ISC01);
When the code was wrong, the INT0 interrupt was being generated when the pin was LOW (instead of falling edge) since both the ISC00 and ISC01 bits were unset. Agree?
Does the overlay work ok with this modified code? (Believe it or not, I have no Video Experimenters at the moment because I sold them all).
I’m not sure I understand how this bug effects counting of frames…
