search

rm-hull / luma.lcd

Python module to drive PCD8544, HT1621, ST7735, ST7567 and UC1701X-based LCDs
https://luma-lcd.readthedocs.io
MIT License
156 stars 56 forks source link

Thoughts on Bridgetek EVE (Embedded Video Engine) #133

Closed mattblovell closed 3 years ago

mattblovell commented 3 years ago

Have you encountered displays using the Bridgetek EVE[234] controllers?

https://github.com/RudolphRiedel/FT800-FT813 (C driver, MIT License) https://www.ftdichip.com/EVE.htm

Would these be difficult to incorporate into luma.lcd, for, say, a new Python programmer -- asking for a friend :) There's a 4.3" IPS display from Newhaven Display that looks like it could be a nice upgrade from the TN panel I've been using:

https://www.newhavendisplay.com/nhd43800480ftcsxpctp-p-9663.html

The resolution is certainly high (800 x 480), but my use model mostly consists of static information (just a progress bar and elapsed timer changing most of the time). High frame rates would not be a goal.

rm-hull commented 3 years ago

Short answer is no, I hadn’t seen these display controllers before. I had always resisted supporting higher resolution devices because of the slow frame rates that a python implementation would yield.

However, since the advent of the latest diff_to_previous() changes, this may not be such a huge issue, but it would still mean that we would need to write and test any new driver code.

An alternative is that if there is already a kernel framebuffer implementation for this device (i.e. it exports a /dev/fb0 device), then we can simply use the luma.core.device.linux_framebuffer() pseudo-display right now.

mattblovell commented 3 years ago

An alternative is that if there is already a kernel framebuffer implementation for this device (i.e. it exports a /dev/fb0 device), then we can simply use the luma.core.device.linux_framebuffer() pseudo-display right now.

Ah, I had not realized that functionality existed as part of luma.core. For display through /dev/fb* I was thinking one had to switch to something like Pytorinox's framebuffer.py. Good to learn something new!

I'll need to review the documentation for those EVE controllers further. They seem quite a bit different than other controllers. The marketing for the displays targets fairly low-powered hardware (like Arduino's), with EVE offering extensive onboard support for rendering text, drawing primitives, etc. I think the display controller ends up being more powerful than the connected microcontroller! I still need to see if they even offer the usual "make the pixel at this location this color" capability. :)

mattblovell commented 3 years ago

Version 1.2 of Bridgetek's FT81X Series Programmer's Guide can be found here:

https://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/FT81X_Series_Programmer_Guide.pdf

Perhaps I'm missing it, but I don't think the EVE controllers offer a pixel-based framebuffer for external use. Most of the programming guide is devoted to the high-level commands one can issue (Section 4). One can transfer bitmaps, with compression. I don't know enough to recognize whether that forms a viable alternative drawing path for Pillow images or not!

It's fine with me if you want to close this out. I'd just thought I would explore a bit.

rm-hull commented 3 years ago

Well, if it supports sending bitmaps, then we can make it work - after all that is all that the device.display(image) method does. The image parameter is a Pillow image type, but of course it can be serialized into a JPEG or PNG byte stream and sent to the device

mattblovell commented 3 years ago

https://brtchip.com/bt81x/ (UPDATE: Oops, I think this is for the newer EVE chips)

may be a nicer starting point. There are links from that page to lots of demos, and the BT81x datasheet, as well as the Programmer's Guide.

Well, if it supports sending bitmaps, then we can make it work

RAM_G appears to be a 1 MiB space that is the device's general purpose graphics RAM (main memory). SPI commands can write directly there. In addition, there are several coprocessor commands that seem geared to assisting with image copying / decompression:

The majority of the coprocessor CMD_* commands are for the built-in GUI widgets (sliders, dials, keys, gradients, etc) or for managing the on-board flash memory.

Once in memory, there are several related Display List commands:

So, maybe it would be possible. The big thing I'm uncertain about is how one goes about updating an existing bitmap safely (i.e., without getting any bad artifacts onscreen). Can one update an existing bitmap in-place?

mattblovell commented 3 years ago

I went ahead and ordered the Newhaven display I mentioned at the start of this thread.

It should hopefully be fun to play with. More fun, anyway, than wrestling with DRM/KMS applications to share a GPU to drive an HDMI display! :)

The display uses the FT813 EVE (Embedded Video Engine). The long link I posted above to the FT81x Programming Guide is the relevant one. (The shorter link is for what I believe is the newer generation family of EVE chips.)

mattblovell commented 3 years ago

I went ahead and ordered the Newhaven display I mentioned at the start of this thread.

