Den 24.01.2021 21.51, skrev Noralf Trønnes: > > > Den 24.01.2021 19.38, skrev Lubomir Rintel: >> On Wed, Jan 20, 2021 at 06:00:30PM +0100, Noralf Trønnes wrote: >>> Hi, >>> >>> A while back I had the idea to turn a Raspberry Pi Zero into a $5 >>> USB to HDMI/SDTV/DSI/DPI display adapter. >>> >>> The reason for calling it 'Generic' is so anyone can make a USB >>> display/adapter against this driver, all that's needed is to add a USB >>> vid:pid. >>> >>> Unfortunately I've had some compounding health problems that have >>> severally limited the time I can spend in front of a computer. For this >>> reason I've decided to keep the gadget driver out-of-tree and focus on >>> getting the host driver merged first. >>> >>> See the wiki[1] for more information and images for the Raspberry Pi >>> Zero/4. >>> >>> One big change this time is that I've followed Peter Stuge's advice to >>> not let DRM stuff leak into the USB protocol. This has made the protocol >>> easier to understand just from reading the header file. >>> >>> Noralf. >>> >>> [1] https://github.com/notro/gud/wiki >> >> The patch set: >> >> Tested-by: Lubomir Rintel <lkundrak@xxxxx> >> >> Works like a charm with this board [1], though it didn't impress the girls >> as much as I hoped. Code here [2], picture here [3]. >> > > I have wondered what color display resolution it is possible to drive > over USB full speed. I can understand that your PoC wasn't that > impressive since it doesn't use DMA to drive the SPI bus. > I have now done a Raspberry Pi Pico implementation and driving SPI using DMA was just marginally faster than letting the CPU fill the FIFO. Maybe I shouldn't be so suprised since the CPU has nothing else to do, but even so I didn't expect this. But then again I have very little experience with microcontrollers. I have the same size display[1] as you 240x135 and my display was quite snappy (using X windows!), I even added lz4 decompression support. I haven't done much testing so I can't say how much the actual improvement is with the compression. The USB double buffering I was hoping for didn't pan out, the bulk endpoint can only do 64 byte packest (ISO is 512), so I ended up storing the packets and then push the frame in its entirety to the display. The Pico has 264kB of ram so I can afford to have a framebuffer and a decompression buffer for this tiny display. My target display is 320x240 and that means I can't use 2 buffers, so not sure how that goes. [1] https://shop.pimoroni.com/products/pico-display-pack Noralf. > The new $4 Raspberry Pi Pico that came out this week looks interesting > as a USB interface board for tiny panels. It can drive DPI panels > directly, has 2 cores @133MHz, 264K SRAM and USB full speed. Maybe lz4 > decompression is even possible. Another good thing is that the board > will be around for a long time. > > Thanks for testing, I have limited bandwith these days so I couldn't do > a test on an MCU myself. > > Noralf. > >> [1] https://www.banggood.com/LILYGO-TTGO-T-Display-GD32-RISC-V-32-bit-Core-Minimal-Development-Board-1_14-IPS-p-1652870.html?rmmds=search&cur_warehouse=CN >> [2] https://github.com/hackerspace/libopencm3-gf32v-examples/commit/7ef51b31b9 >> [3] https://people.freedesktop.org/~lkundrak/lilygo.jpeg >> >> Had to apply a fix for the drm_connector_enum_list[] ommission I mentioned >> elsewhere, and that I've now noticed you've noted previously. >> >> Take care >> Lubo >>
