search

notro / gud

GUD USB Display
151 stars 7 forks source link

stm32f4 ili9486 finally works but sum confusion #15

Open bm16ton opened 1 year ago

bm16ton commented 1 year ago

Hello, I have a ili9486 rasp pi tft with the spi shifter (I know you lament releasing the schematics to make that possible but I love mine THANK YOU!) I kept having the issues of everything coming from gud/usb being rotated by 180 degrees and colors being sorta inverted. Im all arm64 these days so I thought maybe it was an endian problem. I added __builtin_bswap16 and it fixed everything! But when i finally was able to test on x86 it had exact same problems and needed the same bswap fix. So now im convinced I did something else wrong and this is hackishly getting around it. Didnt know but maybe a common thing? One last question on the ili9486 with spi shifter subject. I see from your code comments and replies to issues that sum data needs to be sent 16bit and sum 8bit. Unfortunately im to new to firmly grasp the wording. Does that mean the displays you worked on didnt need all data sent as 16bit with the 8bit data being padded? I have to send everything 16bit with all 8 bit values padded (hope im using "padded" correctly here, i mean i use "foo >> 8" on everything 8bit) Because my screen definitely needs everything that way, but possibly those 8bit values are still called 8bit after being padded. Im just not sure how the wording/naming works here. Again thank you this has been a lot of fun for me. I would offer a pr to the libopencm3 variants but im afraid my code is extremely hackish, ugly, and just plane bad (tho it works).

notro commented 1 year ago

What do mean by rotated, the whole frame?

Pixel data coming from the host is in little endian format, so it depends on what you do with it. I assume your microcontroller is little endian as well so it should just work. If you configure the SPI controller for 8-bit width, you'll get into trouble however since the bus will put out the individual bytes one by one resulting in big endian order.

As for the shifting and padding it's a long time since I looked at that, but I think the 8-bit commands and 8-bit command data needs to be padded to 16-bit, but pixel data is already 16-bit so needs no padding.

bm16ton commented 1 year ago

Thank you for your response! Yes the whole frame woukd be off 180degrees with usb data vs anything id print from inside firmware. i assume it was just a bad pc side setting and currrently have the rotation set to upside down in my window manager. The fact that 8bit vs 16bit changes the msb/lsb is unbelievably helpful! Very huge piece of the puzzle explained.With spi at 16bit color was fine but image was terrible and at 8 bit image was fine but color was off. I currently switch between 8 and 16 to get around that. And you explained the exact way i have to do it terms of padding the 8 but not the 16 etc. But its great i simply reverse the endian then dump to dma, so cool! Thank you for your amazing work and hopefully these little tidbits of info here willl help someone else.

On Thu, 17 Nov 2022, 4:48 am Noralf Trønnes, @.***> wrote:

What do mean by rotated, the whole frame?

Pixel data coming from the host is in little endian format, so it depends on what you do with it. I assume your microcontroller is little endian as well so it should just work. If you configure the SPI controller for 8-bit width, you'll get into trouble however since the bus will put out the individual bytes one by one resulting in big endian order.

As for the shifting and padding it's a long time since I looked at that, but I think the 8-bit commands and 8-bit command data needs to be padded to 16-bit, but pixel data is already 16-bit so needs no padding.

— Reply to this email directly, view it on GitHub https://github.com/notro/gud/issues/15#issuecomment-1318364592, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP3T5MWBVGZMR4BLIETWIX5OHANCNFSM6AAAAAASAEYINY . You are receiving this because you authored the thread.Message ID: @.***>