BRT Community

And another thing, this is from the BT81x programming manual:

/* Enable backlight of display panel */
#if defined(FT81X_ENABLE)
wr16(REG_GPIOX_DIR, 0xffff);
wr16(REG_GPIOX, 0xffff);
#else
wr8(REG_GPIO_DIR,0xff);
wr8(REG_GPIO,0xff);
#endif
wr8(REG_PCLK,2); //Configure the PCLK divisor to 2, i.e. PCLK = System CLK/2

This does not enable the backlight and it would not be a good idea to enable the backlight at this point since generally the signals need to go out before the backlight is activated.

This is supposed to set the DISP output to HIGH, and it also does.
But why is this setting all the bits in the registers?
DISP is set to output by reset-default in both REG_GPIO_DIR and REG_GPIOX_DIR, so neither of these need to be written to.
And setting all the bits in REG_GPIO or REG_GPIOX does not only set the GPIOx pins to high, it also changes the drive-strength for a couple of pins.

Sure, this might work.
Or it causes problems by for example setting INT_N from Open Drain to Push-pull.

Also, FT81X_ENABLE is not explained.
As the programming guide is for BT81x this might suggest that REG_GPIO_DIR and REG_GPIO are used.
Which would be fine since these are also available in BT81x.

Just keep it simple?

/* Enable DISP signal of display panel */
wr8(REG_GPIO,0x80);

Hello,
I believe I posted this before, but your documentation is inconsistent and I believe it is wrong.

DS_FT800 states:
"Wake up from POWERDOWN state requires the host to pull the PD_N pin down and
release, a low to high transition enables the 1.2V regulator. POR generated when 1.2V
is stable and FT800 will switch to STANDBY mode after internal oscillator and PLL are up
(maximum 20ms from PD_N rising edge). The clock enable sequence mentioned in
section 4.2.3 shall be executed to proper enable the system clock."

That is a clear and concise statement that the 20ms delay after raising PD_N is required and why.

In the FT81x datasheet this was changed to:
"When in the POWER DOWN state, if the device enters this state via an SPI command, then only the SPI
ACTIVE command will bring the device back to the ACTIVE state, provided PD_N pin is also high.
However, if PD_N is used instead, then making PD_N high followed by a SPI ACTIVE command will wake
up the device."

and
"From the SLEEP state, the host MPU sends an SPI ACTIVE command to wake the FT81x into the ACTIVE
state. The host needs to wait for at least 20ms before accessing any registers or commands. This is to
guarantee the clock oscillator and PLL are up and stable."

This contradicts the FT800 datasheet.
This is also found now in the BT88x, BT817/8, BT815/6 - and I believe it is wrong.

It also contradicts this statement in the BT8178 datasheet:
"After reset the BT817/8 will be in the SLEEP state. Upon receiving the SPI ACTIVE command (or
CLKEXT followed by SPI ACTIVE command if external clock source is used), the clock oscillator and
PLL will start up. Once the clock is stable, the chip will check and repair its internal RAM, running the
configuration and then entering into normal operations. The boot-up may take up to 300ms to
complete. During boot up process, software should not access BT817/8 register or RAM except reading
REG_ID and REG_CPURESET."

So one paragraph states that the host must not read any register directly after ACTIVE,
the other states reading REG_ID is fine.

The BT817/8 programming guide has this:
host_command(ACTIVE);//send host command "ACTIVE" to wake up
delay(300ms);
while (0x7C != rd8(REG_ID));

This is at least consistent with the description as it has a delay() between ACTIVE and reading REG_ID.

Now checking what Bridgetek is using in their own code I found this:

    // Reset the display
    MCU_Delay_20ms();
    HAL_PowerDown(1);
    MCU_Delay_20ms();
    HAL_PowerDown(0);
    MCU_Delay_20ms();
...
    // Set active
    HAL_HostCmdWrite(0, 0x00);

    // Read REG_ID register (0x302000) until reads 0x7C
    uint8_t val;
    while ((val = HAL_MemRead8(EVE_REG_ID)) != 0x7C)
    {
        MCU_Delay_20ms();
        (void)val;
    }


So what is does is adding a delay after setting PD_N to high and it has no delay whatsoever between ACTIVE and the first reading of REG_ID.

To my experience and in accordance with the FT800 datasheet, this is correct.
The delay after setting PD_N is for the EVE chip to go from POWERDOWN to STANDBY.
And reading REG_ID directly after ACTIVE is not a problem, the EVE chip does not answer though untill the internal startup is done which I just measured for a BT817 to happen 43ms after ACTIVE.


The next thing is, why are you using:
host_command(CLKEXT);
host_command(CLKSEL);
host_command(RST_PULSE);
host_command(ACTIVE);

And not:
host_command(RST_PULSE);
host_command(CLKEXT);
host_command(CLKSEL);

host_command(ACTIVE);

