BRT Community

Thanks for responding!

Yes.  We need the whole page slid over. For partial screen e.g. list of items it's easy to manage the animation.

I'll look into VERTTEX_TRANSLATE.  It'd be nice to be able wrap the entire page in it.

From what I have gathered scrolling on EVE is achieved by simply redrawing the list at a new position.  This works really well when scrolling images and lighter lists.

In our case, we're trying to implement a menu swipe and the screen (list) contains a lot of active elements. Just the SPI transfer of the list takes a bit of time; but this is fine if you're rendering the screen once as it loads.

When it comes to scrolling, however, I think we're limited by the SPI bandwidth and BT817's FIFO and ability to process the list.

Is there a way to tell the chip to "shift" an already loaded list? or a smoother way of accomplishing this?

tia

Quote

Code Select Expand


I am guessing this would be this in the AN25 EVE LIB:

EVE_LIB_BeginCoProList();
EVE_CMD_TESTCARD();
EVE_LIB_EndCoProList();
delay()


This works, thank you!

trying to test the new set up and I can't seem to get the test card to stay on (other display lists show just fine).  This is based on EVE LIB for ESP32.

EVE_LIB_BeginCoProList();
  EVE_CMD_DLSTART();
  EVE_CLEAR_COLOR_RGB(0, 0, 0);
  EVE_CLEAR(1,1,1);
  EVE_CMD_TESTCARD();
  EVE_DISPLAY();
  EVE_CMD_SWAP();
  EVE_LIB_EndCoProList();
  EVE_LIB_AwaitCoProEmpty();

When I run the above code, it flash the test card and goes back to a blank screen.  Not running any other code that would cause the screen to clear.


EVE_LIB_BeginCoProList();
  EVE_CMD_DLSTART();
  EVE_CLEAR_COLOR_RGB(0, 0, 0);
  EVE_CLEAR(1,1,1);
  EVE_COLOR_HEX(0xFFFFFF);
  EVE_CMD_TEXT(100,100, 31, 0, "Hello, World!");
  EVE_DISPLAY();
  EVE_CMD_SWAP();
  EVE_LIB_EndCoProList();
  EVE_LIB_AwaitCoProEmpty();

Above code stays on the screen.

What is the correct way of using CMD_TESTCARD().

I have two boards.  One with ESP32 populated with 12Mhz Xtal and BT817Q from 2208 and the other with a 32-bit ARM populated with 12Mhz Xtal and BT817Q dated 2221.

Both boards run identical settings and displays, but the newer silicon shows the display "squished" at 72MHz.  The older one doesn't seem to have a problem.

HAL_HostCmdWrite(0x61, 0x46);


If I change the newer one's clk setting down to 60Mhz, the display looks normal. 

HAL_HostCmdWrite(0x61, 0x45);


On the oscilloscope they both show 12Mhz from the crystal and the display is the same between them.

I've seem some notes on the forum about pclk settings but I'm not sure if there is an update documentation that will point me in the right direction.

QuoteCan you please provide more information on how this issue is triggered?

I believe this happens if/when  EVE_LIB_EndCoProList() does not match a EVE_LIB_BeginCoProList().  In other words you have something like:


EVE_LIB_BeginCoProList()
...
EVE_LIB_EndCoProList()
...
EVE_LIB_EndCoProList()

The Error itself does not seem to be related much to the current list being executed in the FIFO.  As the "screen" will render fine if EVE_LIB_EndCoProList() is not encountered out of turn. 

Font Handle Error when no BMP Font is used and 256 byte Format Buffer Overflow when the OPT_FORMAT string and the arguments are only a few bytes long.

It feels like the CoPro jumps to a random location and starts executing random code and eventually sees something it doesn't like. 

I've noticed that in some situations (perhaps if there are EVE_LIB_EndCoProList() commands without a EVE_LIB_BeginCoProList()), EVE can hang and produce an error.

For example:

read pointer: 0xfff
ERROR: illegal font or bitmap handle in cmd_toggle()

The documentation says we should:

