Can't we just use %111000 for the output drive? That would drive low and float high. I think the pin resistance is ~20 ohms, so maybe add 80-ohm series resistors?
yep 1k resistor soldered between the 5v pad adjacent to the smt 12 pin header, to the 5v pin that connects to pin 18 of the hdmi socket
In effect feeding 5v from the p2es rev B board through to pin 18 of the hdmi socket, via that 1k resistor
Its one less mystery, but not the mystery we really want solved...
Reading this part below seems to imply to me that we shouldn't be operating at the low end with the BITDAC but at the higher end of the P2 voltage range. If the single ended swing is between 400mV and 600mV through the termination resistor I wonder if something using the BITDAC settings of 1111_1011 might be quite good?
EDIT: Actually rethinking these numbers, they don't take into account the 123 ohm P2 impedance, so we might need a larger swing to accommodate that, more like 1111_1001 perhaps.
Can't we just use %111000 for the output drive? That would drive low and float high. I think the pin resistance is ~20 ohms, so maybe add 80-ohm series resistors?
Can't we just use %111000 for the output drive? That would drive low and float high. I think the pin resistance is ~20 ohms, so maybe add 80-ohm series resistors?
That worked for me directly without resistors.
Does %000000 fail, where it's driven for both high and low?
No it doesn't fail, it works for me and that is how I did all my development, but I didn't like the idea of that being the default in the code I released because there was no protection resistance except for 20 ohms. The BITDAC has 123 ohms which at least gives you something.
No it doesn't fail, it works for me and that is how I did all my development, but I didn't like the idea of that being the default in the code I released because there was no protection resistance except for 20 ohms. The BITDAC has 123 ohms which at least gives you something.
It says the termination impedances Rt and the characteristic cable impedance Zo must be matched so I guess it should really be 50 ohms source impedance to match that too, so your 20 ohms is closer, but 123 ohms gives you a bit more protection perhaps from over voltages on the DVI/HDMI equipment, or maybe it all gets diode clamped anyway.
Yep, those diode clamps are always there. So, maybe we should use the same 27 ohm series resistors that USB uses, and then just configure the pins for high-float and low-drive.
Regarding using the float high, drive low approach of %111_000, now I've left it running more, I see a few sparkly pixels in some places on that setting so it's not ideal.
I think the BITDAC option might be good, even though the source impedance is a bit high. Maybe we could throw parallel resistors to ground to lower it? Pulling the pin all the way low with 20 ohms seems to violate the DVI spec swing level and it would be too low a voltage.
Maybe because it doesn't have as far to float back to the high voltage sensing range compared to when pulled closer to zero voltage. ie. It's cable capacitance related.
Maybe because it doesn't have as far to float back to the high voltage sensing range compared to when pulled closer to zero voltage. ie. It's cable capacitance related.
Yes, the spec is 150mV over 50 ohms per side min, so that's 3mA min.
Current drive from P2 would be best,(4~6mA?) but failing that, a series R should mean less swing on the cable.
So long as the cable terminates in it's matched impedance, there should be no reflections, ie 50 ohm drive is not needed.
The examples all show current differential drive.
I think if you build a dedicated board you can design it right, but for people already using the direct P2-EVAL breakout using Parallax supplied Digital Video Out board without resistors, perhaps this float/1.5k setting is okay, OR if it varies from cable/setup we can try the BITDAC approach.
I felt rather uneasy about having the direct 0V drive down and 3.3V drive up approach I'd been using myself in my driver (so I went and released it with the 1.5k drive coded in for high and low) but perhaps with the 50 ohm termination in the DVI/HDMI receiver it shouldn't ever be a dead short. This float up and 1.5k pull down seems safe(ish?) if it also works for other people. We sort of need people to try it out to see if it works.
Alternatively the BITDAC level version might be a more universal/well constrained solution to be used with the Digital Video Out board.
Fair enough, though one problem might be that your switcher may not like the P2's DVI signals without I2C, or the 5V thing so you may have to do the same as Tubular did and strap to the 5V pin with a 1k5 resistor.
By the way if you get stuck @potatohead, you can always mess around in VGA or component mode with my driver, these offer much higher resolutions to DVI anyway on the P2, though not quite as cool.
Yeah. We are going to find out. Looks to me like most of what has been tried seems to have been OK. In the analog realm, I know this stuff cold. Abused it many times, no worries.
I think the coolest setup is Y-Pb-Pr 1080P (component HDTV). It only takes 3 analog pins and provides good resolution (1920 x 1080) on inexpensive TV's. You can get monochrome 1080P with just the Y signal on one pin. The only downside is that it uses bulky RCA plugs. I think on our A/V accessory board, we have a 1/8" 4-conductor plug that could carry the three signals.
Yeah component HD works out well with it's 3 pins and looks pretty nice like RGB. I've been using that A/V breakout board you mentioned Chip with the 3 cables with RCA connectors. Though, one further downside I found with my setup a least was that there was some overscan applied I couldn't seem to get rid of in my monitor's scaler settings so you can sometimes lose the information at the sides. Not so bad for graphics or video use, more of an issue for text. You can always compensate for it by adding more front and rear porch and shrinking the active area respectively, or tweak the timing to try to send all 1280/1920 pixels in the visible area.
By the way for those that didn't download the zip file in the top post, here is the summary of the feature set this video driver provides.
'******************************************************************************
'* *
'* P2 VGA/DVI/TV graphics and text mode video driver features *
'* =============================================================== *
'* *
'* This driver was inspired by original P2 video test code from Chip Gracey. *
'* Since then it has expanded with many features and capabilities identified *
'* below. Thanks also for some assistance & suggestions from Parallax forum *
'* members who helped find optimizations allowing performance improvements. *
'* *
'* Features: *
'* *
'* - fully programmable output resolution and timing *
'* - selectable DVI/VGA/SDTV/HDTV output mode and P2 pin group *
'* - multiple VGA sync options: RGBHV, RGBS, RGsB (SyncOnGreen) support *
'* - component HDTV video support up to 1080i (YPrPb) *
'* - PAL or NTSC SDTV video over composite/S-video/component *
'* - interlaced or progressive scan output *
'* - all P2 colour formats are supported in graphics mode *
'* - built in 16 colour text mode renderer *
'* - programmable font size (1-256 scanlines), 8 pixel wide font *
'* - up to 240 text columns supported in 1920 pixel wide mode *
'* - optional text blinking attribute (VGA style 16 bit text data format) *
'* - interlaced text font output support *
'* - fine text scrolling capability *
'* - pixel width doubling, scanline doubling in all output modes *
'* - dynamic colourspace converter parameters loaded per frame *
'* - multiple independently sized text or graphics regions per screen *
'* - a programmable mouse sprite available in all graphics/text regions *
'* - region specific mouse image data, palettes and/or fonts *
'* - selectable global mouse/region specific mouse co-ordinates *
'* - dual text cursors with independent attributes & colours per region *
'* - programmable top/bottom/side borders (per pixel boundary) *
'* - programmable border colour (24 bit) *
'* - programmable scanline source data skew/pitch *
'* - screen source buffer wraparound options per region allowing scrolling *
'* - per scanline status update for supporting external sprite drivers *
'* - support for odd/even field/frame automatic page flipping *
'* - software interface for requesting frame buffers from external memory *
'* - low system clock speeds supported using transparent pass through mode *
'* - scalable performance, high clock cycle use features can be disabled *
'* *
'* Revision history: *
'* ----------------- *
'* 0.8b 21 NOV 2019 rogloh -initial BETA release- *
'* *
'******************************************************************************
And here is a handy summary of the control registers to set up the display and the display region list, the main documentation file explains it all in further detail.
Component is my favorite too Chip. There are converter chips we can use on a breakout to get that to HDMI. I see some devices actually do that to 4K HDMI. Wonder whether cranking the pixel clock up on one of those would deliver more than 1920 pixels?
But, I do really want to experiment and learn what we can really do with HDMI directly. It's hackable.
Comments
In effect feeding 5v from the p2es rev B board through to pin 18 of the hdmi socket, via that 1k resistor
Its one less mystery, but not the mystery we really want solved...
EDIT: Actually rethinking these numbers, they don't take into account the 123 ohm P2 impedance, so we might need a larger swing to accommodate that, more like 1111_1001 perhaps.
That worked for me directly without resistors.
Does %000000 fail, where it's driven for both high and low?
What is the impedance supposed to be? 100 ohms?
Regarding using the float high, drive low approach of %111_000, now I've left it running more, I see a few sparkly pixels in some places on that setting so it's not ideal.
wrpin ##%111001<<8, a
Interesting that float/1r5k works, but float/20r doesn't. Whatever the solution, it shouldn't be more than a few resistors.
Yes, the spec is 150mV over 50 ohms per side min, so that's 3mA min.
Current drive from P2 would be best,(4~6mA?) but failing that, a series R should mean less swing on the cable.
So long as the cable terminates in it's matched impedance, there should be no reflections, ie 50 ohm drive is not needed.
The examples all show current differential drive.
I felt rather uneasy about having the direct 0V drive down and 3.3V drive up approach I'd been using myself in my driver (so I went and released it with the 1.5k drive coded in for high and low) but perhaps with the 50 ohm termination in the DVI/HDMI receiver it shouldn't ever be a dead short. This float up and 1.5k pull down seems safe(ish?) if it also works for other people. We sort of need people to try it out to see if it works.
Alternatively the BITDAC level version might be a more universal/well constrained solution to be used with the Digital Video Out board.
By the way if you get stuck @potatohead, you can always mess around in VGA or component mode with my driver, these offer much higher resolutions to DVI anyway on the P2, though not quite as cool.
This is new, so baby steps.
But, I do really want to experiment and learn what we can really do with HDMI directly. It's hackable.
I'm also going to check what value of resistor the 5v sense of the TVL monitor works up to