BRT Community

There are a couple of options that I have not explored myself as my hardware usually does not have an SD card socket.

- CMD_LOADIMAGE with a MEDIA-FIO and scaling - but this probably does not look good.
- CMD_INFLATE2 with a MEDIA-FIFO for zlib compressed ASTC.
- CMD_INFLATE with some modifications.
void EVE_cmd_inflate(const uint32_t ptr, const uint8_t * const p_data, const uint32_t len)
void block_transfer(const uint8_t * const p_data, const uint32_t len)

block_transfer already cuts larger transfers into chunks of 3840 bytes as the transfer goes through the FIFO

- Write directly to RAM-G.
void EVE_memWrite_sram_buffer(uint32_t const ft_address, const uint8_t *p_data, uint32_t const len)

You would only need a wrapper around this to count up from the base address for whatever block you are transferring.
This might be the easiest to implement, but this would be for unpacked data, so 1024x600 in ASTC 8x8 would require to write 150kiB.

Edit: personal point of curiosity - which MCU are you using?

I've decided to go down the ASTC route, a simple application will run EAB in command line mode to generate the necessary raw data file. This will be placed on SD card. The boot screen (full colour ASTC 8x8) can be loaded into RAM_G at startup along with approx 20 small icons (60x60) in L1 format.

The final part for me, is how to get the data from the file on the sdcard to RAMG_G in small 2048 byte chunks, using Rudolph's library. I'm using Rudolph's library extensively at the moment.

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