Quote
When the host MCU encounters the fault condition, it can recover as follows:
1. Read REG_COPRO_PATCH_PTR into a local variable “patch_address”.
2. Set REG_CPURESET to 1, to hold the coprocessor engine in the reset condition
3. Set REG_CMD_READ , REG_CMD_WRITE , REG_CMD_DL to zero
4. Set REG_CPURESET to 0, to restart the coprocessor engine
5. Write the variable “patch_address” of step 1 to REG_COPRO_PATCH_PTR.
6. To enable coprocessor access flash content, send commands “CMD_FLASHATTACH” following
“CMD_FLASHFAST”. It will make sure flash enters full speed mode.
7. Restore REG_PCLK to the original value if the error string is ‘display list must be empty’
because REG_PCLK is set to zero when that specific error takes place.

So in the EVE LIB, it seems to be the following:


uint32_t Patch_Add = HAL_MemRead32(EVE_REG_COPRO_PATCH_PTR + EVE_RAM_REG);
HAL_MemWrite8(EVE_REG_CPURESET + EVE_RAM_REG, 1);
HAL_MemWrite8(EVE_REG_CMD_READ + EVE_RAM_REG, 0);
HAL_MemWrite8(EVE_REG_CMD_WRITE + EVE_RAM_REG, 0);
HAL_MemWrite8(EVE_REG_CMD_DL + EVE_RAM_REG, 0);
HAL_MemWrite8(EVE_REG_CPURESET + EVE_RAM_REG, 0);
HAL_MemWrite32(EVE_REG_COPRO_PATCH_PTR + EVE_RAM_REG, Patch_Add);



However, the above code does not seem to reset BT817 or the error and it remains stuck untill a hardware reset.

What's the correct way of doing this?

Thank you for your help!
Looks like there were two issues.

1) The examples and programming guide makes heavy use of direct to DL commands.  So I was setting the handle in the DL but the bitmap info in the CO CMD queue.
2) DISPLAY() at the of the DL was required otherwise the bitmaps would get chopped or shrunk depending on the garbage passed the end of the list in DL RAM.

I'm able to display display multiple image/bitmaps as long as each image is set up with HANDLE, SOURCE, etc immediately prior to display.

If I try to set up multiple bitmaps parameters in advance, and then add a bitmap using VERTEX2F, I get a corrupted screen/display.

Below is an example of what does NOT work:

Note, the image data is already loaded into RAM and imageTable array contains valid bitmap attributes.



char handles[] = { 8,9 };
uint32_t addresses[] = { ramBitmapAddress1,ramBitmapAddress2};


       int count = 1; // if count == sizeof(handles) the display gets corrupted

for (int i = 0; i < sizeof(handles); i++) { 
App_WrCoCmd_Buffer(phost, BITMAP_HANDLE(handles[i]));
App_WrCoCmd_Buffer(phost, BITMAP_SOURCE(addresses[i]);
App_WrCoCmd_Buffer(phost, BITMAP_LAYOUT(L1, imageTable[i]->Stride, imageTable[i]->Height));
App_WrCoCmd_Buffer(phost, BITMAP_SIZE(NEAREST, BORDER, BORDER, imageTable[i]->Width, imageTable[i]->Height));
}

//Place the image
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS)); // start drawing bitmaps
App_WrCoCmd_Buffer(phost, COLOR_RGB(0,255,0));
App_WrCoCmd_Buffer(phost, VERTEX2F(685 * 16, 380 * 16, 8, 0));
App_WrCoCmd_Buffer(phost, END());




What is the correct way of doing this?  It seems inefficient to have to set up the bitmap attributes every time it's being used.

Converting just the numeral characters (0-9) of a .ttf in rather large font sizes (within limits since if the pixel width goes over 255 you get: File "fnt_cvt.py", line 929, in run UnboundLocalError: local variable 'xf' referenced before assignment).

Choosing the legacy format results in the .raw file of about 40KB for the 10 chars.

However, if I chose extended format, L1 option for the same 10 chars is 460KB and with ASTC (auto) is 640KB.

Am I doing something wrong?

[apologies if this is a misstep. New here]

It looks like the references to the internal clock source option that was available in BT816 has been removed in the datasheet for BT817/8 with seemingly the only option being an external crystal.

The rest of the document however, makes it sounds like other options are still available:

"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)".

Possible you could clarify if the internal relaxation osc still available or to what extent?

many thanks!

-a