Raspberry Pi Pico PIO Clock recovery? - Page 1
Forum section: electronics / general

author: aeberbach
author_rank: Regular Contributor
timestamp: June 19, 2022, 11:39:14 pm
content: Has anyone seen (or have) an example of clock recovery using Raspberry Pi Pico? I'm interested in having the Pico behave as a VGA monitor, sampling video. I'm thinking one PIO can do clock recovery interrupting another to actually sample the pixel values at that point. Will possibly require overclocking?

author: ataradov
author_rank: Super Contributor
timestamp: June 19, 2022, 11:49:15 pm
content: I've implemented clock recovery (or rather sample point adjustment) for a USB protocol herehttps://github.com/ataradov/usb-sniffer-lite/blob/main/firmware/capture.cIt did require overclocking and USB encoding is specifically designed to have guaranteed periodic edge transitions. In the end I don't think it was necessary, but I kept it, since it was working anyway.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 19, 2022, 11:53:36 pm
content: How would you achieve "clock recovery"? From the sync signals?And how are you going to sample the VGA R, G and B? Those are not digital signals, but analog.Unless you're going to just extract a one-bit value for each using 3 comparators, giving you a whopping total of 3 bits of color and so 8 colors including black?Otherwise you'll need an external ADC.

author: ataradov
author_rank: Super Contributor
timestamp: June 19, 2022, 11:59:15 pm
content: I assumed it was something like a comparator per R, G and B, so you only get 8 colors. If this is the case you can do clock recovery based on the edge transitions in the signal, assuming the color component is not entirely on or off. This obviously limiting, but probably the best you can do.Just synchronizing on the sync signals is trivial and can't even be called clock recovery really.

author: aeberbach
author_rank: Regular Contributor
timestamp: June 20, 2022, 12:37:25 am
content: I'm messing around with video inside a compact Macintosh - so 512x342x1bpp, 60Hz, roughly 10.5MHz pixel clock. Easy mode compared to real VGA, no ADCs required - but it does use a very similar scheme of sync pulses.Thanks for the sample code.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 20, 2022, 12:51:08 am
content: Quote from: aeberbach on June 20, 2022, 12:37:25 amOh, so it's not VGA at all, just a monochrome signal with a relatively "slow" clock. That should be doable indeed.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 20, 2022, 01:01:49 am
content: Quote from: ataradov on June 19, 2022, 11:59:15 pmLimiting? That's just not going to work. You'd need images with a lot of transitions for that, basically noise.Screen with a solid color would just have zero transition. And any images from simple GUIs would probably have much too few to be usable.Quote from: ataradov on June 19, 2022, 11:59:15 pmOf course the sync signals will give you... signals to sync on.But the idea was to use the HSYNC signal (because it's the fastest one and you get as many pulses as there are lines) to "recover" the pixel clock indirectly. I think that's more or less how VGA monitors handle it.You just need to know the total number of pixels per line (including the front and back porch). Use a counter with your own ref clock and count between HSYNC pulses. That'll give you the number of pulses of your own ref clock per line, and knowing the total number of pixels per line, you can deduce the pixel clock - actually you won't recover it, but you'll adjust the sampling point pixel per pixel. While doing this with an FPGA would be relatively straightforward, doing it on the RP2040 with just the PIO... that would require some thought. But you could always oversample the input video, put the result in RAM (the RP2040 has a comfy amount of RAM and the OP says they're gonna deal with a relatively low-res monochrome signal, so it should fit no problem even oversampled), then the bitmap reconstruction could be done on the second core if needed while acquisition and handling the "line counter" could happen on the first core, helped by the PIO and DMA. It would just need to sample the signal deserializing it and putting the result in memory through DMA, the PIO is perfect for this.A 4x oversampling should be more than enough, and would just require a 42MHz clock for the PIO, no problem at all for the RP2040, and the 512x342x1bpp oversampled 4 times would just require 85.5 KBytes, which is only a fraction of the available RAM on the RP2040. You can even use two for double-buffering.Just the way I see it at this point. This is a fun project.

author: ataradov
author_rank: Super Contributor
timestamp: June 20, 2022, 01:13:56 am
content: Quote from: SiliconWizard on June 20, 2022, 01:01:49 amIt is not that bad. You need to have the clock that is reasonably close, of course. Edge transitions would do minor adjustments. If your clock is so bad that it gets out of sync within a few scan lines, then it you just need to get a better source clock.I was thinking more of a full frame without an HSYNC. But if there is an HSYNC, then you are probably fine without any adjustments anyway.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: June 20, 2022, 03:28:51 am
content: Quote from: aeberbach on June 20, 2022, 12:37:25 amDoes this need to work with one Mac, or many ?If you want to sample pixels, the line sync can initially align you in time, for the start of each line, but the clock difference between your Mac and Pi will skew things across the line.To keep the sampling code simple, you may need to check and trim the clock.Pico's look to use 12MHz Osc, and have these paramsReference clock frequency min=5MHz, max=800MHzFeedback divider min=16, max=320VCO frequency min=750MHz, max=1600MHzCore Clk Nom 133MHzSo that makes 126MHz or 136.5 MHz as useful target 10.5MHz multiples, with 126Mhz having 12 ticks per 10.5MHz pixel.A VCO of 1008MHz divides by 8 to 126MHz and divides by 84 to 12MHz (refin)

author: aeberbach
author_rank: Regular Contributor
timestamp: June 20, 2022, 04:02:27 am
content: It is a bit of an academic exercise because the actual clock is available on the other side of the main PCB, but I would like to just use the three signals that actually go into the analog video circuit, vsync, hsync and pixel. I have played with an Arty FPGA board and found that while I can get a reasonably close clock after messing around with PLL dividers there is always just a little bit of corruption in the VGA output to an external monitor. If I just take that system clock and sync pixels on its edge, perfection - but that clock isn’t normally present at the video circuitry.It would be nice if it works on every such machine. I think it is going to be possible to get a clock close enough if it is re-synced from the hsync pulse at the beginning of every line. Haven’t had time to get into ataradov’s code yet though.