From the BT817/8 datasheet:
RST_PULSE

Send reset pulse to BT817/8 core. The behaviour is the same as POR except those settings done through SPI commands will not be affected

So what this meant to say is "host commands"?
Ok, if that is the case, the order should not matter as long as RST_PULSE comes before ACTIVE.

Yes, using zlib compressed files is not about RAM-G usage.
But it would reduce the transfers from the SD card and the SPI traffic to the EVE chip.

I do have Teensy 4.0 and 4.1, but I never really found a use for them apart from implementing the library code. Total overkill.

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?

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. 

Hi, I am still having this issue and it just made me publish my first youtube video ever.


Fortunately, while I had to rotate the display for my last project to landscape (EVE_cmd_setrotate(2) ), this was fine while EVE_cmd_setrotate(3; shows the same distortion.
Since the panel is IPS the viewing angle is the same from all sides anyways.

Hello, will this be made available later? Like on your Youtube channel?

I am just getting "Error: Invalid value for '-c' / '--command'" when adding -cw 1 0 0 0

Excellent, a viable workaround and a fix incoming then. 
I just went with the ASTC 4x4 for now, I should be pretty much done with the UI and still have not filled half of RAM-G.
Interesting that ASTC has no direct support for grey textures.
I tried to use the -cw" option from astcenc.exe, but eab_tools does not accept it.

I am working on a project and needed a font, mostly for extra characters, but I also modified Roboto to have a dot in the zero.
Anyways, I noticed artifacts in the font. I am always using "exhaustive" and in "auto" the output log shows the format is ASTC_8x8.
As I did not recall having seen this before, I went back thru the EAB versions I have.
4.1.0 - exact same binary
4.0.1 - result is different, quality is better
2.13 - best quality with the same settings

Taking fotos from the display is not the best option and so I also used ESE to verify this - only to find that the result in ESE is different than on the display.

As a last step I set the mode to 4x4 which improved the quality even more. With this I do not see a difference between EAB 2.13 and 4.2.0 - the .glyph files are not the same though.
I have plenty of RAM-G left in this project, using a 136kiB .glyph file instead of a 43kiB .glyph file does not affect me for this project - but that is practially no compression.

I tried ASTC 6x6 with EAB 4.2.0 and the result is still good while the .glyph file went down to 57kiB. There are artifacts though if you look for them.

Looks like there is an issue with the EAB 4.x font converter, getting this level of artifacts on 8x8 is not what I am used to.
And I am also using a 792x792 image in the project that I converted to ASTX 8x8 with EAB 4.2.0. And there are almost no artifacts on it.

The command lines are:

eab_tools pre82x font -f extended -i ../Roboto-Subset_mod.ttf -o .../Font -s 26 -E ASTC -b 8x8 -e exhaustive -d 0 -R -u .../Fonts/!CharMap_UTF8_min.txt -S

eab_tools font -f extended -i .../Roboto-Subset_mod.ttf -o .../Font -s 26 -E ASTC -b 8x8 -e exhaustive -d 0 -x ".../EVE Asset Builder2/tools/astcenc.exe" -R -p -u .../Fonts/!CharMap_UTF8_min.txt -w

Ok, there is a small difference, EAB 4.2.0 uses the option "-S" and the end and EAB 2.13 has "-w", this appear to be options for eab_tools, "-w" does not seem to exist for eab_tools from 2.13 though.

In my experience, using the external flash for display list contents is an issue. And it gets worse with higher resolutions.
The reason is simple, the bandwidth for the external flash is limited and the higher the resolution, the less time the BT817 has to fetch data.
And it gets worse with lots of random access reads when using fonts.

So, rule of thumb, avoid displaying from flash as much as you can, use it as a last resort. This does not render the external flash useless, you can still copy assets to RAM-G when you need them.

Quote from: maciej_ch on March 24, 2026, 07:32:10 AMImportantly, the issue also occurs with minimal code using only CMD_TESTCARD(), which is sometimes stable and sometimes shows artifacts.

That might be two things, incorrect initialization or an electrical issue with unstable supply.

Which library are you using?
I am working on a project right now which uses a 10" with 1280x800 and BT817, I just changed my project to use CMD_TESTCARD on startup for five seconds. And while there was a slight flicker initially, this was from the supply still stabilizing. When I just reset without power down it does not happen and after I changed the code to initially wait 2s, it stopped, so electrical issue.

Quote from: maciej_ch on March 24, 2026, 07:32:10 AMWhat is the practical maximum size/resolution of images that can be displayed smoothly on BT817 (especially when using ASTC 4×4 or assets from flash)?

Apart from that I recommend using ASTC 8x8 as I only observed artefacts beyond that, it is less the resolution as the amount of images and therefore the random accesses necessary per scan line.
Years ago I ran into issues when trying to display 64x64 color icons, the limit was like 12 from external flash - but this is 8kiB per image, there is not really a reason to load these from flash.

Right now I am using a 720x720 ASTC 8x8 in my project and since it is "only" 126kiB it just sits in RAM_G. For the last iteration of the project I was using three ASTC 8x8 with 624x624 each and rotated two of these, 95kiB each, RAM-G, no problem.

Last year I did a project in which I had to emulate a TV for a demonstrator, my task was to display pictures from one particular american football team on a 5" with 800x480, in the end I used two RAM_G buffers to copy the images to from the external flash, 96000 bytes per image. But I tried, the double-buffer was not even necessary, I only kept it as there is no use saving RAM-G. The copy with CMD_FLASHREAD was so fast that I did not notice any issues from switching the images while there were displayed.

Quote from: maciej_ch on March 24, 2026, 07:32:10 AMIn flash FULL mode, is the SPI clock fixed by EVE, or can it be increased to improve throughput?

No, there is no API to change the flash clock, the only way would be to overclock the BT817 and that would also ruin the display settings, apart from other side effects that might occur.

Hmm, what clock speed is your BT817 configured to?

Quote from: maciej_ch on March 24, 2026, 07:32:10 AMFor very large fonts (~400–500 pt), EVE Asset Builder seems to hit limits (glyph width issues) — what are recommended approaches to handle large fonts while keeping full character support?

500? Wow.
Yes, I am also getting a warning: "WARNING: Characters with widths exceeding 255 pixels have been filtered out."
The limit for the reduced character Roboto I used was 290px.
The full font lost a couple of glyphs, out of 901 "only" 856 got converted to the size.
But the Roboto-Regular_280_ASTC.glyph for that is 28.3MiB...
What do you mean by "keeping full character support"?
Tried 400px, the glyphs converted went down to 587 - 35.4MiB.

At this size a tile approach should make more sense, I am not sure though if there are actually tools for that.

The BT820 could probably handle that as a font.
It still has the same limitation, if that can be called a limitation.

The output from the font converter in EAB 4.2.0 is not the same though:
Characters submitted by the user: 901
Accepted characters for conversion: 587
   Success: 587
   Fail   : 0

The relocatable asset Roboto-Regular_400_ASTC.reloc needs to be loaded by
cmd_loadasset. It will take 37536544 bytes of RAM_G after decompression.

Font conversion is now complete!

That is an issue, EAB in BT82x mode just silently refuses to convert glyphs without telling why.

So, anything? 

Well, see you at Embedded World in Nürnberg. 
I have my train ticket, I plan to attend on wednesday, might check out your booth around 1pm.

This issue just came back to me: https://github.com/RudolphRiedel/FT800-FT813/discussions/163

I reduced my display list to this:

EVE_cmd_dlstart();
EVE_clear_color_rgb(WHITE);
EVE_clear(1, 1, 1);
EVE_tag(0);
EVE_color_rgb(BLACK);
EVE_cmd_number(100, EVE_VSIZE - 65, 26, EVE_OPT_RIGHTX, cmd_fifo_size);
EVE_cmd_number(100, EVE_VSIZE - 50, 26, EVE_OPT_RIGHTX, display_list_size);
EVE_cmd_number(104, EVE_VSIZE - 35, 26, EVE_OPT_RIGHTX|6U, num_profile_a);
EVE_cmd_number(104, EVE_VSIZE - 20, 26, EVE_OPT_RIGHTX|6U, num_profile_b)
EVE_display();
EVE_display();
EVE_cmd_swap();

And with EVE_cmd_setrotate(0); the text is fine, with EVE_cmd_setrotate(1); it is barely readable.
With EVE_cmd_setrotate(2); it is fine.

The display settings I am using:
#define EVE_HSIZE (1280L)
#define EVE_VSIZE (800L)
#define EVE_VSYNC0 (0L)
#define EVE_VSYNC1 (10L)
#define EVE_VOFFSET (23L)
#define EVE_VCYCLE (838L)
#define EVE_HSYNC0 (0L)
#define EVE_HSYNC1 (20L)
#define EVE_HOFFSET (88L)
#define EVE_HCYCLE (1440L)
#define EVE_PCLK_FREQ (0x08C1U) /* value to be put into REG_PCLK_FREQ -> 72MHz, REG_PCLK is set to 1 */
#define EVE_SET_REG_PCLK_2X
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD (0L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 4
#define EVE_BACKLIGHT_FREQ (4000U)


Is there anything I can do to fix this?

To add a minor detail, FT8xx and BT81x "only" support 32 bitmap handles, so 0 to 31.
15 is used as a scratch bitmap by a couple of commands.

BT82x has 64 bitmap handles and 16 to 34 are assigned to the fonts.
Unfortunately it still uses the same fonts, but at least there are all directly useable.

Just saw that EAB 4.1.0 is finally: out https://brtchip.com/eab/