Using SPI for video overlay with Teensy 3.1 -- glitches

[epoulsen]

I'm attempting to implement a video graphics overly using SPI (mosi) to modify a live NTSC composite signal. I'm using the Teensy in "bare metal + arduino libraries" mode; I have a makefile, but I often call Arduino libraries as neccessary, though in some places it's full bare-metal.

For hardware, I'm using an LM1881 for sync separation, and interrupts for vsync, and burst output (hsync). For modifying the signal, the MOSI pin is attached to a 1n4148 diode and a resistor (in series) which is then attached to the video signal. This allows the MOSI pin to pull up the luminance, meaning that "1" bits show up as a bright dot on-screen.

All of the software + external hardware actually works just fine, but I'm having a bit of a problem with the SPI output itself, using the spi4teensy3 libraries:

[EDIT: looks like for issue #2, spi4teensy3 waits for the xfer to complete before sending two more bytes. The spike glitch is every two bytes. I'm going to look into modifying it to keep the FIFO full]

1. SPI seems to have a quiescent-high state when not sending data. Since a HIGH out means having a white pixel on-screen, then this causes a white bar near the left edge of the screen, since there is a delay between when SPI is turned on, and when data is actually sent.
2. When sending SPI data, there is a small postitive-going "spike" between bytes, which I believe is the MOSI attempting to return to it's quiescent state. This is visible in the video as faint vertical lines.

For the first issue, I can simply invert the MOSI signal (with external components, as this doesn't seem possible using the mk20 hardware), and consider a "0" bit to be a white pixel. But that would mean that the 2nd issue would cause faint dark lines for graphics that are mostly-white.

Two questions:

1. Is it possible to invert the SPI MOSI polarity solely via chip configuration? I've been through the data sheet, but could only find clock polarity.
2. Is there a known way to elimnate the glitch spikes between bytes on the MOSI output? I know spi4teensy3 sends 2 bytes at a time.

 

[epoulsen]

Ok, spi4teensy3 is keeping the FIFO full; just seems that the SPI has that spike issue between frames (SPI_CTAR_FMSZ)

[Edit]: These gaps are actually intentional:

• tASC: After SCK Delay
• tDT: Delay after Transfer
• tCSC: PCS to SCK Delay

It doesn't look like you can remove them entirely.