I guess the VGA Hsync could be provided from the LCD Hsync. Big problem there is that this LCD uses weird timings that won't quite work for VGA. But having no external display/capture kinda blows, doesn't it?
Difficult problem. (The VGA hsync can be made to come from any DAC0 pin, btw)
@Wuerfel_21 said:
I guess the VGA Hsync could be provided from the LCD Hsync. Big problem there is that this LCD uses weird timings that won't quite work for VGA. But having no external display/capture kinda blows, doesn't it?
Difficult problem. (The VGA hsync can be made to come from any DAC0 pin, btw)
Yeah external would be nice - hard to solve though.
Ideally what I'd like to do is use USB-C instead of the PropPlug output and use that Alternate mode to carry HDMI but not enough P2 pins now unless I go down to 8 bit PSRAM and the cables all want to use the DP Alt Mode as an intermediate step - why!? Or I try to reuse some LCD pins for HDMI out - problem is the actual bus load for the HDMI as the LCD would still be connected to those pins and I don't really want to add extra buffer chips etc. I could use one of those Parallel RGB to to TMDS chips but there is really limited space and that chip is large. I could probably fit a micro HDMI connector in but I lose the ability to reprogram and/or download to the embedded SD card. I think I'd stick to just USB-C.
Ok I might still keep port A bits 0, 1 free. TBD. In fact I do have 3 free pins down there because DE is not required in this implementation. That would allow an analog VGA out if the sync pins are shared (as an either/or output due to restricted LCD timing). Again, what micro connector supports it? Actually a custom USB-C adapter to VGA perhaps could do that over a USB-C cable....hmm. Not as nice as direct cable to TV, but maybe better than nothing.
So something like this mapping could work out perhaps:
bit 0 - HSYNC
bit 1 - Blue
bit 2 - Green
bit 3 - Red
bit 4 - VSYNC
bit 5 - PIXELCLK
bit 6 - LEFT_PWM
bit 7 - RIGHT_PWM
This has an added advantage in that it is sort of compatible with the A/V breakout board pin mapping.
Custom cable it is I guess. For capture weird timings don't really matter, at least with those Datapath cards. Though I haven't been able to solve the annoying video offset problem. I think the Windows driver doesn't suffer it?
Yeah I'm gonna look into the USB-C with VGA as an option - only issue is it might possibly be a danger to plug a USB-C cable into a PC if VGA is being output at the time. RGB signals are limited to 0.7V or so but I still don't imagine the USB-C chips will be too happy with it, and I'd need to carry LVCMOS levels for syncs and possibly audio unless DACs are used (which may mess up internal audio though if amp is enabled or headphones are used). I could use the USB2 pins for those 3.3V signals I guess.
@Wuerfel_21 One possible way to get HDMI out might be those cheap VGA to HDMI converter boxes. If they worked with this tight video timing I guess we could try to use make use of that. Be cool if that chip fit inside this box, but I still need the connector space for it and it's at a premium. Might make more sense to use one externally even though not as nice a solution. https://goughlui.com/2019/02/02/quick-teardown-mini-vga2hdmi-converter/
Getting there on the next board. It's probably about 95% routed but that last 5% will of course take longer. I ended up adding USB-C to this which will allow programming and updating the internal SD card files via USB at some point - I have jumpers that can select paths via FTDI or through P62/P63 directly. I also added a bunch of solder jumpers for optionally sending VGA over a custom USB-C cable which may be helpful at some point. They are accessible on the bottom layer. Maybe a CM201 can be modified to accept input via USB-C connector and then output HDMI.
Here's the top layer - it's filling up a bit now, I just have some more USB-C routing to do and a general tidy up/DRC etc. I've also gone to 4 layers on the FireAnt board. With any luck the heat from the layers on the top P2 board can wick down via the grounded metal solder nuts and the two larger ground planes on my board will help dissipate the heat. But that's going to be an interesting test when we get to it - the P2 sitting above is facing outwards so adding some sort of external metal heatsink plate is still possible if needed. Hope it doesn't need an external fan!
@Wuerfel_21 , was chatting with @Tubular today and we talked about reversible USB-C cables carrying VGA signals. I wonder in your drivers whether we can make good use of Sync-on-Green as a way to deal with cable reversal or if there's any issue there. Looking at the colour channel mapping in the prior post's diagram, instead of using the TX2 pair for H/V syncs green is replicated on both TX1+/- as well as TX2+/- pins. Then if the USB-C cable is reversed then only red and blue colours would be swapped and this would be immediately visible but it would still work. Also L&R channels would be swapped but that's tolerable also. Another way to keep it working but avoiding sync-on-green is to use both CC1/CC2 pins for a single combined (H^V) sync single.
Note that doing this is obviously completely non-standard and is just for a customized breakout application using a USB-C interface cable to output VGA, not for normal USB-C operation. Ideally though it wouldn't interfere with a USB-A to USB-C cable at all and the D+/D- pins could still be used for a USB prop plug via the on-board FTDI chip. I could either use CC1/CC2 for combined sync, and the SBUS pins for audio or vice versa. Not sure which is better - perhaps SBUS is better for audio if no pull down resistors are present so the DAC mode can be used, but for this 5k1 resistor value it's unlikely to matter anyway.
Yes, I have support for Soggy Sync and C-Sync in my driver. Though to what extent monitors support it... IIRC my ASUS 1920x1200 monitor supports C-Sync, don't remember if it does soggy. The VisionRGB card certainly does all 3 (H/VSync, CSync, Soggy). Though it's certainly not universal. IIRC there's some issue with how soggy sync is generated (for both Sync-on-Green and YPbPr) that prevents it from running alongside HDMI (Csync is okay). Will have to figure out if that holds for LCD as well (which doesn't have that need to escape raw 10b codes)
EDIT: BTW, swapping red/blue (or Pb/Pr) in software is pretty ez.
Yeah I'll probably aim to target the C-sync way, at least as an option. All my monitors seem to accept that mode. My driver also does it as well. I believe C-sync can also be driven at video levels too. Am sort of hoping that the LCD without vsync might shut down and stop the internal amp so that would let us use DAC mode externally but not 100% sure yet.
UPDATE: with respect to the pinning of the cable and the audio/sync, I figured out it would need to be the combined HVSYNC on CC1 & CC2 with audio on SBUS because inside the USB-C cable there is only one CC line connected so stereo audio would not work there. So I'll just put the video sync on those pins. It means that CC1 and CC2 are shorted together after the socket (I'll populate only a single 5k1 resistor or possibly do 2x10k in parallel).
Whipped up another P2 related PCB since I'll be sending the P2 FireAnt one in a few days so I have an opportunity to make this as well. This one (if it works) will convert VGA to HDMI at up to 165MHz pixel clocks. The usual resolutions from 640x480 to 1920x1080 should be supported and stereo audio is encoded but some testing will be required to find the limits. The board is fairly densely packed now as I may have to hand solder some of it if component changes are needed because I'm using 0603's so I have some chance of doing so. But the 6x6mm QFN-48 is gonna be fun. Will be getting the stencil for sure and using the hotplate again. Probably should have chosen a smaller regulator but I'm just not sure how much current this will take and being linear and dropping 1.5V as heat, it could get quite hot. I do know it'll be less than 500mA as these converters can be USB powered.
I've added CEC as an option (solder jumper on back) for the spare pin after the 5 VGA pins then followed by left and right DAC pins so it's compatible with the A/V breakout to some extent. Just needs a bit of a touch up for the diff pairs and to sort out a few more DRCs then it'll be ready to go.
I haven't got any around the house to test, but I wouldn't trust these VGA digitizer chips to automatically detect the correct clock/phase even on standard modes. LCD monitors almost never get this 100% right in their auto-adjust feature either, unless you bring up a checkerboard pattern and then do it. This probably just guesstimates it on signal detect.
Comments
I guess the VGA Hsync could be provided from the LCD Hsync. Big problem there is that this LCD uses weird timings that won't quite work for VGA. But having no external display/capture kinda blows, doesn't it?
Difficult problem. (The VGA hsync can be made to come from any DAC0 pin, btw)
Yeah external would be nice - hard to solve though.
Ideally what I'd like to do is use USB-C instead of the PropPlug output and use that Alternate mode to carry HDMI but not enough P2 pins now unless I go down to 8 bit PSRAM and the cables all want to use the DP Alt Mode as an intermediate step - why!? Or I try to reuse some LCD pins for HDMI out - problem is the actual bus load for the HDMI as the LCD would still be connected to those pins and I don't really want to add extra buffer chips etc. I could use one of those Parallel RGB to to TMDS chips but there is really limited space and that chip is large. I could probably fit a micro HDMI connector in but I lose the ability to reprogram and/or download to the embedded SD card. I think I'd stick to just USB-C.
Ok I might still keep port A bits 0, 1 free. TBD. In fact I do have 3 free pins down there because DE is not required in this implementation. That would allow an analog VGA out if the sync pins are shared (as an either/or output due to restricted LCD timing). Again, what micro connector supports it? Actually a custom USB-C adapter to VGA perhaps could do that over a USB-C cable....hmm. Not as nice as direct cable to TV, but maybe better than nothing.
So something like this mapping could work out perhaps:
bit 0 - HSYNC
bit 1 - Blue
bit 2 - Green
bit 3 - Red
bit 4 - VSYNC
bit 5 - PIXELCLK
bit 6 - LEFT_PWM
bit 7 - RIGHT_PWM
This has an added advantage in that it is sort of compatible with the A/V breakout board pin mapping.
Custom cable it is I guess. For capture weird timings don't really matter, at least with those Datapath cards. Though I haven't been able to solve the annoying video offset problem. I think the Windows driver doesn't suffer it?
Yeah I'm gonna look into the USB-C with VGA as an option - only issue is it might possibly be a danger to plug a USB-C cable into a PC if VGA is being output at the time. RGB signals are limited to 0.7V or so but I still don't imagine the USB-C chips will be too happy with it, and I'd need to carry LVCMOS levels for syncs and possibly audio unless DACs are used (which may mess up internal audio though if amp is enabled or headphones are used). I could use the USB2 pins for those 3.3V signals I guess.
@Wuerfel_21 One possible way to get HDMI out might be those cheap VGA to HDMI converter boxes. If they worked with this tight video timing I guess we could try to use make use of that. Be cool if that chip fit inside this box, but I still need the connector space for it and it's at a premium. Might make more sense to use one externally even though not as nice a solution.
https://goughlui.com/2019/02/02/quick-teardown-mini-vga2hdmi-converter/
Getting there on the next board. It's probably about 95% routed but that last 5% will of course take longer. I ended up adding USB-C to this which will allow programming and updating the internal SD card files via USB at some point - I have jumpers that can select paths via FTDI or through P62/P63 directly. I also added a bunch of solder jumpers for optionally sending VGA over a custom USB-C cable which may be helpful at some point. They are accessible on the bottom layer. Maybe a CM201 can be modified to accept input via USB-C connector and then output HDMI.
Here's the top layer - it's filling up a bit now, I just have some more USB-C routing to do and a general tidy up/DRC etc. I've also gone to 4 layers on the FireAnt board. With any luck the heat from the layers on the top P2 board can wick down via the grounded metal solder nuts and the two larger ground planes on my board will help dissipate the heat. But that's going to be an interesting test when we get to it - the P2 sitting above is facing outwards so adding some sort of external metal heatsink plate is still possible if needed. Hope it doesn't need an external fan!
@Wuerfel_21 , was chatting with @Tubular today and we talked about reversible USB-C cables carrying VGA signals. I wonder in your drivers whether we can make good use of Sync-on-Green as a way to deal with cable reversal or if there's any issue there. Looking at the colour channel mapping in the prior post's diagram, instead of using the TX2 pair for H/V syncs green is replicated on both TX1+/- as well as TX2+/- pins. Then if the USB-C cable is reversed then only red and blue colours would be swapped and this would be immediately visible but it would still work. Also L&R channels would be swapped but that's tolerable also. Another way to keep it working but avoiding sync-on-green is to use both CC1/CC2 pins for a single combined (H^V) sync single.
Note that doing this is obviously completely non-standard and is just for a customized breakout application using a USB-C interface cable to output VGA, not for normal USB-C operation. Ideally though it wouldn't interfere with a USB-A to USB-C cable at all and the D+/D- pins could still be used for a USB prop plug via the on-board FTDI chip. I could either use CC1/CC2 for combined sync, and the SBUS pins for audio or vice versa. Not sure which is better - perhaps SBUS is better for audio if no pull down resistors are present so the DAC mode can be used, but for this 5k1 resistor value it's unlikely to matter anyway.
Yes, I have support for Soggy Sync and C-Sync in my driver. Though to what extent monitors support it... IIRC my ASUS 1920x1200 monitor supports C-Sync, don't remember if it does soggy. The VisionRGB card certainly does all 3 (H/VSync, CSync, Soggy). Though it's certainly not universal. IIRC there's some issue with how soggy sync is generated (for both Sync-on-Green and YPbPr) that prevents it from running alongside HDMI (Csync is okay). Will have to figure out if that holds for LCD as well (which doesn't have that need to escape raw 10b codes)
EDIT: BTW, swapping red/blue (or Pb/Pr) in software is pretty ez.
Yeah I'll probably aim to target the C-sync way, at least as an option. All my monitors seem to accept that mode. My driver also does it as well. I believe C-sync can also be driven at video levels too. Am sort of hoping that the LCD without vsync might shut down and stop the internal amp so that would let us use DAC mode externally but not 100% sure yet.
UPDATE: with respect to the pinning of the cable and the audio/sync, I figured out it would need to be the combined HVSYNC on CC1 & CC2 with audio on SBUS because inside the USB-C cable there is only one CC line connected so stereo audio would not work there. So I'll just put the video sync on those pins. It means that CC1 and CC2 are shorted together after the socket (I'll populate only a single 5k1 resistor or possibly do 2x10k in parallel).
Whipped up another P2 related PCB since I'll be sending the P2 FireAnt one in a few days so I have an opportunity to make this as well. This one (if it works) will convert VGA to HDMI at up to 165MHz pixel clocks. The usual resolutions from 640x480 to 1920x1080 should be supported and stereo audio is encoded but some testing will be required to find the limits. The board is fairly densely packed now as I may have to hand solder some of it if component changes are needed because I'm using 0603's so I have some chance of doing so. But the 6x6mm QFN-48 is gonna be fun. Will be getting the stencil for sure and using the hotplate again. Probably should have chosen a smaller regulator but I'm just not sure how much current this will take and being linear and dropping 1.5V as heat, it could get quite hot. I do know it'll be less than 500mA as these converters can be USB powered.
I've added CEC as an option (solder jumper on back) for the spare pin after the 5 VGA pins then followed by left and right DAC pins so it's compatible with the A/V breakout to some extent. Just needs a bit of a touch up for the diff pairs and to sort out a few more DRCs then it'll be ready to go.
I haven't got any around the house to test, but I wouldn't trust these VGA digitizer chips to automatically detect the correct clock/phase even on standard modes. LCD monitors almost never get this 100% right in their auto-adjust feature either, unless you bring up a checkerboard pattern and then do it. This probably just guesstimates it on signal detect.
I've had some success with this working out ok on the CM201 product I have here, but you might be right it may not be perfect at all times.
Though I'd stick with just breaking VGA out. Then you can plug it into a VisionRGB or smth like that and dial it in for pixel-perfect capture.