Scratch that. Upon reading through the programming guide in more detail, I'm afraid it's not well-suited to my application. There are indeed two ways of getting a bitmap onto the FT813 -- either transfer the data directly into RAM_G or use one of the co-processor commands (CMD_INFLATE, CMD_LOADIMAGE) to handle decompression and the jpg or PNG format on your behalf. However, all of the RGB pixel formats have fairly limited color-depth! The highest appears to be 16 bits (e.g., RGB565).

There is a PALETTED8 format to handle an indexed-color bitmap. The indexed colors are each 32-bits (full ARGB, 8 bits for each channel including alpha), but I'm pretty sure the bitmap is then limited to having at-most 256 distinct colors.

The RAM_G area is only 1 MiB in size. For either 800x480 or 800x600 (the controller's maximum resolution), that is only sufficient space for 16 bits per pixel.

I think the EVE series of controllers really is intended more for applications in which one is mainly using the controller's built-in widgets or a set of small(ish) bitmaps to construct a GUI or information panel. Given the color depth restrictions, the series doesn't seem well suited for true color bitmaps.

So, I guess my search for a SPI-connected IPS panel of decent resolution and size (>3.2 inches) has to continue.

Thanks to @rm-hull for entertaining my wild thought.

rm-hull commented 3 years ago

I did actually send off a request for an evaluation kit, but got a generic brush-off:

Hello Richard,

Thank you for your interest in Newhaven Display.

Due to recent changes to our policy, unfortunately we cannot provide free of charge samples. Samples may be purchased directly from our website or through one of our distributors such as Digi-Key or Mouser Electronics.

Please let me know if you have any questions.

Best Regards,

S----- M------ | Technical Support

Newhaven Display International, Inc. 2661 Galvin Court, Elgin, IL 60124 - USA Call: 847.844.8795 | Fax: 847.844.8796 www.newhavendisplay.com

mattblovell commented 3 years ago

I did actually send off a request for an evaluation kit, but got a generic brush-off

Well, it worth a shot! :)

Hunting around further for anything ellse "interesting" that's SPI-connected, there is this product. built around an RA8876 and intended for use as an Arduino shield:

http://www.techtoys.com.hk/BoardsKits/HDMIshield/HDMIshield.htm

The RA8876 looks to have full 24-bit color depth, depending upon how much SRAM one is willing to throw down on the board. It has a general purpose framebuffer, well more than one actually, with HW assist for picture-in-picture and (I think) panning. There are a few graphics primitives as well, but different than the EVE line. The support for true color RGB888 pixels is appealing.

The price is a little high, though, particularly when combined with that of a decent HDMI panel.

Adafruit has a somewhat similar breakout board / adapter based upon the RA8875, for directly driving a TFT panel. That controller looks to be limited to at-most 16-bit color depth, though.

The RA8875 is a powerful TFT driver chip. It is a perfect match for any chip that wants to draw on a big TFT screen but doesn't quite have the oomph (whether it be hardware or speed). Inside is 768KB of RAM, so it can buffer the display (and depending on the screen size also have double overlaying). The interface is SPI with a very basic register read/write method of communication (no strange and convoluted packets). The chip has a range of hardware-accelerated shapes such as lines, rectangles, triangles, ellipses, built in and round-rects. There is also a built in English/European font set (see the datasheet section 7-4-1 for the font table) This makes it possible to draw fast even over SPI.

The RA8875 can also handle standard 4-wire resistive touchscreens over the same SPI interface to save you pins. There's an IRQ pin that you can use to help manage touch interrupts. The touchscreen handler isn't the most precise driver we've used, so we broke out the X/Y pins so you can connect them up to something like the STMPE610 which is a very classy touchscreen controller.

I started looking at such adapters after getting frustrated with a 4" IPS HDMI panel I was hoping to use with an RPi4. Unfortunately, the modern GPU drivers for Pi -- well, Linux generally -- don't seem keen on providing distinct framebuffers for each head. I think I'll just have to wait to see what develops.

In the meantime, I'm going to try a 3.5" IPS SPI-connected 480x320 panel with an ILI9486L controller. That controller seems a fairly close relative to the ILI9341 (18-bit color depth, SPI transfers look to be the same), so I think I can get it working with luma.lcd with relatively few changes.

(If you haven't noticed, I really want to move to an IPS panel!)

UPDATE: Github for that TechToys HDMI shield (BSD license) https://github.com/techtoys/HDMI-Shield/tree/master/Ra8876_Lite

mattblovell commented 3 years ago

@rm-hull -- bump just for last update. Since I posted to an already closed issue, I thought no notification might get sent. I thought you'd appreciate the content, though.

rm-hull commented 3 years ago

Cheers @mattblovell ... good to know

a lot of my GitHub notifications (inc yours) seem to just go straight to the spam folder even though I’ve may times told gmail that they aren’t spam

-sigh-