Hello:
Sorry for the delay but I've had other projects come up and since yesterday I've picked this one back up.
I'm trying to use CMD_SETBITMAP as the comapñero told me but when I use it it doesn't paint on screen neither the image I call nor the next thing to paint.
EVE_add_cmd(BITMAP_HANDLE(BMP_HANDLE), 4u);
EVE_add_cmd(SET_BITMAP, 4u);
EVE_add_cmd(0, 4u);
EVE_add_cmd(COMPRESSED_RGBA_ASTC_8x8_KHR, 2u);
EVE_add_cmd(40, 2u);
EVE_add_cmd(40, 2u);
EVE_add_cmd(BEGIN(EVE_BITMAPS), 4u);
EVE_add_cmd(VERTEX2F((unsigned long)(x * PIXEL_PRECISION), (unsigned long)(y * PIXEL_PRECISION) ), 4u); // Top left point to print
EVE_add_cmd(END(), 4u);
EVE_add_cmd FUNCTION CODE:
void EVE_add_cmd(uint32_t command, uint8_t num_bytes)
{
if (num_bytes == 4u)
{
eve_tft_tx_buffer[eve_tft_txOffset++] = (uint8_t)(command); // Send command 32 bits
eve_tft_tx_buffer[eve_tft_txOffset++] = ((uint8_t)(command >> 8 ));
eve_tft_tx_buffer[eve_tft_txOffset++] = ((uint8_t)(command >> 16));
eve_tft_tx_buffer[eve_tft_txOffset++] = ((uint8_t)(command >> 24));
}
else if (num_bytes == 2u)
{
eve_tft_tx_buffer[eve_tft_txOffset++] = (uint8_t)(command); // Send command 16 bits
eve_tft_tx_buffer[eve_tft_txOffset++] = ((uint8_t)(command >> 8 ));
}
else if (num_bytes == 1u)
{
eve_tft_tx_buffer[eve_tft_txOffset++] = (uint8_t)(command); // Send command 8 bits
}
eve_tft_cmdOffset = (uint16_t)(eve_tft_cmdOffset + num_bytes); // Calculate new offset
eve_tft_cmdOffset &= 0x0FFF; // ... roll over
}
can you tell me some more help.

