Recommendation please? Need well tested P2 HDMI driver - text and line drawing
Stephen Moraco
Posts: 303
in Propeller 2
Hi, I'm looking for a stable/tested HDMI driver I can use during my latest development effort.
Do you have a well-used favorite?
(I've been hunting but the most capable ones I've tried so far seem to be unstable/interfere with PNut/Propeller Tool use of debug(). I haven't tracked down why... but am perplexed.)
Comments
How are you planning to use the DEBUG statement in the HDMI driver?
If DEBUG is located in the PASM driver COG it will very likely interfere with the output due to the timing being interrupted while the BRK instruction is being serviced. I'd hope the DEBUG handler in PropTool doesn't somehow interrupt/suspend a COG if the BRK is not issued by that COG.
Personally I've used DEBUG in non-video COGs in FlexSpin and that seems to be okay with my own video driver, from the limited testing I've done with it.
One issue you may be encountering is that the PLL clock frequency is being changed by the driver after startup and this is interfering with the DEBUG output baud rate...? I know evanh had some suggestions for working around this...I think you can set the operating startup frequency to be whatever the video driver will also use.
Not planning to use debug() in the HDMI driver. Just in the rest of the project.
The HDMI driver will be used to display variable values in various parts of the project as I'm developing the project. I'm transitioning from Debug() use for some of this as I need less lag in the display of the values.
Over time some Debug() will continue to be used but my more time-sensitive output will be shown via HDMI screen. HDMI driver is fed a display list for each object needing something displayed and then just iterates over the values in its own Cog.
This make more sense?
Yep. If you gave my driver a try what do you find tends to happen with it in your setup when you use it with PropTool and DEBUG? It can be used for both text and graphics regions, though for now you'll probably need to write your own line drawing code into the frame buffer - which is not too hard.
I am using this one on my project to run the little 7" HDMI display from Parallax. Works great!
https://www.parallax.com/dvi-vga-text-driver-demo/
Can confirm I had this problem. Was able to work around it by discovering the Clock Speed with
send("Clock Speed: ") vid.dec(clkfreq) send( $0D, $0A)It would return Clock Speed: 270000000
I placed it in the main() after the DVI was started (obviously). Once I knew what the driver was configured for, I set this in the con area of the top file.
_xtlfreq = 20_000_000 _clkfreq = 270_000_000After placing the debug information in the spin2 file I wanted to debug, all was good.
Yep, driver, you suggested works. Thanks!
Your driver works without any side effects that I was seeing with other drivers. I ended up using p2textdriver0_92b
It turns out that some of my confusion when searching for drivers was the DVI is used when I was hunting for HDMI... I'm constantly learning!
Yeah HDMI is basically just TMDS video underneath plus some extra stuff for the other HDMI specific features. Both systems use the same type of TMDS signalling for their video portions. You can send DVI signals into HDMI monitors using the right cable adapters and they should mostly accept it. DVI will just be unencrypted video only, while HDMI can also have HDCP protection and other audio and video features present. The same TMDS encoders are used for both but HDMI uses additional control bits not used by DVI for signalling/delimiting these extra features. These are passed in the "data islands" sent during horizontal and vertical blanking intervals. The low level line coding used for that portion is called TERC4.
Signalling wise, HDMI is a superset of single-link DVI. So, long story short: The DVI driver works with HDMI devices.