The file Esd_Context.c in function Esd_Render(Esd_Context *ec)
has code lines in DEBUG builds:
  #if defined(_DEBUG)
   // This will cause a dark red screen in case background video incorrectly swaps the display
   EVE_Hal_startTransfer(phost, EVE_TRANSFER_WRITE, RAM_DL);
   EVE_Hal_transfer32(phost, CLEAR_COLOR_RGB(0x40, 0x00, 0x20));
   EVE_Hal_transfer32(phost, CLEAR(1, 1, 1));
looks a bit suspect to me. IMHO this should be an opt-in sequence in request, not the default for debug.

Hi,

Thanks for sharing,

Yes, great work, the display fits in perfectly with the product and the front panel. The 480x118 panel is ideal for updating a wide range of 1U rackmount equipment to have color graphics and touch.

Best Regards, BRT Community

Hi,

Here is a small example where we copy two fonts to RAM_G and then display them.

The pointer to the graphic data will have been set in the xfont block when you convert the font or when creating the bin for the flash but you can overwrite this after copying the xfont to RAM_G as shown below.

Hope it helps, BRT Community

void eve_display(void)
{

Flash_Full_Speed();


//unified.blob                  : 0     : 4096
//EDF Block                     : 4096  : 128
//HPSimplified_Rg_14_ASTC.xfont : 4224  : 192
//HPSimplified_Rg_14_ASTC.glyph : 4416  : 8192
//HPSimplified_Rg_20_ASTC.xfont : 12608 : 192
//HPSimplified_Rg_20_ASTC.glyph : 12800 : 24576

// define where we will put in RAM_G
#define Font1_xfont  0
#define Font1_glyph  0+192
#define Font2_xfont  0+192+8192
#define Font2_glyph  0+192+8192+192

// ---------------------------------------------------------------------------

// copy xfont to RAM_G (font 1 is size 14)
EVE_LIB_BeginCoProList();
EVE_CMD_FLASHREAD(Font1_xfont, 4224, 192);
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

// copy glyph to RAM_G
EVE_LIB_BeginCoProList();
EVE_CMD_FLASHREAD(Font1_glyph, 4416, 8192);
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

// copy xfont to RAM_G (font 2 is size 20)
EVE_LIB_BeginCoProList();
EVE_CMD_FLASHREAD(Font2_xfont, 12608, 192);
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

// copy glyph to RAM_G
EVE_LIB_BeginCoProList();
EVE_CMD_FLASHREAD(Font2_glyph, 12800, 24576);
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

// ---------------------------------------------------------------------------

// Update the RAM_G location holding start of graphic data which is 8th 32-bit value in the xfont block
// See BT81x programmers guide 5.4.3
HAL_MemWrite32((Font1_xfont+32), Font1_glyph); // update address xfont + (4*8 bytes)
HAL_MemWrite32((Font2_xfont+32), Font2_glyph);  // update address xfont + (4*8 bytes)

// ---------------------------------------------------------------------------

EVE_LIB_BeginCoProList();
EVE_CMD_DLSTART();
EVE_CLEAR_COLOR_RGB(0, 0, 0);
EVE_CLEAR(1,1,1);
EVE_COLOR_RGB(255,255,255);

EVE_CMD_SETFONT2(2, Font1_xfont, 0);
EVE_CMD_SETFONT2(3, Font2_xfont, 0);

EVE_CMD_TEXT(100, 50, 2, 0, "Custom Font 14");
EVE_CMD_TEXT(100, 100, 3, 0, "Custom Font 20");
EVE_DISPLAY();
EVE_CMD_SWAP();
EVE_LIB_EndCoProList();
EVE_LIB_AwaitCoProEmpty();

// ---------------------------------------------------------------------------

while(1)
{
}

}

Hi,

I am using BT817Q controller and I need 2 custom fonts in my project.
I have successfully used EVE Assets Builder to create fonts, load it into the flash and use fontcache.
But I have performance problems because only one of the fonts is in the cache. I would like to load one font into the fontcache and second one into the RAM_G.
And I can not find any working example. Can someone please help me.

Here is the code I am using:
/*
unified.blob            : 0      : 4096
saarland_120_ASTC.glyph : 4096   : 420480
saarland_120_ASTC.xfont : 424576 : 320
saarland_200_ASTC.glyph : 424896 : 479168
saarland_200_ASTC.xfont : 904064 : 320
*/