- February 09, 2025, 10:04:04 PM
- Welcome, Guest
News:
Welcome to the Bridgetek Community!
Please read our Welcome Note
Technical Support enquires
please contact the team @ Bridgetek Support
Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology
1
on: February 06, 2025, 01:08:00 PM
|
||
Started by maria@dsg-id.com - Last post by maria@dsg-id.com | ||
2
on: January 31, 2025, 01:55:09 PM
|
||
Started by Rudolph - Last post by BRT Community | ||
Hi Rudolph,
We don't have the 10.1" module but we do have the 7" version. Did you see it fail with the original Flash chip provided on the module? Best Regards, BRT Community |
3
General Category / Discussion - EVE / Re: IPS-50 and 5" Display Works, IPS-70 and 7" Display Doesn't Work
on: January 30, 2025, 02:44:22 PM
|
||
Started by kumaichi - Last post by kumaichi | ||
Thank you, Rudolph! I did a quick test setting the REG_PCLK_2X to 1 and didn't resolve the issue. I was thinking that using QSPI would have been able to read from the flash fast enough but apparently, I was mistaken
![]() Thanks again for your help and patience. Kindest regards. |
4
General Category / Discussion - EVE / Re: IPS-50 and 5" Display Works, IPS-70 and 7" Display Doesn't Work
on: January 29, 2025, 05:44:19 PM
|
||
Started by kumaichi - Last post by Rudolph | ||
First of all, make use of all the RAM_G you have before even considering diplaying anything from flash.
You could use CMD_FONTCACHE for the largest font, but it is a little tricky to use and does not take it kindly if you try to display more characters than can fit in the cache. Then there is REG_ADAPTIVE_FRAMERATE which is set to 1 by default. With REG_AH_HCYCLE_MAX, which is set to 0 by default, you can enable adaptive HSYNC, it is to be set to a value between REG_HCYCLE and 4095 - so 4095. :-) This suspends PCLK if the next scanline is not ready yet, so this gives the graphics engine more time at the cost of reducing the framerate. Another option would be to check if the display settings could be modified to lower the pixel clock and/or make the scanlines longer, which again results in a lower framerate. There also is REG_PCLK_2X which if set to 1 tells the graphics engine that it can send two pixels per clock to the output block. I am not sure if it helps in this situation, but given the description it might, if the effect is that the graphics engine is spending less time pushing out pixels then it might free enough clock cycles for the external flash. |
5
General Category / Discussion - EVE / Re: IPS-50 and 5" Display Works, IPS-70 and 7" Display Doesn't Work
on: January 29, 2025, 01:18:20 PM
|
||
Started by kumaichi - Last post by kumaichi | ||
Hi Rudolph,
I switched all the fonts to use ROM font 31 and everything displayed correctly. Is there any way to change settings so that I can use custom fonts or are ROM fonts the only option? Thank you for your response, extremely helpful. Kindest regards. |
6
on: January 28, 2025, 06:49:48 PM
|
||
Started by maria@dsg-id.com - Last post by Rudolph | ||
I attach an image where you can see that I cannot load the image. First of all, please be aware that images carry meta information, including your geo location I always cut fotos to what I want to show and when I save I have all the checkboxes in IrfanView to keep the meta data ticked off. Then I just loaded the image into EVE Screen Editor and it works fine, including alpha, so the image is good. CMD_SETBITMAP(4500, COMPRESSED_RGBA_ASTC_8x8_KHR, 88,72) BEGIN(BITMAPS) VERTEX2F(20, 326) END() And the inspector shows this in the display-list: Offset (decimal) Raw Text 447 0x01001194 BITMAP_SOURCE(4500) 448 0x29000000 BITMAP_SIZE_H(0, 0) 449 0x0800b048 BITMAP_SIZE(NEAREST, BORDER, BORDER, 88, 72) 450 0x2e0093b7 BITMAP_EXT_FORMAT(COMPRESSED_RGBA_ASTC_8x8_KHR) 451 0x28000000 BITMAP_LAYOUT_H(0, 0) 452 0x07f96009 BITMAP_LAYOUT(GLFORMAT, 176, 9) 453 0x1f000001 BEGIN(BITMAPS) 454 0x400a0146 VERTEX2F(20, 326) 455 0x21000000 END() And that should be it, you are not using BITMAP_EXT_FORMAT, only BITMAP_LAYOUT. GLFORMAT should be 31. And COMPRESSED_RGBA_ASTC_8x8_KHR should be 37815. 0x07f96009 - 0x07 / bit 19 to 23 = format -> 11111 = 31 / bits 9 to 18 = linestride -> 00 1011 0000 = 176 (88*2) / bits 0 to 8 = height -> 9 (72 / ![]() 0x2e0093b7 - 0x2e ... reserved .. 16 bits format - yes, 0x93b7 = 37815 Oh yes, I almost overlooked this, the VERTEX2F coordinates are only so low because I am also using VERTEX_FORMAT(0) in this ESE test-project |
7
on: January 28, 2025, 03:32:48 PM
|
||
Started by maria@dsg-id.com - Last post by BRT Community | ||
Hi,
Thanks for the image, we'll try it out here too. It is worth trying Rudolph's advice to use CMD_SETBITMAP - if you set the size and layout via the individual commands and if the layout and size _H values (which have the upper bits) are left with old values then EVE may be using these incorrect values. Also, displaying from RAM_G is good to test, Best Regards, BRT Community |
8
on: January 28, 2025, 01:29:57 PM
|
||
Started by maria@dsg-id.com - Last post by maria@dsg-id.com | ||
Hello:
I attach an image where you can see that I cannot load the image. At the bottom of the screen you can see that the image is in position 0 of the ram_g, width: 88, height: 72 and format: 38 which is equivalent to EVE_COMPRESSED_RGBA_ASTC_8x8_KHR so the image loads fine in ramg and its values are displayed. can you help me please. |
9
General Category / Discussion - EVE / Re: IPS-50 and 5" Display Works, IPS-70 and 7" Display Doesn't Work
on: January 27, 2025, 04:21:32 PM
|
||
Started by kumaichi - Last post by Rudolph | ||
I just checked and I am using the same parameters with my RVT70HSBNWC00-B.
But this looks like a different issue entirely: external flash bandwidth. Please switch to ROM fonts and check what it looks like then. The RVT50H might be just barely working as the time per display line is a couple of µs longer. |
10
on: January 27, 2025, 04:06:56 PM
|
||
Started by maria@dsg-id.com - Last post by Rudolph | ||
I tried, but there is just too much code and this is incomplete.
Please try something much simpler first, not reading from SD(?), writing to QSPI flash(?), reading from there and so on. Quote PS.- the images are ASTC_8x8 and it is a 88x72 image. I pass the .raw file that is generated from the several that it generates. Using the .raw file is correct. So the files should have 1584 bytes. Just add the array to the .c file as a first step. const uint8_t test_icon [1584] = { ..... }; Write it to RAM_G in console_tft_init(): EVE_mem_write(ramg_test_icon_address, test_icon, sizeof(test_icon)); Display it: EVE_add_cmd(COLOR_RGB(255u, 255u, 255u), 4u); EVE_add_cmd(BEGIN(EVE_BITMAPS), 4u); EVE_add_cmd(CMD_SETBITMAP(ramg_test_icon_address, EVE_ASTC_8x8, 88u, 72u), 16u); EVE_add_cmd(VERTEX2F((unsigned long)(100 * 16), (unsigned long)(100 * 16) ), 4u); EVE_add_cmd(END(), 4u); Yes, that "EVE_add_cmd(CMD_SETBITMAP(" is a wild guess, I am not familiar with the library you are using. But it really should include a way to use CMD_SETBITMAP. Which library is this? The "4u" at the end really looks inconveniant. Side-Note, does your VERTEX2F really need uint32_t? The coordinates are 15 bit wide and signed. My lib uses int16_t for VERTEX2F: void EVE_vertex2f(const int16_t xc0, const int16_t yc0); In my library this would look like this: EVE_color_rgb(WHITE); EVE_begin(EVE_BITMAPS); EVE_cmd_setbitmap(MEM_LOGO, EVE_ASTC_8X8, 88U, 72U); EVE_vertex2f(100U*16U, 100U*16U); EVE_end(); CMD_SETBITMAP sets bitmap source, size and layout_h and layout. The only time you do not want to use it is when you need to not set BITMAP_SIZE filter/wrapx/wrapy to NEAREST/BORDER/BORDER. But even then you can send a BITMAP_SIZE with the preferred values after CMD_BITMAP, at the cost of 4 bytes extra in the display-list. At this point I am not sure anymore what "linestride" was, something, something, pixel. :-) I have not been using BITMAP_LAYOUT for years now as FT81x / BT81x support CMD_SETBITMAP. |