BRT Community

Hi Toby,

Could you advise what type of images you will use? Are they full photos or mainly logos etc.

Normally if you would like to use images directly we would suggest png or jpg and then inflate via CMD_LOADIMAGE. However, png normally decompress to a format such as RGB565 (full colour) or ARGB4 (if image has transparency) which give good quality colour images.  Both of these take 2 bytes per pixel and so the image would be bigger than then RAM_G.    Mono png images would be L8 (1 byte per pixel) or in some cases an indexed image may be palleted. However, if you want to allow users to use most images without too many restrictions it would likely be the 2-bytes-per-pixel formats.

1024 x 600 x 2 = 614400 x 2 = 1,228,800 and so more than the 1MBytes RAM_G

If your image is a logo then you may be able to load it as smaller one with a background colour defined by EVE, or you could consider to load and scale up a slightly smaller image.

ASTC would be ideal for this but if you want to avoid the conversion then these options above may be good.

If you could send details of the typical image style we can see what else we can advise thought too,

Best Regards, BRT Community



 

How would I got about loading and displaying a large image (1024x600) from sd card on a Riverdi 7" display which uses a BT817?

Its for a boot screen which only needs to be displayed once at startup. I don't really want to have to get the user to convert images to ASTC format first, nor do I want to store the file in external eeprom either.

All the examples I see are for small images which fit into EVEs memory nicely... but what about full screen images?

Is there a a simple "picture frame" application which supports files from SD card for larger display sizes?

Cheers
Toby

Check this:This device is using an EVE3-50G from Matrix Orbital which has a BT815.

And a little over a week ago I found that the Polyend Tracker is using a FT812 soldered to the board.

Very nice to finally have some more products confirmed, unfortunately these are way to expensive to buy them for just the heck of it. 

Looking to streamline your next project?
🖥� Our upcoming Bridgetek webinar (Powering Performance: The Hardware Behind EVE) is exactly what you need.
Mark your calendars for June 24, 2026, at 3 PM UK time.
For Bridgetek IC Development Kits (more info in the webinar):
✅ 10% Discount just for registering.
✅ EXTRA 10% Discount for attendees (valid through July 3, 2026).
Stay ahead of the curve and save big on industry-leading hardware.
See you there!
Register now: https://42bmw.share.hsforms.com/2GonQDEuPRAeqtB7GKfo2yg
#TechWebinar #Bridgetek #ICDevelopmentKit #ElectronicsEngineering #Discount #TechPromo

🎉 100,000 Strong! 
We've officially hit 100K subscribers on YouTube — thank you for powering our journey and being part of the Bridgetek family. 🚀
💡 This milestone is just the beginning.
👉 Join us as we aim for the next big goal!


#Bridgetek #100KSubscribers #YouTubeMilestone #TechInnovation #CommunityCelebration

Thank you for sharing your solution.


Best Regards,
BRT Community

Posting a followup in the hopes that it helps someone else in the future.  The root cause issue turned out to be an undocumented requirement with the FT811 that the REG_HCYCLE value must be greater than the sum of the REG_HOFFSET and REG_HSIZE values (same is true for the vertical timing).  I actually did have the ST7789 configured properly and running, but FT811 refused to perform the swap and draw a new screen unless the above condition was true.

For the actual ST7789 setup, I used a mux to share the CS between the display and the FT811, and this init code.  I configured the display as 4 line 8 bit serial II (IM[3:0] = 1110) which required another GPIO to toggle the D/CX line, but any serial config should work, with 9-bit 3 wire being the simplest.  Some of these delays are arbitrary and can likely be tightened up:

Set RESX low
50ms delay
set RESX high
50ms delay
set MADCTL to 0x00
set COLMOD to 0x66 (18-bit RGB mode)
send INVON command
set RAMCTRL to 0x11, 0xC2
set RGBCTRL to 0x40, 0x08, 0x14
send command DISPON
100ms delay
send command SLPOUT
100ms delay

For configruing the FT811:
// HORIZONTAL TIMING
#define hfp         38
#define hsw         10
#define hbp         10
#define h_active   240
#define h_total      (hfp + hsw + hbp + h_active+1) //+1 to make it actually swap

// VERTICAL TIMING
#define vfp         8
#define vsw         4
#define vbp         4
#define v_active   320
#define v_total      (vfp + vsw + vbp + v_active+1)  //+1 to make it actually swap
   
//Screen Settings
#define DISPLAY_HCYCLE      h_total            //total pixels/line
#define DISPLAY_HOFFSET      (hfp + hsw + hbp)   //(FP + sync width before active)
#define DISPLAY_HSYNC0      hfp               //(sync pulse starts after FP)
#define DISPLAY_HSYNC1      (hfp + hsw)         //(sync pulse ends)
#define DISPLAY_VCYCLE      v_total            //total lines/frame
#define DISPLAY_VOFFSET      (vfp + vsw + vbp)   //(FP + sync width before active)
#define DISPLAY_VSYNC0      vfp               //(sync pulse starts after FP)
#define DISPLAY_VSYNC1      (vfp+vsw)         //(sync pulse ends)   
#define DISPLAY_PCLK_POL   0               //rising edge output
#define DISPLAY_CSPREAD      1
#define DISPLAY_WIDTH      h_active
#define DISPLAY_HEIGHT      v_active
#define PCLK_DIV         3               //16Mhz when main clock set to 48MHz

Come and register in our Next Webinar on 24 Jun 2026 @ 3pm UK time.

Bridgetek Webinar | Powering Performance: The Hardware Behind EVE

Register Now

Thank you for joining our Bridgetek Webinar: "From Design to Device: Showcasing EVE Capabilities" held on 20 May 2026 at 3:00 PM (UK time).

We appreciate your time and engagement during the session.

For those who could not attend live, or if you'd like to revisit the content, the full webinar recording is now available as per below video.


If you know someone who would benefit from this session, please feel free to share the Webinar recording link to them so they can access the recording and be part of the conversation.

Should you have any questions or require further information, simply reply to this email—we're here to help.

Thank you once again for your participation, and we look forward to connecting with you in the next webinar on 24 Jun 2026 – Register Now.

Update and a follow up now that I have actual hardware to work on:

I have been able to bring up the ST7789 based panel and draw some test screens to it over SPI to verify that the panel itself is configured properly and functions.

I can also verify that I can control the FT811, as I use it to toggle the DISP pin on the panel interface as well as control the backlight.

Unfortunately, I have not yet been able to have the FT811 drive the panel.  A simple output script results in no changes to the display:

Ft_Gpu_Hal_WrCmd32(CMD_DLSTART );
Ft_Gpu_Hal_WrCmd32(COLOR_RGB(35,144,255));
Ft_Gpu_Hal_WrCmd32(CLEAR(1,1,1));
Ft_Gpu_CoCmd_FgColor(COLOR_RGB(255,255,255));
Ft_Gpu_CoCmd_Text(24, 80, 29, OPT_CENTER, "Test");
Ft_Gpu_Hal_WrCmd32(DISPLAY());
Ft_Gpu_Hal_WrCmd32(CMD_SWAP );
Ft_Gpu_Hal_WaitCmdfifo_empty();
I seem to be missing some config option for the ST7789 to get it into RBG mode.  Screens written via the FT811 have no effect.  The previously linked code for ILI9488 doesn't fully apply to ST7789 as they are different ICs.   The ST7789 datasheet is not at all clear on what needs to be configured for RBG mode to work, only offering hints. 

Any suggestions?