if (E_OK == EVE_init_flash())
{
           EVE_cmd_fontcache(12, 0xf0000, 0x80000);
           EVE_cmd_flashread(0, 424576,320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */           
           EVE_cmd_flashread(MEM_FONT, 904064,320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
}

EVE_cmd_setfont2_burst(12,0,32);
EVE_cmd_setfont2_burst(13,MEM_FONT,32);

Thank you...

One of the best integrations of our 1U displays. An EVE2 with our custom symmetrical 480x118 1U TFT, using resistive touch, SPI interface, 3.3V.

"IQTX – coherent optical modulation transmitter

Generate and control phase-modulated optical signals at 11 GHz, 20 GHz, 23 GHz or 40 GHz of bandwidth. Supports M-QAM, M-PSK and custom modulation formats and Baud rates beyond 64 GBaud."

Display:
https://www.matrixorbital.com/eve2-38a

Company:
https://www.quantifiphotonics.com

This forum needs a like button. 

Now I kind of want one.
But holy smokes, 5 gallons? That is like 20l?
That is maybe something to recommend for the company restaurant.

Yes, it is a lot, it is designed for Cafes I believe. They even have a 380L version if you really need a hit!

Alternatively, instead of using the Esd_Loop function, reimplement this behaviour into your RTOS event loop.

Whenever you get an interrupt from EVE, push an event in your RTOS event loop, check if the current loop state is IDLE and the frame swap is done, and if so call Esd_Update and Esd_Render.

Instead of Esd_WaitSwap, you'll need a new function to check the swap (EVE_Cmd_rp(phost) == EVE_Cmd_wp(phost)) and also check EVE_CMD_FAULT(rp),
refer to EVE_Cmd_waitFlush and Esd_WaitSwap to see how the fault state is resolved correctly - it affects some internal state.
After cmd is swapped or reset, check if EVE_Hal_rd8(phost, REG_DLSWAP) == 0 --- this is just to catch any unexpected behaviour.

In this case Idle will only get called deep in the call stack while the command buffer is full (this should resolve quickly), so from there you can just pump any pending events in your RTOS event loop.

I'm ok with that, I have UI elements that does not use cpu ressource. But I've noticed that widget ESD_MultiGradientRounded use 30% of my CPU. Why?

The emulator has a detection to not redraw the screen if it's presented the same display list twice without changes to graphics ram.

The multi gradient works by writing four colors to a circular bitmap buffer with 64 entries, giving you 32 gradients per frame.
This technique causes a change to graphics ram each frame, which causes the emulator to do a full redraw.

A solution would be to cache the last couple of gradients in the library, and re-use when possible. That'll also let you draw more of these fancy gradients when they share the same colors.

@Kaetemi, thanks for your answer,
Yes, the Idle function callback of the application could be used
for some cases, BUT it is called somewhat  'unpredictable' or multiple times.
  (see Esd_Loop()  =>  Esd_Update() : Idle at least once every frame)
Thanks!

For all the Idle calls that are done during the WaitSwap step, LoopState will be set to ESD_LOOPSTATE_IDLE.
Any other Idle calls that may be done deep in the call stack may have update or render loop state set instead.

As far as the multiple calls, it seems okay to just check in the Idle call if the low power state was already enabled to deduplicate.
Maybe a single IdleEnd call after each batch of Idle calls may be useful to restore back to full speed, though...

Do you have any reference device with power management and a reference RTOS to see how this can be integrated in practice?

@Kaetemi, thanks for your answer,
Yes, the Idle function callback of the application could be used
for some cases, BUT it is called somewhat  'unpredictable' or multiple times.
  (see Esd_Loop()  =>  Esd_Update() : Idle at least once every frame)

I STRONGLY propose to add a specific app-callback,
I guess best place would be here in Esd_Loop as last line in the while-loop, like:
ESD_CORE_EXPORT void Esd_Loop(Esd_Context *ec)
{
........Esd_Start(ec);
   while (Esd_IsRunning__ESD() && !ec->RequestStop)
   {
      Esd_Update(ec);
      Esd_Render(ec);
      Esd_WaitSwap(ec);
                ec->FrameDone();  // <<<<< CALLBACK APP (ONLY HERE!)
   }
   Esd_Stop(ec);
}

Thanks!