One of the problems we have is that we only have 16kB of ROM total and we really had to do some squeezing.
I hope you've carefully replaced every RET with _RET_ :P
While I love those _ret_ modes and I use them wherever I can, they still only add up to a handful of longs that are saved. Where I can save memory is by figuring out what is essential for working with the ROM, and the things that can easily be added afterwards. The ROM is mainly for booting but it also provides a way of communicating with the chip and hardware itself, either as a sanity check in case external memory is playing up, or as an IDE free programming environment, or simply to interact with the hardware directly.
What I would like it to do though is support VGA directly from ROM so that it at least displays some basic information about the chip. I could sense 75 ohm termination on the I/O and assume VGA is connected. I'm not sure whether this will fit in though, even with a small font table.
If we had more ROM space we could do all kinds of IDE free stuff, even turning the P2 into its own development system from the bare chip. Then USB would be possible too.
BTW - the P2 has been running flawlessly through a high speed slide show at 340MHz. I thought I had a glitch but it turned out to be a simple software wraparound bug. The speed the images are flashing up at would do a Hollywood computer proud. That reminds me, I might add some sound to it now and write a version of the breakout game or even space invaders.
What I would like it to do though is support VGA directly from ROM so that it at least displays some basic information about the chip. I could sense 75 ohm termination on the I/O and assume VGA is connected. I'm not sure whether this will fit in though, even with a small font table.
If we had more ROM space we could do all kinds of IDE free stuff, even turning the P2 into its own development system from the bare chip. Then USB would be possible too.
? - but if basic info is what you want, that can be sent over a serial link, and any ROM hosted VGA is going to be so crippled, it may detract rather than appeal ?
It seems smarter to have fundamental and useful items, like single-pin-boot, in the ROM, ahead of niche and partial VGA features ? Leave that for P3 with larger ROM ?
Also useful, would be some simple Oscillator calibrate routine.
eg I think I've suggested before, that AutoBaud be capable of echo of the chosen dividers for the OSC.
Serial link is always there, that's part and parcel of TAQOZ but VGA display is a bonus. Don't you like something extra for nothing? Everybody does. But you have always been caught up with single pin boot and what gets me is rather than continue to talk about it, why you haven't even played with P2 FPGA in all these years that you could have developed a support micro that loaded the P2 via a single pin. Personally I'm not concerned about single pin boot since I would always want some form of Flash storage available anyway. What's the point of saving 3 pins just to use 4 again for storage?
Auto-baud could probably calculate what the baud rate of the input is if it is a standard baud rate since RCFAST will be within a certain region but that's not important.
I'm busy with exercising practical and usable aspects of the P2, building up a new ROM, another new P2D2 PCB and dev board, and many other aspects of P2 development and testing. However if I mention some feature, it's usually because I've done it, doing it, or intend to do it.
Don't you like something extra for nothing? Everybody does.
If it really comes at zero cost, sure, but it's more a simple question of where finite ROM resource is best spent.
I've already mentioned 2 features that are not in the ROM, and so there is an opportunity cost, right there.
I'm sure there are more simple features that others can think of, which they would rank ahead of VGA--.
..that you could have developed a support micro that loaded the P2 via a single pin. Personally I'm not concerned about single pin boot since I would always want some form of Flash storage available anyway. What's the point of saving 3 pins just to use 4 again for storage?
Oh, I have code for a Single pin Micro host already, that's not difficult. If you cannot see the merit, why exclude it from others ?
There have been posts on here asking what P2 can manage, and common is around how many smart pins can users actually use.
Some application will be using P2 purely for the smart pins, they will not need external storage - ie P2 will be a peripheral, not a host.
Auto-baud could probably calculate what the baud rate of the input is if it is a standard baud rate since RCFAST will be within a certain region but that's not important.
I'm not following the logic here - are you really saying the frequency of RCFAST is of no concern to users ?
If that were true, why do all the other MCU vendors take the trouble to offer calibrated Oscillator MCUs ?
Autobaud already calculates timing, it just keeps the SysCLK cycles result secret from the user, so they do not know the RCFAST value.
Anybody get 1080p working yet?
Looks to me like monitors have a low end vertical refresh of 56 Hz, meaning we need 280 MHz clock...
Oops, I was thinking about digital output with 140 MHz output clock.
I guess we only need 140 MHz for analog...
No. Peters code unmodified. I have an Acer X233H 1920x1080 23" with VGA and DVI inputs, and a Dell 24" 1920x1080 with VGA and HDMI inputs.
A few months ago I threw out all my old smaller VGA monitors. May be regretting that now.
Now I am wondering about 3 or 4 pin modes which use sync on the green pin.
I am just looking at the various code to see how it works and wondering what resolution I might be able to get to with VGA.
I have just been working out what is required for 1980x1080p @180MHz
With the visible component of 1440x540 it works. I noticed the P2 gets hot w/o a fan and does start to shiver. A finger on the P2 fixes short term. I have posted this code below.
With the visible component of 1680x540 it fails by scrolling horizontal as the line buffer isn't fast enough.
Note there isn't enough hub ram for a full graphics 1920x1080 display.
Gets hot at 180 MHz? I thought we could get to 250 MHz without a fan... Guess not...
We may find a couple implementations make longer term sense.
1. Board, no fan, modest clock.
2. Board, fan maybe heat sink, higher clock.
3. System designed for maximum clocks.
Personally, I'm happy that we can run the clocks we've seen run. Maybe the respin will improve, and for sure, does not degrade. Either way, these are reasonably nice problems to have.
A P2 running at 100mhz is going to be powerful, useful, for example. Education, for example, may just adopt a modest, standard clock.
Based on what I've seen so far, I know I'm going to keep that in mind. Make sure code can run at various clocks, and or test limits. People will be running these at a variety of clock speeds.
.... I noticed the P2 gets hot w/o a fan and does start to shiver. A finger on the P2 fixes short term. I have posted this code below.
hmm... Is that time-domain, or analog domain shiver ? eg Could the SMPS be running out of headroom ?
Hopefully it is not some P2 internal effect, as other tests indicated 180MHz was easily meeting spec, and that spec targets Vmin and 125'C die MAX.
Note there isn't enough hub ram for a full graphics 1920x1080 display.
Maybe you need one of these ? "OCTOBER 10, 2018 NXP Introduces High Performance, Arm Cortex-M33 / DSP Crossover Processor with 4.5MB on-chip SRAM" (VFBGA176)
Note there isn't enough hub ram for a full graphics 1920x1080 display.
Maybe you need one of these ? "OCTOBER 10, 2018 NXP Introduces High Performance, Arm Cortex-M33 / DSP Crossover Processor with 4.5MB on-chip SRAM" (VFBGA176)
Cluso, get yourself a can of RS components freeze spray. It'll let you overclock long enough to run tests. Or just add a small fan.
The other day we needed to deliberately heat the board while it was on dry ice. Running at 350 Mhz for a short while achieved this. We also noticed a bit of slipping, need to investigate further.
You need a good USB cable because any voltage drops result in high current draw from the SMPS and high current draw results in higher voltage drop! Although I use a microUSB for my serial cable, I also use a heavy USB A to USB A which I plug into the USB A on my matrix board to give a nice solid 5V. I find that USB ports have no trouble supplying the extra current, but the cables have to be up to it.
I once ordered a box load of micro USB cables from eBay only to find out that they were essentially useless since they use signal wire for the power and ground, and signal wire here means a very thin strip of foil wrapped around a thread. Since none of them advertise the cable resistance I found you need to order tablet charger cables instead. But the longer the cable, the greater the voltage drop, the greater the current!
Ray, the P2D2 is fine even at 250MHz I find, although it is a bit warm, but not overly hot. However I have my fan mounted on the flip side of the board with adhesive pads providing the clearance. The board never even gets warm even though I run at 320MHz.
I will try some other clock configurations to see how they affect the monitor but I have noticed that sometimes because I might have a completely black background that the monitor's autoset has trouble. So I use a white or non-black background instead and autoset the monitor from that.
With my board running Cluso's code image is fine.
The 'shiver' appears if I place a finger on the chip near the XO/Xi corber.
The closer I get to the oscillator corner the worse it gets eventually losing video all together.
With my board running Cluso's code image is fine.
The 'shiver' appears if I place a finger on the chip near the XO/Xi corber.
The closer I get to the oscillator corner the worse it gets eventually losing video all together.
So you have not touched anything electrically - this is all proximity ?
That's sounding very delicate - I wonder if the right xtal Caps are selected, and are they working ?
What does a counter/scope on HS/VS indicate ?
Has anyone with a real P2 tried change of the internal OSC CAPs and measuring what ppm shift that gives, with the fitted crystals ?
Comments
While I love those _ret_ modes and I use them wherever I can, they still only add up to a handful of longs that are saved. Where I can save memory is by figuring out what is essential for working with the ROM, and the things that can easily be added afterwards. The ROM is mainly for booting but it also provides a way of communicating with the chip and hardware itself, either as a sanity check in case external memory is playing up, or as an IDE free programming environment, or simply to interact with the hardware directly.
What I would like it to do though is support VGA directly from ROM so that it at least displays some basic information about the chip. I could sense 75 ohm termination on the I/O and assume VGA is connected. I'm not sure whether this will fit in though, even with a small font table.
If we had more ROM space we could do all kinds of IDE free stuff, even turning the P2 into its own development system from the bare chip. Then USB would be possible too.
BTW - the P2 has been running flawlessly through a high speed slide show at 340MHz. I thought I had a glitch but it turned out to be a simple software wraparound bug. The speed the images are flashing up at would do a Hollywood computer proud. That reminds me, I might add some sound to it now and write a version of the breakout game or even space invaders.
? - but if basic info is what you want, that can be sent over a serial link, and any ROM hosted VGA is going to be so crippled, it may detract rather than appeal ?
It seems smarter to have fundamental and useful items, like single-pin-boot, in the ROM, ahead of niche and partial VGA features ? Leave that for P3 with larger ROM ?
Also useful, would be some simple Oscillator calibrate routine.
eg I think I've suggested before, that AutoBaud be capable of echo of the chosen dividers for the OSC.
Auto-baud could probably calculate what the baud rate of the input is if it is a standard baud rate since RCFAST will be within a certain region but that's not important.
I'm busy with exercising practical and usable aspects of the P2, building up a new ROM, another new P2D2 PCB and dev board, and many other aspects of P2 development and testing. However if I mention some feature, it's usually because I've done it, doing it, or intend to do it.
I've already mentioned 2 features that are not in the ROM, and so there is an opportunity cost, right there.
I'm sure there are more simple features that others can think of, which they would rank ahead of VGA--.
Oh, I have code for a Single pin Micro host already, that's not difficult. If you cannot see the merit, why exclude it from others ?
There have been posts on here asking what P2 can manage, and common is around how many smart pins can users actually use.
Some application will be using P2 purely for the smart pins, they will not need external storage - ie P2 will be a peripheral, not a host.
I'm not following the logic here - are you really saying the frequency of RCFAST is of no concern to users ?
If that were true, why do all the other MCU vendors take the trouble to offer calibrated Oscillator MCUs ?
Autobaud already calculates timing, it just keeps the SysCLK cycles result secret from the user, so they do not know the RCFAST value.
Looks to me like monitors have a low end vertical refresh of 56 Hz, meaning we need 280 MHz clock...
Oops, I was thinking about digital output with 140 MHz output clock.
I guess we only need 140 MHz for analog...
Color VGA using Peters code posted at the top of this thread.
Did you just use the code as is which looks like it uses separate vsync, or modify it somehow for combined sync?
A few months ago I threw out all my old smaller VGA monitors. May be regretting that now.
Now I am wondering about 3 or 4 pin modes which use sync on the green pin.
I am just looking at the various code to see how it works and wondering what resolution I might be able to get to with VGA.
Here's an old VGA demo updated for silicon that might help.
It supported a few video modes.
With the visible component of 1440x540 it works. I noticed the P2 gets hot w/o a fan and does start to shiver. A finger on the P2 fixes short term. I have posted this code below.
With the visible component of 1680x540 it fails by scrolling horizontal as the line buffer isn't fast enough.
Note there isn't enough hub ram for a full graphics 1920x1080 display.
That's good to know.
A small little cheap heat sink can go far. I saw Mouser had some for like $2.
We may find a couple implementations make longer term sense.
1. Board, no fan, modest clock.
2. Board, fan maybe heat sink, higher clock.
3. System designed for maximum clocks.
Personally, I'm happy that we can run the clocks we've seen run. Maybe the respin will improve, and for sure, does not degrade. Either way, these are reasonably nice problems to have.
A P2 running at 100mhz is going to be powerful, useful, for example. Education, for example, may just adopt a modest, standard clock.
Based on what I've seen so far, I know I'm going to keep that in mind. Make sure code can run at various clocks, and or test limits. People will be running these at a variety of clock speeds.
hmm... Is that time-domain, or analog domain shiver ? eg Could the SMPS be running out of headroom ?
Hopefully it is not some P2 internal effect, as other tests indicated 180MHz was easily meeting spec, and that spec targets Vmin and 125'C die MAX.
I'd guess a PLL lock issue would be a lot more than 'shiver'
The XCL220 is rated at just 1A, and the Pd curve starts downwards from 25'C, - initial P2D2 boards are just 2 layers.
Maybe you need one of these ?
"OCTOBER 10, 2018 NXP Introduces High Performance, Arm Cortex-M33 / DSP Crossover Processor with 4.5MB on-chip SRAM" (VFBGA176)
You could do a tile mode.
Will be interesting to see if better to use lower clock freq to avoid heating issues...
You could clock at 297MHz or 148.5MHz.
The other day we needed to deliberately heat the board while it was on dry ice. Running at 350 Mhz for a short while achieved this. We also noticed a bit of slipping, need to investigate further.
I am powering from my laptop USB as well.
Certainly there are a few things to check. The code is doing a lot of continuous work changing the screen continuously.
I once ordered a box load of micro USB cables from eBay only to find out that they were essentially useless since they use signal wire for the power and ground, and signal wire here means a very thin strip of foil wrapped around a thread. Since none of them advertise the cable resistance I found you need to order tablet charger cables instead. But the longer the cable, the greater the voltage drop, the greater the current!
Ray, the P2D2 is fine even at 250MHz I find, although it is a bit warm, but not overly hot. However I have my fan mounted on the flip side of the board with adhesive pads providing the clearance. The board never even gets warm even though I run at 320MHz.
I will try some other clock configurations to see how they affect the monitor but I have noticed that sometimes because I might have a completely black background that the monitor's autoset has trouble. So I use a white or non-black background instead and autoset the monitor from that.
The 'shiver' appears if I place a finger on the chip near the XO/Xi corber.
The closer I get to the oscillator corner the worse it gets eventually losing video all together.
That's sounding very delicate - I wonder if the right xtal Caps are selected, and are they working ?
What does a counter/scope on HS/VS indicate ?
Has anyone with a real P2 tried change of the internal OSC CAPs and measuring what ppm shift that gives, with the fitted crystals ?