Chip,
I vaguely remember you and JMG discussing adding extra inverters into the crystal/PLL circuits, for the purpose of slowing it down, after the test die came back from the shuttle run. I don't remember anything particular though.
The crystal oscillator is a single inverter. This keeps the gain low enough that the crystal doesn't go into an overtone mode. There is a string of 4 inverters, I think, that are fed by the XI pin, that sharpen up the incoming edges for clocking usage.
Chip,
I vaguely remember you and JMG discussing adding extra inverters into the crystal/PLL circuits, for the purpose of slowing it down, after the test die came back from the shuttle run. I don't remember anything particular though.
That may have been related to not having the VCO range, miss-match the counter ability ?
ie you do not want the VCO feedback loop, to have a peak f while settling, that is too fast for the counter, otherwise it will never settle.
Cluso,
re: P2 chip temp. When the P2 is hot to the touch on top, what is the temp of the bottom of the board below the chip? I'm wondering if your particular board got a good solder connection from the chip ground pad to the PCB?
Chip seemed to indicate that his setup was not getting that hot when running at 180Mhz, and even wasn't bad at 250Mhz. I know he drilled out the hole in the PCB and loaded up a lot of solder into that connection.
The bottom of the pcb gets hot too, so I don't think there is any problems with the soldering of the ground pad.
With the new settings at 148.5MHz (12MHz osc then /24 then *297) it looks good and full screen width.
Now just need to play with the streamer to replay the hub twice to get full screen. Need to remove the 16x16 font for this to fit.
img: the Acer #2 doesn't display a pic at all. Complains invalid setting. Unfortunately I e discovered I cannot enter the menu (maybe push button faulty) so I don't know what setttings are there. It works fine on my laptop tho. Not going to waste time on this.
1920x1080 @ 2bpp 148.5MHz is running. It needs 506.25KB of Hub ram. Just enough in P2
I loaded up the cogs and then used Hub as the video buffer.
Does some graphics. Some gets a bit jittery depending on the bitmap though coloured lines seems fine. Need more testing and adjustments as I suspect I am not seeing every pixel on screen Sotheby's sync and porches need adjusting.
Chip,
My scope is too slow. I haven’t used it in 20 years.
However, I haven’t been trying to fix any jitter. I have just been getting it to run and move things around so I can load up the cogs and then I can use all 512KB of HUB for buffers
Now I’ve done that but had to remove all text and font from the graphics. Next I will put an 8x8 font into LUT and I have 5.75KB of HUB for a text buffer section. I have a font I used in P1.
Unfortunately will not have much time the next 3 days
Now I have a full screen I can check I can see all edges with a rectangle outline of pixels and adjust accordingly.
Then I can post for Peter or Lachlan to check temperatures. I am only running 2 cogs at 148.5MHz and it gets hot and starts to jitter fairly quickly which isn’t good. I need to check current etc.
What about current, Cluso? Does your meter display current consumption at 5v? We can always match current consumption, then take thermal photos or measurements.
OzProp and I have added DS18B20 temperature sensors to our R2D2s, to log ambient temperature.
OzProp and I have added DS18B20 temperature sensors to our R2D2s, to log ambient temperature.
This is a great idea Tubular. I was thinking of adding a one wire interface for one of these to my carrier board for this purpose, but your idea of simply modding/attaching on the P2D2 directly makes far more sense and avoids some additional connectors and wiring. Did you use true one wire (parasitic) operation or did you use its separate powered form?
Also I wonder if it is possible to dual purpose a serial port pin or flash pin for this somehow. Will have to dig into one wire protocol to see if this is doable. It might not be. Another possibility is to use a simple analog temp sensor and put a pin of the P2 into ADC mode.
Cluso, have you tried testing with different monitors? I wonder if the jitter is a feature of the monitor. When you send VGA to a flat screen monitor it has to digitize the video signal to be able to display it. If the timing is off a bit it can end up digitizing the signal right a the transition between adjacent pixels instead of in the middle of a pixel. This will cause the image to jitter as noise causes it sample at the end of a pixel versus the beginning of a pixel. When you touch the P2 you may be changing the clock frequency slightly, which will remove the jitter.
If you still have an old CRT monitor it would be interesting to see if it jitters. Or try other flat screen monitors.
Cluso, have you tried testing with different monitors? I wonder if the jitter is a feature of the monitor. When you send VGA to a flat screen monitor it has to digitize the video signal to be able to display it. If the timing is off a bit it can end up digitizing the signal right a the transition between adjacent pixels instead of in the middle of a pixel. This will cause the image to jitter as noise causes it sample at the end of a pixel versus the beginning of a pixel. When you touch the P2 you may be changing the clock frequency slightly, which will remove the jitter.
If you still have an old CRT monitor it would be interesting to see if it jitters. Or try other flat screen monitors.
I want to complete the code before I delve into the jitter too much. I did have it stable before. But when it gets hot it does cause jitter.
I'll have to find my multimeter temp probe. It's a bimetal joint that you press onto the surface. Probably a P2 ADC could be setup to use it.
Cluso99, I think you may be running the VCO too fast.
If you are clocking the chip at 100MHz+, bypass the VCO post-divider by using %1111 and run the VCO at the desired chip frequency.
For a 12MHz crystal, divide it by 24 to get 0.5MHz, then multiply that frequency in the VCO by 297, in order to get 148.5MHz.
Right now, you may be running the chip at 148.5MHz, but the VCO is going 297MHz. The whole thing is heating up and the 10-bit VCO divider is bumping into its limits at that frequency and temperature.
Just to confirm @cluso99 ozprop and I were also able to see shivers/shimmers today
@rogloh for the DS18B20 we are taking advantage of the external pullup on P58 that fixes the boot glitch. So the DS18B20 is on that pin (OzProp's idea, works well, but we're not using SPI nor MicroSD at this point). We've been joking about gluing an array to the top of the Prop so we can work out which pizza wedge corresponds to which cog
Cluso99, I think you may be running the VCO too fast.
If you are clocking the chip at 100MHz+, bypass the VCO post-divider by using %1111 and run the VCO at the desired chip frequency.
For a 12MHz crystal, divide it by 24 to get 0.5MHz, then multiply that frequency in the VCO by 297, in order to get 148.5MHz.
Right now, you may be running the chip at 148.5MHz, but the VCO is going 297MHz. The whole thing is heating up and the 10-bit VCO divider is bumping into its limits at that frequency and temperature.
Yes. I have a 12MHz oscillator (not xtal). When I was using 168 or 180MHz I was dividing by 12, then multiplying by 168 or 180, then %1111.
When I changed to 148.5MHz, I am dividing by 24, then multiplying by 297, then %1111.
Just to confirm @cluso99 ozprop and I were also able to see shivers/shimmers today
Is that running the same code ?
Previous ozprop report was shimmers needed a hand near the osc corner and it could stop totally. Is that still the case ?
Or do these shimmers more match Cluso99 reports of 'appear when hot' & 'can remove on touch'
Name 1920x1080p60
EDID Name 1080p
Aspect Ratio 16:9
Pixel Clock 148.5 MHz
Pixel Time 6.734 ns
Active Pixels 2,073,600 total
8-bit Memory 16,200 Kbits
32-bit Memory 64,800 Kbits
Data Rate 3.56 Gbps
Horizontal Timings
Active Pixels 1920
Front Porch 88
Sync Width 44
Back Porch 148
Blanking Total 280
Total Pixels 2200
Sync Polarity pos
Vertical Timings
Active Pixels 1080
Front Porch 4
Sync Width 5
Back Porch 36
Blanking Total 45
Total Pixels 1125
Sync Polarity pos
Cluso99, when the crystal divider is large, you get more jitter, due to less frequent feedback. Try this, instead:
....
Yes, but that sort of jitter is not likely to degrade with temperature so much ?
The code in #1 does not appear to use any post-vco divide, but it does not seem to have been updated ?
There is also a solution at 12/8*99 = 148.5MHz which is a change in operating point from /24 * 297, (PFD is 3x) but keeping VCO the same.
Hey Chip,
This looks to be much better. It has been running longer too. The P2 and pcb is hot still, but doesn't lose sync like it did before.
There are a few bugs in the display cog, but i've posted the code anyway.
Note the graphics that display the "c" moniker does have some horizontal flutter. Bars and lines are quite stable (not perfect).
I believe the field display is not perfectly synchronised to the syn pulses, so this needs some work to scope it out. I am not getting the edges of the display either so some porch adjustments are required. But hey, it works
It's still going some 5 or more minutes later. Never got this far before without losing sync.
Chip, what I think is that the vertical sync is not specifically timed with respect to the horizontal sync due to it being written directly with OUTNOT while the streamer is running somewhere in the background. I would like to try and get some actual timing relationship between the streamers xcont and the outnot.
While 2bpp is not working properly for me yet although the new settings may help (or its a bug of mine but too late tonight, maybe in the morning), I want to get the streamer logging pins to hub, then re-working the received stream into pixels to show on the VGA.
To have fun, you have to have an objective to your code
So I should be able to stream 512KB of 8 I/O at full clock speed, so that's 512K samples @ 148.5MHz (6.7ns) = ~3.53s of samples
Yes, I might have to go searching for my scope box. It's burried in the garage since the last move
I would imagine your VSYNC would be accomplished via 'DRVNOT #vsync_pin' and it would come right after a blank line. I suppose the monitors register VSYNC on HSYNC. I wish we knew if your HSYNC is consistent.
I am sure the HSYNC is consistent as it comes out the same as the rgb does. VSYNC on the other hand, while it will be consistent, it's the relationship to HSYNC that concerns me more. I am just not sure how to time the streamer with the generation of VSYNC.
Anyway, all will be revealed when I get the LA working on it
It's still going some 5 or more minutes later. Never got this far before without losing sync.
You did not mention losing sync before, just shimmers.
The attached code seems to be 180MHz, is that an old copy ?
When the chip got too hot the pic started to break up. Putting my finger/thumb cooled sufficiently to fix. Now I can run >30 minutes (not tested longer) without problems.
BTW I am fairly sure I posted the correct code. Did you check the CON section and not comments? Sorry cannot check on my phone.
Comments
The crystal oscillator is a single inverter. This keeps the gain low enough that the crystal doesn't go into an overtone mode. There is a string of 4 inverters, I think, that are fed by the XI pin, that sharpen up the incoming edges for clocking usage.
That may have been related to not having the VCO range, miss-match the counter ability ?
ie you do not want the VCO feedback loop, to have a peak f while settling, that is too fast for the counter, otherwise it will never settle.
With the new settings at 148.5MHz (12MHz osc then /24 then *297) it looks good and full screen width.
Now just need to play with the streamer to replay the hub twice to get full screen. Need to remove the 16x16 font for this to fit.
img: the Acer #2 doesn't display a pic at all. Complains invalid setting. Unfortunately I e discovered I cannot enter the menu (maybe push button faulty) so I don't know what setttings are there. It works fine on my laptop tho. Not going to waste time on this.
I loaded up the cogs and then used Hub as the video buffer.
Does some graphics. Some gets a bit jittery depending on the bitmap though coloured lines seems fine. Need more testing and adjustments as I suspect I am not seeing every pixel on screen Sotheby's sync and porches need adjusting.
640kB is simply fanciful, 5.75kB ought to be enough for everybody. LOL! Great work.
Actually I think mono 1080p might be quite useful.
My scope is too slow. I haven’t used it in 20 years.
However, I haven’t been trying to fix any jitter. I have just been getting it to run and move things around so I can load up the cogs and then I can use all 512KB of HUB for buffers
Now I’ve done that but had to remove all text and font from the graphics. Next I will put an 8x8 font into LUT and I have 5.75KB of HUB for a text buffer section. I have a font I used in P1.
Unfortunately will not have much time the next 3 days
Now I have a full screen I can check I can see all edges with a rectangle outline of pixels and adjust accordingly.
Then I can post for Peter or Lachlan to check temperatures. I am only running 2 cogs at 148.5MHz and it gets hot and starts to jitter fairly quickly which isn’t good. I need to check current etc.
OzProp and I have added DS18B20 temperature sensors to our R2D2s, to log ambient temperature.
Also I wonder if it is possible to dual purpose a serial port pin or flash pin for this somehow. Will have to dig into one wire protocol to see if this is doable. It might not be. Another possibility is to use a simple analog temp sensor and put a pin of the P2 into ADC mode.
If you still have an old CRT monitor it would be interesting to see if it jitters. Or try other flat screen monitors.
I'll have to find my multimeter temp probe. It's a bimetal joint that you press onto the surface. Probably a P2 ADC could be setup to use it.
If you are clocking the chip at 100MHz+, bypass the VCO post-divider by using %1111 and run the VCO at the desired chip frequency.
For a 12MHz crystal, divide it by 24 to get 0.5MHz, then multiply that frequency in the VCO by 297, in order to get 148.5MHz.
Right now, you may be running the chip at 148.5MHz, but the VCO is going 297MHz. The whole thing is heating up and the 10-bit VCO divider is bumping into its limits at that frequency and temperature.
@rogloh for the DS18B20 we are taking advantage of the external pullup on P58 that fixes the boot glitch. So the DS18B20 is on that pin (OzProp's idea, works well, but we're not using SPI nor MicroSD at this point). We've been joking about gluing an array to the top of the Prop so we can work out which pizza wedge corresponds to which cog
Yes. I have a 12MHz oscillator (not xtal). When I was using 168 or 180MHz I was dividing by 12, then multiplying by 168 or 180, then %1111.
When I changed to 148.5MHz, I am dividing by 24, then multiplying by 297, then %1111.
CON _XTALFREQ = 12_000_000 ' crystal frequency _XDIV = 12 * 2 ' crystal divider to give 0.5MHz _XMUL = 297 '148.5MHz '168 * 2 ' crystal / div * mul _XDIVP = 1 ' crystal / div * mul /divp to give _CLKFREQ (1,2,4..30) _XOSC = %01 'OSC ' %00=OFF, %01=OSC, %10=15pF, %11=30pF _XSEL = %11 'XI+PLL ' %00=rcfast(20+MHz), %01=rcslow(~20KHz), %10=XI(5ms), %11=XI+PLL(10ms) _XPPPP = ((_XDIVP>>1) + 15) & $F ' 1->15, 2->0, 4->1, 6->2...30->14 _CLOCKFREQ = _XTALFREQ / _XDIV * _XMUL / _XDIVP ' internal clock frequency _SETFREQ = 1<<24 + (_XDIV-1)<<18 + (_XMUL-1)<<8 + _XPPPP<<4 + _XOSC<<2 ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_00 ' setup oscillator _ENAFREQ = _SETFREQ + _XSEL ' %0000_000e_dddddd_mmmmmmmmmm_pppp_cc_ss ' enable oscillator '' 1920x1080 60Hz mode @ 148.5MHz from https://timetoexplore.net/blog/video-timings-vga-720p-1080p '' ---------------------------------------------------------------------------------- PIXEL_CLK = _CLOCKFREQ ' H_DISP = 1920 H_FPORCH = 88 H_SYNC = 44 H_BPORCH = 148 V_DISP = 1080 V_FPORCH = 4 V_SYNC = 5 V_BPORCH = 36 '' ---------------------------------------------------------------------------------- DAT org 0 video_buffer ' $00000 (hub ram 506.25KB) half screen 4bpp [w * h / 2] '+-------[ Set Xtal ]----------------------------------------------------------+ hubset #0 ' set 20MHz+ mode hubset ##_SETFREQ ' setup oscillator waitx ##20_000_000/100 ' ~10ms hubset ##_ENAFREQ ' enable oscillator '+-----------------------------------------------------------------------------+Is that running the same code ?
Previous ozprop report was shimmers needed a hand near the osc corner and it could stop totally. Is that still the case ?
Or do these shimmers more match Cluso99 reports of 'appear when hot' & 'can remove on touch'
Crystal divide = 4 (%000011)
VCO multiply = 99 (%0001100010)
VCO post-divide = 2 (%0000)
That will produce 12/4*99/2=148.5MHz.
And here are the timings for 1080p/60:
https://timetoexplore.net/blog/video-timings-vga-720p-1080p
Note the horizontal sync of 44 clocks.
Yes, but that sort of jitter is not likely to degrade with temperature so much ?
The code in #1 does not appear to use any post-vco divide, but it does not seem to have been updated ?
There is also a solution at 12/8*99 = 148.5MHz which is a change in operating point from /24 * 297, (PFD is 3x) but keeping VCO the same.
yes those timings for 1080p are what I am using and posted above.
I'll give those xtal settings a go.
This looks to be much better. It has been running longer too. The P2 and pcb is hot still, but doesn't lose sync like it did before.
There are a few bugs in the display cog, but i've posted the code anyway.
Note the graphics that display the "c" moniker does have some horizontal flutter. Bars and lines are quite stable (not perfect).
I believe the field display is not perfectly synchronised to the syn pulses, so this needs some work to scope it out. I am not getting the edges of the display either so some porch adjustments are required. But hey, it works
Chip, what I think is that the vertical sync is not specifically timed with respect to the horizontal sync due to it being written directly with OUTNOT while the streamer is running somewhere in the background. I would like to try and get some actual timing relationship between the streamers xcont and the outnot.
While 2bpp is not working properly for me yet although the new settings may help (or its a bug of mine but too late tonight, maybe in the morning), I want to get the streamer logging pins to hub, then re-working the received stream into pixels to show on the VGA.
To have fun, you have to have an objective to your code
So I should be able to stream 512KB of 8 I/O at full clock speed, so that's 512K samples @ 148.5MHz (6.7ns) = ~3.53s of samples
Yes, I might have to go searching for my scope box. It's burried in the garage since the last move
Attached is a video of the screen. Its not very good tho
Anyway, all will be revealed when I get the LA working on it
The attached code seems to be 180MHz, is that an old copy ?
When the chip got too hot the pic started to break up. Putting my finger/thumb cooled sufficiently to fix. Now I can run >30 minutes (not tested longer) without problems.
BTW I am fairly sure I posted the correct code. Did you check the CON section and not comments? Sorry cannot check on my phone.