Wrong interrupt in initOverlay()

[doctorandrey]

Hello!

It looks there is a misprint in initOverlay() routine – INT0 should be initialized in this rows:

// Enable external interrupt INT0 on pin 2 with falling edge.

EIMSK = _BV(INT0);

EICRA = _BV(ISC11);

ISC11 – The rising edge of INT1 generates an interrupt request.
must be:
ISC01 – The falling edge of INT0 generates an interrupt request.

I found it by trying to access to display.frames and TV.millis() – id doesn’t count frames and elapsed time, but all overlay output work fine.

Andrey

[Michael]

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…

[Michael]

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

[doctorandrey]

Here is oscillograms with correct and wrong INT0 init – you were right, interrupt handler fires over and over during the whole vertical blanking interval (see channel 1).

[doctorandrey]

Next screenshots shows how it not counts frames and TV.millis, but overlaying working.

void loop() {

TV.print(0, 90, millis());

TV.print(40, 90, TV.millis());

TV.print(60, 90, display.frames);

}

[acton]

Fantastic … I’m glad you found this. I had assumed the issue was somewhere in the TVout code and I searched and searched but couldn’t find it! I have been overlaying the time (with vsync time to the nearest millisecond) and struggling to get consistent timing. I ended up fudging it myself by having my own frame and line counting within the hbi function and relying on the intrinsic accuracy of the camera crystal. This should simplify it all enormously!

Thanks!

[Michael]

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.

[doctorandrey]

I am glad that I helped to develop such nice project 🙂

[Author]

Posts