Low cost 7" display with HDMI and USB
Rayman
Posts: 14,145
Just got this display working with the Digital Video Output accessory (AKA HDMI).
Had to hack in some extra power because the onboard USB doesn't supply enough power for the backlight.
Issue now is there is not enough RAM for 1024x600 @8bpp.
What I'm doing here is showing a 1024x300x8bpp twice.
Have to either drop to 2 or 4 bpp or invoke PSRAM...
Also, the touchscreen doesn't seem to work with this driver, hopefully will with a newer one...
Update: Actual display resolution is 1024x600, fixing these posts...
480 x 640 - 181K
Comments
If usb touch doesn't work, think can hack in direct I2C connection to capacitive touchscreen. Might be easier than developing a driver...
Wow touch as well. So the touch works OK with the Pi over USB, presumably. Is there a separate touch chip that processes the touch input? Something like an AR1010?
Well the touch works with Windows
That was interesting
Most cap touch have an i2c chip built in.
This has a chip that must covert i2c to USB.
Might have to remove that one…
That's an interesting resolution. I've seen the usual 1024x600 and 1280x800 panels but not 1200x600. It's a perfect 2:1 aspect ratio, probably with square pixels as well.
@rogloh Appears it is actual 1024x600. No idea where I got 1200x600 stuck in my head...
Interesting that it works even given wrong resolution...
This is it: https://www.amazon.com/gp/product/B08Z1HG8N9?th=1
There are plenty like it for ~$50
Ok that makes more sense then. Yeah I have a 1024x600 panel here too with touch and it can be driven by the P2. I think it's a Waveshare model. The touch output appeared as a mouse raw report over USB.
https://forums.parallax.com/discussion/comment/1550950/#Comment_1550950
Here's the chip and it's connection to the touchscreen. Can't seem to find any detail on the chip.
@rogloh So you've been able to use the P2 to talk to a similar touch panel already? That's good to know...
Well, strange was able to easily get an image when thought was 1200x600. Having trouble getting a 1024x300 image to show...
Yeah I had issues with timing on these displays until I found something that worked. You may have to experiment a bit.
https://forums.parallax.com/discussion/175364/waveshare-touchscreens-at-1024x600-and-p2-hdmi-vga
Thanks Rogloh! Seems I shouldn't have started a new thread on the sameish subject...
Probably didn't find it because was searching for wrong resolution...
Ok, seems my real problem was with the Prop Tool. Was getting junk on the screen. Stable junk, but junk, and had no idea why, it made no sense at all.
Then, created another test image and it worked.
Went back to original image and nothing I could do made it work, and I could strangely make out a messed up version of the second image on the screen.
Then wondering how in the world is this possible....
Finally figured out that the first bitmap was not being included in the binary, even though it was included in the code with the "File" directive. I could tell by the code size in "info" that it wasn't there. Then, figured out that I must have earlier clicked on a subobject in the Prop Tools object list and it then opened all the files in the code including the .bmp file. So, the .bmp file was an open tab in the Prop Tool. Clicked on that tab and Prop Tool acted like it crashed with a error reporting window. But, it didn't actually crash and finally worked after closing that tab.
Anyway the display settings from first post in @rogloh thread two posts above this one seem to work fine.
Now, have to get touchscreen to work and decide on a bpp...
This version works with regular USB mouse, but not the USB touchscreen (yet).
Note: Uses P52 and P53 for usb diagnostics. You might want to change that or turn off...
Tried the USB code from @pik33 that @rogloh pointed me to above: https://forums.parallax.com/discussion/comment/1550950/#Comment_1550950
I'm also seeing the device code of 0EEF0005.
But, I'm only getting any data when four fingers are on the panel.
Seems need to tweak something...
After some poking, found that long[usb.get_hidpad_buffer()+256] has the x and y values for when one finger is on the display.
Some longs above 256 seem to have data when multiple fingers are on the display...
Now, need to see if can get usbnew to work in PropTool...
You really just need to take the if/end blocks out, I think (of course, if there's an else, you only want one side to be included).
@Wuerfel_21 Did that and it compiles but get 0 instead of touch values...
Must be something else to do...
Maybe something to do with FlexProp being hubexec....
I see a "loc" in the assembly. Don't think that works in Prop Tool...
LOC in relative mode works. Check if your modified version still works in flexspin, if not you just made a mistake.
Also, reading 256 bytes into the
hidpad_reportis wrong and bad. It only has 224 bytes. You will hiturx_buffby chance, which will for some amount of time maybe contain the raw device data. It's used for multiple purposes, so it gets overwritten all the time. The correct way of reading it would be to copy it somewhere else. A good place to do that is the beginning ofhid_decodeOk, maybe that's it. Perhaps the urx_buff is somewhere else in the PropTool version?
If you didn't have mouse enabled earlier, that'd do it.
Actually, the device ID is at start of hidpad_report and that doesn't work either...
Maybe I can try using the asm output of FlexProp.
Or, just use FlexProp. That's not so bad of this.
hidpad_report will only contain what data the HID parsing could gather (+ the ID). You need to modify the code to read any device that wouldn't place sensible data there. The raw report is only temporarily in urx_buf.
@Wuerfel_21 It is remarkable reliable for being a buffer overflow situation...
I'm still thinking it's all the LOC in assembly that makes it not work in Prop Tool.
In past things, had to always get rid of LOC and instead pass all the pointers from Spin to Assembly.
But, that's a lot of work... Think I'll just use FlexProp...
Way back in the P2V days, I was able to sniff PC to mouse USB packets and then later pretend to be a PC and just replay the conversation to get started and then just process the HID reports after that.
Very simple, but worked.
That's the other way could go here, but that's also a lot of work at this point...
Got it working with Prop Tool!
Fortunately, @Ariba posted a stripped down and Prop Tool compatible version here:
https://forums.parallax.com/discussion/comment/1554440#Comment_1554440
Did WinDiff with full one to see what the differences are.
Was nothing to do with LOC.
This was the actual problem:
CLKFREQ_PTR = $44'RJA $14Guess I'm still abusing the buffer overflow, but works great anyway...