@Wuerfel_21 said:
Well, there'd be some heavy compromise here...
Feature set is one thing for sure. I was also thinking about the layout; having ALL parts optimally placed for purpose (and ideal routing), rather than positioned to fit a PCB shape or certain connector layout requirements/etc..
@rogloh said:
Here's a full screen HDMI capture of 1360x768 at 85.5Mpixels/s - not too bad but there are some artefacts / noise. Look at the mouse pointer and some of the icons on the left of the GUI. I wonder if a decent PCB will solve most of this... might have to try it.
@VonSzarvas said:
Me too! I'd love to find a reason to layout an optimal P2 board without all the conflicting compromises, or to acquire one from someone who does have a reason and the resources
With Ada, that's a panel of 3 locked in !!
LOL, you two are assuming I'd be able to make a decent P2 board. Right now as a first step I'm actually thinking of something a lot less grand and faster to make, initially anyway, and just spinning a top interface board that sits over P2-EVAL (on this inside of the breakout connectors) and feeds RBG24+control signals from the TFP401 chip on the Adafruit board to port A, instead of via that FPC to IDC40 ribbon cable thing I put in the path. It's basically just a direct wiring adapter to the Adafruit board instead of the split ribbon which I don't like using for 85MHz stuff without grounds present for shielding. The interface board would just have the FPC40 pin connector and a decent ground plane under it and ideally it would also need to pass down the pixel clock to XI on P2-EVAL. I already have a 64MB PSRAM board I can use for P2 EVAL but this is an half inner board too and when fitted on port B it does cover over the XI pin and also takes up all of P32-P55 so it doesn't let me access any other 8 bit port for another breakout like the HDMI/VGA/USB ones already available. You can see the ugliness of what I'm dealing with right now - the single red wire carrying the pixel clock wire is intercepted from P24 IDC header with a logic probe clip and is going to XI on the bottom side of P2-EVAL, and yes it's far too long/unshielded for doing 85MHz stuff, makes a good antenna etc, I know, I know. Maybe instead for now I'll just go solder a short kynar wire from P24 directly to XI, under the EVAL board as a temporary measure to proceed with my current testing setup.
A downside is that this interface board may not actually help if these problems really are skew related issues on P2-EVAL, or incurs PLL issues due to use of P29 for a high speed signal on a Rev B P2-EVAL. It's mainly noise that I'd like to try to eliminate for now (as I do see pixels here and there with random colours) and see what remains afterwards. The Adafruit board does have series 33 ohm resistors on all its signals which is what I also placed on the 4 bit SD breakout I made and gets good high speed results, but if 33 ohms is not ideal I might also be able to fit extra bypassable inline resnet pads for potential fine tuning if needed. Still not sure if I'd need to.
Alternatively (and probably ideally) the P2-EC32MB with its much shorter paths could be used on a custom small capture board but unfortunately it doesn't expose XIN at the edge connector so sync capture can't be tested. I do wonder if one could be hacked to bring this net out to an unused (NC) gold finger on the connector? That might be a really good option actually if doable as it already eliminates any extra PSRAM requirements. @VonSzarvas do you think a fine wire could even be modded from XI to an NC on the Edge using one of your later Rev boards? Are you up for an attempt? On my original Rev A I do see a couple of tiny gold solder pads under the xtal, which are close the the NC pads, are they XI/XO by any chance, or something else for testing?
If I could go this route I could layout a pretty simple board that basically just has the P2 Edge connector, a FPC 40 way connector, power socket and one regular 12 pin breakout connector for P32-P39 access, then following on, a dedicated capture board with the TFP401 and other requested stuff could be made too. That's a nice pathway. Will have to think about this...
@Wuerfel_21 said:
Well, there'd be some heavy compromise here... If we need the entire Port A for the capture interface, 18+ pins for PSRAM, 4 pins for SD/flash (do we need flash?), 2 for serial, that would leave exactly 8.
Whereas possible extra wants would be:
DDC pins (2), so the ROM can be easily rewritten - or maybe just emulate it in software to begin with. Could also do other fun things, maybe we can implement a HDCP handshake. I seem to remember someone figured out the master key for HDCP 1.x some while ago. Would only be useful for offline analysis though.
Video output. 8 pins for HDMI. Could maybe go 3 pin for sync-on-green analog, but uhhhh and that wouldn't include any audio.
USB master/device (at least 2 pins each) for aforementioned latency test application.
Though with an optimized board maybe sysclk/1 HyperRAM can be a thing again and save pins that way... There's a nice-looking part, IS66WVH64M8DBLL, 3.3V 64Mx8
If a dedicated board was built for HDMI capture, HyperRAM would be a good way to go. LOL, imagine dual HyperRAMs for double the memory bandwidth and potential 1080p60! capture assuming sysclk/2 sampling worked and IO skew+layout was good enough to sample pixels switching at 148.5MHz! But based on the inherent IO skew of ~9ns I do expect this is unachievable unless you could fine tune each IO pin signal individually. One bank is sufficient so it'd be 720p and 1080i only at sysclk/4 streaming rates.
You can definitely save some pins on the control interface when sync capturing. The "Active" signal from the TFP401 is not really needed. It came along for the ride in my case because it was in the middle of the IDC cable bundle and not that easy to remove. The clock pin might not be needed to go to an IO pin if it just goes to XIN, although it's good for signal analysis with smart pins when clocked internally and you could read it at startup on the internal 20MHz clock to detect presence of HDMI before switching to the PLL settings, and present a notification to plug in the cable first etc.
I do wait for a video guard pattern to appear on the data pins, and use a VSYNC falling edge before starting the pattern waiting step. The other pins like DE and HSYNC are more useful for analysis and for async capture although I did use DE to qualify the video guard pattern even though it's probably not a valid pattern when DE=0. Here's the capture COG triggering code I do for sync capture right now. In theory you could get by with just VSYNC and that could free a lot of pins then maybe even something like this IO pin usage is achievable:
P0-P23 - RGB data
P24 - Vsync
P25 - pixel clock or DE?
P26-P31 - 6 free pins for 4bit SD control/data?
P32-P39 - HDMI or VGA/AV output
P40-P47 - HyperRAM 8 bit data bus
P48-P50 - HyperRAM control (3 pins)
P51-P55 - 5 free pins for USB input D+/- & output D+/D- + host power switch control
P56-P57 - I2C to respond to EDID queries if directly connected to HDMI interface, or to reprogram EDID EEPROM on Adafruit board.
P58-P63 - standard boot flash & P2 serial
waitatn ' wait for capture trigger from control COG
rdlong total, ptrb ' we are now capturing this many bytes of data
setse1 #128+VS_PIN ' falling edge of vsync
modcz _CLR,_SET wcz
setpat ##$12ffffff,##$12AB55AB ' video guard pattern when DE=1, and HDMI is active
pollse1
waitse1 'wait for vsync
pollpat
waitpat ' wait for video guard
waitx #2 ' adjust for best capture
' start a continuous streamer reading in the desired HDMI port data and writing to FIFO blocks
xinit ##X_32P_4DAC8_WFLONG|X_WRITE_ON|$ffff, #0
Just wired a very short wire from P24 to the XI pad on P2-EVAL. Didn't seem to help, still seeing those bad pixels, which could just be skew and sampled during transitions. Here's some zoomed in parts:
Also the same pixels seem to be getting affected in two different capture runs which indicates something other than random noise, so I suspect it's timing skew on some bits vs others. In theory it might even be PSRAM effects at this P2 speed, although I do a memory test once I boot up to validate the delay being set for the input clock rate.
E.g. captured just now.
Yesterday's capture:
One thing I didn't understand is that yellow pixel in the top grey line of the folder icon. It shouldn't be transitioning the pixels between same colour so why does it go yellow then?
Gonna mess with some Schmitt / sync/async settings to see if it helps and also want to drop down to 74.25Mpixels/sec with 720p or 1080i signal instead, which may also help. I wish I could just get that 9P hostFs code from @ersmith working to avoid yanking the uSD card out of the P2-EVAL and mounting on my Mac each time I capture an image. That got old fast. See https://forums.parallax.com/discussion/comment/1561718/#Comment_1561718 I took a quick look but it seems to be some sort of u9fs buffering/message delineation problem in loadp2 for Macs/Linux perhaps.
@Tubular said:
We do have the pin by pin skew figures, fwiw
Thanks, just saw the tables in your email. Seems like approx 9ns total difference from slowest to fastest.
I struggled to make sense of that spreadsheet. I couldn't work out what path or paths it represented. And I was pretty sure it was only for unregistered pins.
EDIT: Hmm, reading it again, it does say OUTGOING PIN SIGNALS CORE->PAD and INCOMING PIN SIGNALS PAD->CORE
I presume that means between the inner and outer edges of the pad-ring ... Which explains the way we have to accommodate multiple sysclock ticks in turnaround time when measuring external device responses at high sysclock rates.
I haven't read up on any modern ARM chip. I wonder what those have to deal with. I'm pretty certain it must be below 1.0 ns each way though.
The last P2 Eval build had an improved internal layout around the xtal. What rev and datecode do you have? I think C was the last, but had 2 datecodes. Will check it later.
The last P2 Eval build had an improved internal layout around the xtal. What rev and datecode do you have? I think C was the last, but had 2 datecodes. Will check it later.
Oh, and the PLL is more stable with smaller D divider values too. eg: Setting 200 MHz sysclock is notably more stable than 201 MHz.
EDIT: Or it could be the multiplier. A large divider makes for a large multiplier too.
The XI mod wire- sure! Easy peasy!! Using a bit of very fine RGxx wire would be nicer, considering thats the input. Like the very thin shielded cable GPS antenna often use.
@VonSzarvas said:
The last P2 Eval build had an improved internal layout around the xtal. What rev and datecode do you have? I think C was the last, but had 2 datecodes. Will check it later.
I have a Rev A here, date code 2146 by the looks of it. EDIT: that is for my P2-Edge with PSRAM. RevB code 1928 for the P2-EVAL.
The last P2 Eval build had an improved internal layout around the xtal. What rev and datecode do you have? I think C was the last, but had 2 datecodes. Will check it later.
Oh, and the PLL is more stable with smaller D divider values too. eg: Setting 200 MHz sysclock is notably more stable than 201 MHz.
EDIT: Or it could be the multiplier. A large divider makes for a large multiplier too.
Yeah I should try that. Right now am still struggling with this u9fs thing to see if I can write serially to the host filesystem instead of SD card hotswaps. It returns IO errors on every serial write attempt, not sure why.
@Tubular said:
We do have the pin by pin skew figures, fwiw
Thanks, just saw the tables in your email. Seems like approx 9ns total difference from slowest to fastest.
I struggled to make sense of that spreadsheet. I couldn't work out what path or paths it represented. And I was pretty sure it was only for unregistered pins.
Actually given it's using a 10GHz clock it looks like I'm off by a factor of ten here. It's more like 0.9ns for 9 cycles of 10GHz, isn't it? I'm looking at that stuff Henrique did with each of the 64 pin's transitions plotted against each other using a 10GHz ref clock.
@VonSzarvas said:
The last P2 Eval build had an improved internal layout around the xtal. What rev and datecode do you have? I think C was the last, but had 2 datecodes. Will check it later.
I have a Rev A here, date code 2146 by the looks of it.
2146 is probably rev C. It should be labelled as such on the top.
My rev A is 1846. My two rev Bs are both 1928. These are Eval Boards, not Edge Cards.
@VonSzarvas said:
The last P2 Eval build had an improved internal layout around the xtal. What rev and datecode do you have? I think C was the last, but had 2 datecodes. Will check it later.
I have a Rev A here, date code 2146 by the looks of it.
2146 is probably rev C. It should be labelled as such on the top.
My rev A is 1846. My two rev Bs are both 1928. These are Eval Boards, not Edge Cards.
Doh, yeah I was looking at the P2 Edge. My P2-EVAL is a revB. My P2-EVAL has a tiny 1928 on it.
@rogloh said:
Actually given it's using a 10GHz clock it looks like I'm off by a factor of ten here. It's more like 0.9ns for 9 cycles of 10GHz, isn't it?
I figured as much. I didn't quite get to commenting about that.
@evanh said:
Oh, and the PLL is more stable with smaller D divider values too. eg: Setting 200 MHz sysclock is notably more stable than 201 MHz.
EDIT: Or it could be the multiplier. A large divider makes for a large multiplier too.
Current clock mode computed by flexspin compiler is $010003F7 for these...already uses the smallest values for multiplier and divider.
@VonSzarvas said:
The XI mod wire- sure! Easy peasy!! Using a bit of very fine RGxx wire would be nicer, considering thats the input. Like the very thin shielded cable GPS antenna often use.
BTW here's the temporary bodge I did for P2-EVAL in the end. I wanted it to be easily removable/replaceable so I just wire-wrapped to the pin and added a new short wire-wrap pin stub to the XI pad. Hopefully 20MHz mode still works once I remove the wire.
@rogloh said:
BTW here's the temporary bodge I did for P2-EVAL in the end. I wanted it to be easily removable/replaceable so I just wire-wrapped to the pin and added a new short wire-wrap pin stub to the XI pad. Hopefully 20MHz mode still works once I remove the wire.
Oh, um, not sure that's going to be happy like that. XO stays active when XI is used in any way. Which means the soldered crystal is actively fighting the hacked input. And then there is the fact you've got a 85.5 MHz clock running down some long wires ... !
@rogloh said:
BTW here's the temporary bodge I did for P2-EVAL in the end. I wanted it to be easily removable/replaceable so I just wire-wrapped to the pin and added a new short wire-wrap pin stub to the XI pad. Hopefully 20MHz mode still works once I remove the wire.
Oh, um, not sure that's going to be happy like that. XO stays active when XI is used in any way. Which means the soldered crystal is actively fighting the hacked input. And then there is the fact you've got a 85.5 MHz clock running down some long wires ... !
Yes not ideal I know. Best I could do at short notice, LOL.
Had another idea to test out. I could try to run directly from XI and bypass the PLL in the P2. It would need to sample pixels at sysclk/1 to hub only and couldn't be written to PSRAM, but I could still capture a subset of the screen in the area of interest and compare with what was captured with the PLL operational. It might help rule out PLL jitter as a cause of these errors. Plus all these captures so far were with done with the pin mode as async (live input mode). Need to check if a sync (clocked input mode) capture helps, hopefully it might.
No luck with the sync mode enabled on the pin (with P_SCHMITT_A). Waitx #2 is still the best clock phase. Will try without Schmitt triggering enabled.
waitx #0
waitx #1
waitx #2
waitx #3
@rogloh said:
BTW here's the temporary bodge I did for P2-EVAL in the end. I wanted it to be easily removable/replaceable so I just wire-wrapped to the pin and added a new short wire-wrap pin stub to the XI pad. Hopefully 20MHz mode still works once I remove the wire.
Oh, um, not sure that's going to be happy like that. XO stays active when XI is used in any way. Which means the soldered crystal is actively fighting the hacked input. And then there is the fact you've got a 85.5 MHz clock running down some long wires ... !
Agree with evanh on the antenna- a shielded cable from your clock source would be better. As for XO... I though it could be disabled in one of the modes? hmm.. well- I've not looked. But if you really can't then yeah- hot air gun that xtal off the board. It has fairly small contact points, so a generous "pool" of flux will let you lift that part without overheating it; I'd expect you to be able to re-use the part later, without much fuss. Or just dedicate a board for clock experiments.
@VonSzarvas said:
The last P2 Eval build had an improved internal layout around the xtal. What rev and datecode do you have? I think C was the last, but had 2 datecodes. Will check it later.
I have a Rev A here, date code 2146 by the looks of it.
2146 is probably rev C. It should be labelled as such on the top.
My rev A is 1846. My two rev Bs are both 1928. These are Eval Boards, not Edge Cards.
Doh, yeah I was looking at the P2 Edge. My P2-EVAL is a revB. My P2-EVAL has a tiny 1928 on it.
To fill the gaps:
Rev A - 1846
Rev B - 1928
Rev C - 2025
Rev C - 2149 (current build)
Here's some notes I made at the time:
Note that RevC1 PCBs (identified by date code 2149 or greater) have a different USB power switching chip to the previous builds (stock supply shortages). The IC has an internal 2ms soft-start delay. That is just enough to trigger a “power good” reset pulse from the 1.8V switcher. ie. the P2 will reset when customers plug in/out the PC-USB or AUX-USB cables.
On the previous revs, the reset didn’t occur when switching to AUX-USB (although it did occur when switching to PC-USB, but due to a different reason of the Windows DTR pin setting, if the user hadn't adjusted the Windows default behavior).
With this opportunity for change, the layout of the xtal traces on the inner layer was adjusted within available space to improve isolation.
Refer to ECN for BOM changes of associated passives, related to the new USB IC.
The changes might be "slim pickings", but if it's your "go to" board, and with the reduced price, it might be worth grabbing an Eval or two before they go forever!
I'll start a new thread in a moment about a new board.
@rogloh said:
BTW here's the temporary bodge I did for P2-EVAL in the end. I wanted it to be easily removable/replaceable so I just wire-wrapped to the pin and added a new short wire-wrap pin stub to the XI pad. Hopefully 20MHz mode still works once I remove the wire.
Oh, um, not sure that's going to be happy like that. XO stays active when XI is used in any way. Which means the soldered crystal is actively fighting the hacked input. And then there is the fact you've got a 85.5 MHz clock running down some long wires ... !
Yeah amazing anything works at all, lol.
Agree with evanh on the antenna- a shielded cable from your clock source would be better. As for XO... I though it could be disabled in one of the modes? hmm.. well- I've not looked. But if you really can't then yeah- hot air gun that xtal off the board. It has fairly small contact points, so a generous "pool" of flux will let you lift that part without overheating it; I'd expect you to be able to re-use the part later, without much fuss. Or just dedicate a board for clock experiments.
I do have a second RevB P2-EVAL so I could dedicate a board to it if required and a hot air tool too. Might be worth removing it to see if it helps.
Related to this I am currently trying experiments disabling the PLL and running direct from XIN but it's not working. Seems to lock up once I select clock source field %SS=2 (XIN). Also tried going via RCFast first but doesn't help. Flexspin seems to want to use the PLL even when I leave off the _clkfreq constant.
CON
_xinfreq = 85500000
_clkfreq = 85500000
PUB main()
'clkset($0, 20000000)
waitms(10) ' stabilize?
clkset($2, 85500000)
' hangs here during this
UPDATE: just fixed this, clkmode should be 6 not 2.
It's a curious thing, as we did a bunch of testing around the XI, and for sure I was injecting the clock from a sig-gen in some testing, and it was totally fine in the right clock mode. I also seem to recall the clock mode we used didn't seem to make sense... hmm, maybe a clue. Quite certain the board clock remained in place, but maybe I can't remember.
I'll get to the lab computer and bring up the old test code- see what I can find. Should be some video or photos of the setup too.
Finally managed to capture at sysclk/1 with the P2 running from XIN directly at pixel clock frequency. This eliminates use of the PLL inside the P2. Wasn't able to get a full frame into HUB RAM due to not being able to write to PSRAM fast enough but homed in on a strip of scan lines that contain that icon seen before.
I'm still getting errors without the PLL. Probably just skew or ground bounce issues during some transitions. Not random noise as it always affects the same pixels.
Waitx phase has no meaning now because data changes on every P2 clock but this was with sync IO. Will also look at async and Schmitt input mode options but not holding my breath.
Sync only
Updates:
Schmitt + sync
Schmitt + async
Async only
No bueno.
All that's left now to try is this perhaps:
Drop down to 75MHz and hope for improvements.
Desolder the crystal from a RevB to see if that helps.
Improve clock wire to P2 - TFP401 board has no good way to get it out apart from the FFC ribbon. At least if you do that then the lengths for data and clock paths remain coupled.
Spin the connector board and get rid of long IDC ribbon cable and add better grounding.
At 85MHz you may need individual ground wires like those old 80 conductor IDE cables. Or a dedicated PCB The PCI bus has 20 ground pins for 32+ data pins and that's only 33 MHz. That 40 pin FPC connector only has 3? ground pins for 24+ data pins. And ground lines need to run closely parallel to the data lines.
You could enable registered input on only some pins.
Chris Gadd posted a USB mass storage device program here https://forums.parallax.com/discussion/comment/1561434/#Comment_1561434 I didn't have any luck yet with the included SD card driver, but it was easy to use hub ram instead as a 128kB disk. I think it would be easy set it up to use the PSRAM. Just remember that the USB device board dm pins are 18 and 20, not 16 as set in the zipfile. I've been working on a USB video class device which I should be posting soon.
Comments
Feature set is one thing for sure. I was also thinking about the layout; having ALL parts optimally placed for purpose (and ideal routing), rather than positioned to fit a PCB shape or certain connector layout requirements/etc..
Oh, that certainly. Though if good board layout can make DDR HyperRAM reliable, there's more pins left for features, so it all interlocks
We do have the pin by pin skew figures, fwiw
LOL, you two are assuming I'd be able to make a decent P2 board.
Right now as a first step I'm actually thinking of something a lot less grand and faster to make, initially anyway, and just spinning a top interface board that sits over P2-EVAL (on this inside of the breakout connectors) and feeds RBG24+control signals from the TFP401 chip on the Adafruit board to port A, instead of via that FPC to IDC40 ribbon cable thing I put in the path. It's basically just a direct wiring adapter to the Adafruit board instead of the split ribbon which I don't like using for 85MHz stuff without grounds present for shielding. The interface board would just have the FPC40 pin connector and a decent ground plane under it and ideally it would also need to pass down the pixel clock to XI on P2-EVAL. I already have a 64MB PSRAM board I can use for P2 EVAL but this is an half inner board too and when fitted on port B it does cover over the XI pin and also takes up all of P32-P55 so it doesn't let me access any other 8 bit port for another breakout like the HDMI/VGA/USB ones already available. You can see the ugliness of what I'm dealing with right now - the single red wire carrying the pixel clock wire is intercepted from P24 IDC header with a logic probe clip and is going to XI on the bottom side of P2-EVAL, and yes it's far too long/unshielded for doing 85MHz stuff, makes a good antenna etc, I know, I know. Maybe instead for now I'll just go solder a short kynar wire from P24 directly to XI, under the EVAL board as a temporary measure to proceed with my current testing setup.
A downside is that this interface board may not actually help if these problems really are skew related issues on P2-EVAL, or incurs PLL issues due to use of P29 for a high speed signal on a Rev B P2-EVAL. It's mainly noise that I'd like to try to eliminate for now (as I do see pixels here and there with random colours) and see what remains afterwards. The Adafruit board does have series 33 ohm resistors on all its signals which is what I also placed on the 4 bit SD breakout I made and gets good high speed results, but if 33 ohms is not ideal I might also be able to fit extra bypassable inline resnet pads for potential fine tuning if needed. Still not sure if I'd need to.
Alternatively (and probably ideally) the P2-EC32MB with its much shorter paths could be used on a custom small capture board but unfortunately it doesn't expose XIN at the edge connector so sync capture can't be tested. I do wonder if one could be hacked to bring this net out to an unused (NC) gold finger on the connector? That might be a really good option actually if doable as it already eliminates any extra PSRAM requirements. @VonSzarvas do you think a fine wire could even be modded from XI to an NC on the Edge using one of your later Rev boards? Are you up for an attempt? On my original Rev A I do see a couple of tiny gold solder pads under the xtal, which are close the the NC pads, are they XI/XO by any chance, or something else for testing?
If I could go this route I could layout a pretty simple board that basically just has the P2 Edge connector, a FPC 40 way connector, power socket and one regular 12 pin breakout connector for P32-P39 access, then following on, a dedicated capture board with the TFP401 and other requested stuff could be made too. That's a nice pathway. Will have to think about this...
Thanks, just saw the tables in your email. Seems like approx 9ns total difference from slowest to fastest.
EDIT: should be 0.9ns.
If a dedicated board was built for HDMI capture, HyperRAM would be a good way to go. LOL, imagine dual HyperRAMs for double the memory bandwidth and potential 1080p60! capture assuming sysclk/2 sampling worked and IO skew+layout was good enough to sample pixels switching at 148.5MHz! But based on the inherent IO skew of ~9ns I do expect this is unachievable unless you could fine tune each IO pin signal individually. One bank is sufficient so it'd be 720p and 1080i only at sysclk/4 streaming rates.
You can definitely save some pins on the control interface when sync capturing. The "Active" signal from the TFP401 is not really needed. It came along for the ride in my case because it was in the middle of the IDC cable bundle and not that easy to remove. The clock pin might not be needed to go to an IO pin if it just goes to XIN, although it's good for signal analysis with smart pins when clocked internally and you could read it at startup on the internal 20MHz clock to detect presence of HDMI before switching to the PLL settings, and present a notification to plug in the cable first etc.
I do wait for a video guard pattern to appear on the data pins, and use a VSYNC falling edge before starting the pattern waiting step. The other pins like DE and HSYNC are more useful for analysis and for async capture although I did use DE to qualify the video guard pattern even though it's probably not a valid pattern when DE=0. Here's the capture COG triggering code I do for sync capture right now. In theory you could get by with just VSYNC and that could free a lot of pins then maybe even something like this IO pin usage is achievable:
waitatn ' wait for capture trigger from control COG rdlong total, ptrb ' we are now capturing this many bytes of data setse1 #128+VS_PIN ' falling edge of vsync modcz _CLR,_SET wcz setpat ##$12ffffff,##$12AB55AB ' video guard pattern when DE=1, and HDMI is active pollse1 waitse1 'wait for vsync pollpat waitpat ' wait for video guard waitx #2 ' adjust for best capture ' start a continuous streamer reading in the desired HDMI port data and writing to FIFO blocks xinit ##X_32P_4DAC8_WFLONG|X_WRITE_ON|$ffff, #0Just wired a very short wire from P24 to the XI pad on P2-EVAL. Didn't seem to help, still seeing those bad pixels, which could just be skew and sampled during transitions. Here's some zoomed in parts:
Also the same pixels seem to be getting affected in two different capture runs which indicates something other than random noise, so I suspect it's timing skew on some bits vs others. In theory it might even be PSRAM effects at this P2 speed, although I do a memory test once I boot up to validate the delay being set for the input clock rate.
E.g. captured just now.
Yesterday's capture:
One thing I didn't understand is that yellow pixel in the top grey line of the folder icon. It shouldn't be transitioning the pixels between same colour so why does it go yellow then?
Gonna mess with some Schmitt / sync/async settings to see if it helps and also want to drop down to 74.25Mpixels/sec with 720p or 1080i signal instead, which may also help. I wish I could just get that 9P hostFs code from @ersmith working to avoid yanking the uSD card out of the P2-EVAL and mounting on my Mac each time I capture an image. That got old fast. See https://forums.parallax.com/discussion/comment/1561718/#Comment_1561718 I took a quick look but it seems to be some sort of u9fs buffering/message delineation problem in loadp2 for Macs/Linux perhaps.
I struggled to make sense of that spreadsheet. I couldn't work out what path or paths it represented. And I was pretty sure it was only for unregistered pins.
EDIT: Hmm, reading it again, it does say OUTGOING PIN SIGNALS CORE->PAD and INCOMING PIN SIGNALS PAD->CORE
I presume that means between the inner and outer edges of the pad-ring ... Which explains the way we have to accommodate multiple sysclock ticks in turnaround time when measuring external device responses at high sysclock rates.
I haven't read up on any modern ARM chip. I wonder what those have to deal with. I'm pretty certain it must be below 1.0 ns each way though.
The last P2 Eval build had an improved internal layout around the xtal. What rev and datecode do you have? I think C was the last, but had 2 datecodes. Will check it later.
.> @VonSzarvas said:
Oh, and the PLL is more stable with smaller D divider values too. eg: Setting 200 MHz sysclock is notably more stable than 201 MHz.
EDIT: Or it could be the multiplier. A large divider makes for a large multiplier too.
The XI mod wire- sure! Easy peasy!! Using a bit of very fine RGxx wire would be nicer, considering thats the input. Like the very thin shielded cable GPS antenna often use.
I have a Rev A here, date code 2146 by the looks of it. EDIT: that is for my P2-Edge with PSRAM. RevB code 1928 for the P2-EVAL.
Yeah I should try that. Right now am still struggling with this u9fs thing to see if I can write serially to the host filesystem instead of SD card hotswaps. It returns IO errors on every serial write attempt, not sure why.
Actually given it's using a 10GHz clock it looks like I'm off by a factor of ten here. It's more like 0.9ns for 9 cycles of 10GHz, isn't it? I'm looking at that stuff Henrique did with each of the 64 pin's transitions plotted against each other using a 10GHz ref clock.
2146 is probably rev C. It should be labelled as such on the top.
My rev A is 1846. My two rev Bs are both 1928. These are Eval Boards, not Edge Cards.
Doh, yeah I was looking at the P2 Edge. My P2-EVAL is a revB. My P2-EVAL has a tiny 1928 on it.
I figured as much. I didn't quite get to commenting about that.
Current clock mode computed by flexspin compiler is $010003F7 for these...already uses the smallest values for multiplier and divider.
CON _xinfreq = 85500000 _clkfreq = 342000000BTW here's the temporary bodge I did for P2-EVAL in the end. I wanted it to be easily removable/replaceable so I just wire-wrapped to the pin and added a new short wire-wrap pin stub to the XI pad. Hopefully 20MHz mode still works once I remove the wire.
Oh, um, not sure that's going to be happy like that. XO stays active when XI is used in any way. Which means the soldered crystal is actively fighting the hacked input. And then there is the fact you've got a 85.5 MHz clock running down some long wires ... !
Yes not ideal I know. Best I could do at short notice, LOL.
Had another idea to test out. I could try to run directly from XI and bypass the PLL in the P2. It would need to sample pixels at sysclk/1 to hub only and couldn't be written to PSRAM, but I could still capture a subset of the screen in the area of interest and compare with what was captured with the PLL operational. It might help rule out PLL jitter as a cause of these errors. Plus all these captures so far were with done with the pin mode as async (live input mode). Need to check if a sync (clocked input mode) capture helps, hopefully it might.
repeat i from 0 to 28 wrpin(i, P_SCHMITT_A)No luck with the sync mode enabled on the pin (with P_SCHMITT_A). Waitx #2 is still the best clock phase. Will try without Schmitt triggering enabled.
waitx #0
waitx #1
waitx #2
waitx #3
Agree with evanh on the antenna- a shielded cable from your clock source would be better. As for XO... I though it could be disabled in one of the modes? hmm.. well- I've not looked. But if you really can't then yeah- hot air gun that xtal off the board. It has fairly small contact points, so a generous "pool" of flux will let you lift that part without overheating it; I'd expect you to be able to re-use the part later, without much fuss. Or just dedicate a board for clock experiments.
To fill the gaps:
Rev A - 1846
Rev B - 1928
Rev C - 2025
Rev C - 2149 (current build)
Here's some notes I made at the time:
The changes might be "slim pickings", but if it's your "go to" board, and with the reduced price, it might be worth grabbing an Eval or two before they go forever!
I'll start a new thread in a moment about a new board.
Yeah amazing anything works at all, lol.
I do have a second RevB P2-EVAL so I could dedicate a board to it if required and a hot air tool too. Might be worth removing it to see if it helps.
Related to this I am currently trying experiments disabling the PLL and running direct from XIN but it's not working. Seems to lock up once I select clock source field %SS=2 (XIN). Also tried going via RCFast first but doesn't help. Flexspin seems to want to use the PLL even when I leave off the _clkfreq constant.
CON _xinfreq = 85500000 _clkfreq = 85500000 PUB main() 'clkset($0, 20000000) waitms(10) ' stabilize? clkset($2, 85500000) ' hangs here during thisUPDATE: just fixed this, clkmode should be 6 not 2.
It's a curious thing, as we did a bunch of testing around the XI, and for sure I was injecting the clock from a sig-gen in some testing, and it was totally fine in the right clock mode. I also seem to recall the clock mode we used didn't seem to make sense... hmm, maybe a clue. Quite certain the board clock remained in place, but maybe I can't remember.
I'll get to the lab computer and bring up the old test code- see what I can find. Should be some video or photos of the setup too.
Roger sorted it first,
Finally managed to capture at sysclk/1 with the P2 running from XIN directly at pixel clock frequency. This eliminates use of the PLL inside the P2. Wasn't able to get a full frame into HUB RAM due to not being able to write to PSRAM fast enough but homed in on a strip of scan lines that contain that icon seen before.
I'm still getting errors without the PLL. Probably just skew or ground bounce issues during some transitions. Not random noise as it always affects the same pixels.
Waitx phase has no meaning now because data changes on every P2 clock but this was with sync IO. Will also look at async and Schmitt input mode options but not holding my breath.
Sync only
Updates:
Schmitt + sync
Schmitt + async
Async only
No bueno.
All that's left now to try is this perhaps:
At 85MHz you may need individual ground wires like those old 80 conductor IDE cables. Or a dedicated PCB
The PCI bus has 20 ground pins for 32+ data pins and that's only 33 MHz. That 40 pin FPC connector only has 3? ground pins for 24+ data pins. And ground lines need to run closely parallel to the data lines.
You could enable registered input on only some pins.
Chris Gadd posted a USB mass storage device program here https://forums.parallax.com/discussion/comment/1561434/#Comment_1561434 I didn't have any luck yet with the included SD card driver, but it was easy to use hub ram instead as a 128kB disk. I think it would be easy set it up to use the PSRAM. Just remember that the USB device board dm pins are 18 and 20, not 16 as set in the zipfile. I've been working on a USB video class device which I should be posting soon.