Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[LaZorraBRT]

I was previously using a EVE3 5" display and had a large custom font displaying without issue.  When I tried the same code on a EVE4 7" display, I am experiencing a corrupt display.  When I change the code to only display one large digit, it will display correctly.  Also, when I am displaying two digits and they happen to be the same digit, it will display correctly but if they differ it does not work. 

I tried to enable adaptive framerate using the following line under TFT_init but this did not have any effect:

Code: [Select]

EVE_memWrite8(REG_ADAPTIVE_FRAMERATE, 0x1);

I have included my code in a zip file and will include sample images in a following post when this post is approved.  I highly appreciate any help I can get on this issue, thank you!

Todd

This is the part of the code that is causing the display corruption on the 7inch:

Code: [Select]


EVE_cmd_dl_burst(DL_COLOR_RGB | WHITE);
EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_setbitmap_burst(0x800000 + 5254, EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 224, 384);
if (speedinttens > 0){
EVE_cmd_dl_burst(CELL(speedinttens));
EVE_cmd_dl_burst(VERTEX2F(50, 100));
}
EVE_cmd_dl_burst(CELL(speedintones));
EVE_cmd_dl_burst(VERTEX2F(290, 100));
EVE_cmd_dl_burst(CELL(speedinttenths));
EVE_cmd_dl_burst(VERTEX2F(530, 100));
EVE_cmd_dl_burst(DL_END);


[LaZorraBRT]

Here are included images of how it looks while it is working on an EVE3 5inch display and also on the EVE4 7inch display with only one large digit. 

[Rudolph]

I was to suggest to use CMD_FONTCACHE for the digits.
But you are using a single very large image instead.
Try to split these up into individual images first instead of using CELL.

And furthermore you can take load off the flash by using CMD_FONTCACHE.
This commands uses RAM_G to buffer a couple of characters from a larger font in the flash.

EVE_init_flash();
EVE_cmd_flashread(MEM_FONT50, 167936, 192);
EVE_cmd_setfont2(12,MEM_FONT50-0x010000,0x010000);
EVE_cmd_fontcache(12, 0x00002000, 0x00009100);

This is setting up a cache of 64k just before your .xfont in RAM_G.
No idea if this is enough for the "SPEED" font but from the looks of it this should be plenty.

There also is CMD_FONTCACHEQUERY to help with the cache utilisation.
At least the last time I played with this the number of different characters displayed was a hard limit and exceeding it by only a single character ended in a crash.

[LaZorraBRT]

I split the large numbers up into individual images but I am still having graphical glitches (where the top portion of the screen gets duplicated either 2x or x number of times).

For example, this code displays just fine:

Code: [Select]

//Zero
EVE_cmd_setbitmap_burst(0x800000 + 5254, EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 224, 192); 
EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl_burst(VERTEX2F(150,300));
EVE_cmd_dl_burst(DL_END);

//One
EVE_cmd_setbitmap_burst(0x800000 + 5590, EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 80, 192); 
EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl_burst(VERTEX2F(480,300));
EVE_cmd_dl_burst(DL_END);


But if I change the x coordinate on the Zero from 150 to 220, such as this, I get the glitch:

Code: [Select]

//Zero
EVE_cmd_setbitmap_burst(0x800000 + 5254, EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 224, 192); 
EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl_burst(VERTEX2F(220,300));  //x changed from 150 to 220
EVE_cmd_dl_burst(DL_END);

//One
EVE_cmd_setbitmap_burst(0x800000 + 5590, EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 80, 192); 
EVE_cmd_dl_burst(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl_burst(VERTEX2F(480,300));
EVE_cmd_dl_burst(DL_END);

I can play with the coordinates and overlap the numbers on different areas of the screen and it displays fine, so I don't think its an issue with them being overlapped.  Even though in the 2nd bit of code, they shouldn't overlap.  I don't know why moving it to the right 70 pixels should cause the display to go wonky. 

I'll share my complete code and I would love it if someone could try this on their display and at least tell me if this works on another Eve 4. 

I'm really stumped and I'm almost thinking I have a bunk display.   I can upload the same code on my Eve 3 display and it works like a charm.  Not having much luck with Eve 4. 

I tried the fontcache code you shared Rudolph but that resulted in a blank display for me. Thank you, you put a lot of work into your replies and I highly appreciate it. 

Thank you for any help!

[LaZorraBRT]

Here is the working x=150 and not working x=220.

[Rudolph]

I started experimenting a little with this although I know I have other outstanding tasks... 

This is most likely a bandwidth issue with the external flash, hence the idea to use the fontcache.
I can not get the fontcache to actually do something though, I set it up and cmd_fontcachequery reports 99 chars available / 0 in use, while the font is on screen and there should be at least 6 in use.

Have you considered to copy the images from the external flash to RAM_G before using them?

[LaZorraBRT]

I thought that this section of the code, uploaded the data from tft_data into RAM_G:

Code: [Select]

/* this is only needed once to transfer the flash-image to the external flash */
//start of need only once portion
/*
uint32_t datasize;

EVE_cmd_inflate(0, font50, sizeof(font50)); // de-compress flash-image to RAM_G
datasize = EVE_cmd_getptr();  // we unpacked to RAM_G address 0x0000, so the first address after the unpacked data also is the size
EVE_cmd_flashupdate(0,0,4096); // write blob first
EVE_init_flash();
EVE_cmd_flashupdate(0,0,(datasize|4095)+1); // size must be a multiple of 4096, so set the lower 12 bits and add 1
*/
//end of need only once portion

EVE_init_flash();
EVE_cmd_flashread(MEM_FONT50, 167936, 192);
EVE_cmd_setfont2(12,0,32);

initStaticBackground();

I have both the font and the images for the large number within "font50" in tft_data.  Please let me know if I misunderstanding this portion of the code.

Does anyone know if there other examples out there that I can try that have multiple working large images or multiple fonts that are displayed in burst?  I'd love to try any other example that someone has working on a Eve4 display so that I can verify that my display is working correctly.  Thank you for any help!

[Rudolph]

In my demo this looks a bit different:

#if (TEST_UTF8 != 0) && (EVE_GEN > 2)   /* we need a BT81x for this */
   #if 0
      /* this is only needed once to transfer the flash-image to the external flash */
      uint32_t datasize;

      EVE_cmd_inflate(0, flash, sizeof(flash)); /* de-compress flash-image to RAM_G */
      datasize = EVE_cmd_getptr(); /* we unpacked to RAM_G address 0x0000, so the first address after the unpacked data also is the size */
      EVE_cmd_flashupdate(0,0,4096); /* write blob first */
      EVE_init_flash();
      EVE_cmd_flashupdate(0,0,(datasize|4095)+1); /* size must be a multiple of 4096, so set the lower 12 bits and add 1 */
   #endif

      EVE_init_flash();
      EVE_cmd_flashread(MEM_FONT, 84928, 320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
#endif // TEST_UTF8

So the upper part with the "#if 0" can be activated by changing the "0" to for example "1" and then it writes the flash image from the microcontrollers memory to the flash-chip on the EVE module.
This in there for conveniance and to show how to write to the flash, a larger image should be written directly to the module with an USB/SPI adapter.

The EVE_init_flash() line is there to activate full QSPI speed.
And the flashread line copies only the .xfont file from the flash to RAM_G.

So to copy the images the RAM_G as well you need at least one flashread command more.

>EVE_cmd_setfont2(12,0,32);

This line should look like this:
>EVE_cmd_setfont2(12,MEM_FONT50,32);

[LaZorraBRT]

I implemented your suggestion Rudolph:
 

This line should look like this:
>EVE_cmd_setfont2(12,MEM_FONT50,32);

but it didn't make a difference, the display is still corrupted (split in two).

I'm trying to convert the digits into individual images as a solution but am having difficulty with figuring out how to get the memory-map defines right. 

Code: [Select]

/* memory-map defines */
#define MEM_FONT 0x000f6000
#define MEM_BATTRED 0x000f8000
#define MEM_BATTGREEN 0x000fa000
#define MEM_BATTORANGE 0x000FC000 // 000FC000 = 1032192 which is 8192 more than previous value
#define MEM_NUMONE 0x000FE000
#define MEM_NUMZERO 0x00106000

The three battery indicators are showing up well and also the number one as you can see in the attached photo.  But I cannot figure out how to get the number zero to display (the big purple block in the image).  Is there a limit to how many images one can assign memory-maps?  I figure that these are small images and that I am not running out of memory (I hope).  My code is included in a zip file.  Thank you for any help!

[Rudolph]

I just had some fun with this using my RVT70H display with 1024x600.
Due to the forum attachment restrictions I only attached the image and a subset of the source-code.

I already had converted the number characters from the font Inconsolata into huge images.
In the process I also changed the aspect-ratio making them taller for the target width of 200 pixels.

I shortened tft.c to have less clutter.
Like with the basic demo there is a flash-image in tft_data.c and it is written to the flash if commented out segment in TFT_init() is activated.
This flash image is larger:
unified.blob                                               : 0      : 4096
Funtype_32_ASTC.glyph                                      : 4096   : 145664
Funtype_32_ASTC.xfont                                      : 149760 : 320
battery_white_176x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw     : 150080 : 16896
Numbers_200x384_0_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 166976 : 19200
Numbers_200x384_1_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 186176 : 19200
Numbers_200x384_2_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 205376 : 19200
Numbers_200x384_3_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 224576 : 19200
Numbers_200x384_4_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 243776 : 19200
Numbers_200x384_5_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 262976 : 19200
Numbers_200x384_6_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 282176 : 19200
Numbers_200x384_7_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 301376 : 19200
Numbers_200x384_8_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 320576 : 19200
Numbers_200x384_9_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 339776 : 19200

If the flash-image is installed the .xfont file for the font is copied to RAM_G.
Then the images for the numbers are copied to RAM_G as one large block.
And the battery symbol  is copied to RAM_G.

The address for a digit is calculated from a variable:
For example like this: MEM_NUMBERS+(((count % 10000)/1000) * 0x4b00)
So it is Base-Address + (digit * image-size).
Yes, this is not meant to be an optimal solution, just a working one. :-)

Now the battery is just the empty frame.
The eight bars are drawn with rectangles to show a simple solution.

Finally the font is cached now.
This is an UTF-8 font stretching over only the extended ASCII range with 187 glyphs in total.
And I also attached the charmap I convert my fonts with now.

[LaZorraBRT]

It works for me and looks fantastic, this gives me a lot of hope!

I had to change tft.c to tft.cpp for it to compile, otherwise I got warnings about SPI.  Also I changed your tft.h to:

Code: [Select]

#ifndef TFT_H_
#define TFT_H_

extern uint16_t num_profile_a, num_profile_b;

void TFT_init(void);
void TFT_touch(void);
void TFT_display(void);

#endif /* TFT_H_ */

For some reason, with your tft.h, I was getting "undefined reference" errors on the functions. 

I'm off with the wife to Wisconsin for my mother-in-laws birthday party but I'll see if I can figure out the memory-map defines when I get back.  Looking forward to trying to replicate this with my own fonts and images and hope to have the same amount of success.

Thanks a million Rudolph! 

[LaZorraBRT]

I was able to recreate your code, keeping the same size images for the large numbers and I found a similar empty battery image.  I included my code and tft_data in a zip file below.  The battery now charges and discharges.

Code: [Select]

/* memory-map defines */
#define MEM_FONT 0x000fea00 /* the .xfont file for the UTF-8 font is copied here */
#define MEM_LOGO 0x000fec00 /* start-address of logo, needs 784 bytes of memory */
#define MEM_NUMBERS 0x00000000 /* start-address for 10 number images, ASTC 8x8, 200x384, 19200 / 0x4b00 bytes each */
#define MEM_BATTERY 0x0002ee00 /* start-address for a battery symbol, ASTC 8x8, 176x384, 16896 / 0x4200 bytes */
#define MEM_DL_STATIC (EVE_RAM_G_SIZE - 4096) /* 0xff000 - start-address of the static part of the display-list, upper 4k of gfx-mem */

I understand the memory map for the MEM_NUMBERS, just start it at zero, so first thing in memory.  NUMBERS has a size of 19200 x 10 so 192000.  Therefore MEM_BATTERY gets assigned 0x0002ee00 (192000) which places it directly after NUMBERS in memory.  I hope I am thinking about this correctly.

What I don't understand is where the number for MEM_FONT (1042944) or MEM_LOGO (1043456) come from.  By my logic MEM_FONT could start at 192000 + 16896 or 208896 or at the very least an address shortly after 208896.  Do fonts get a different assignment in memory?  The 512 bytes of space between FONT and LOGO are for the xfont (320 bytes) I am assuming.  Is the glyph data always included before xfont and that's why there is a big jump between the address of MEM_BATTERY and FONT? Then the xfont file knows how to access each glyph?

I'm over the moon that I can make some progress on my project here, thank you so much!

(Please excuse my digit #1, I put it in the middle of the image canvas when resizing things, doesn't line up with the segmented display look)

[Rudolph]

Nice. :-)
But well, if you like the digits to use a seven-segment font you could also use two images
and display these as segments for your digits. :-)
Nah, just kidding, that might be an option if you actually run out of RAM_G.

The memory map in my code is nothing but a very simple example of how this could be done.
That the .xfont, the logo and MEM_DL_STATIC section are at the end of RAM_G is just how my simple example is structured, the parts that are not changing are located at the end which leaves RAM_G free from the beginning for additional code.
That the battery image ends up after the number images while it is placed first in the flash was deliberate.
Not because it needs to be this way or because it makes more sense, just to show it makes no difference.

>The 512 bytes of space between FONT and LOGO are for the xfont (320 bytes) I am assuming

Yes, MEM_FONT is for the .xfont file, that 512 bytes get reserved is just lazy, these need to confirm to some alignment so I put the segments on the start of pages, it does not need to be this way but there is plenty of memory left anyways.

>Is the glyph data always included before xfont

In the flash, yes, if this is done like this with first the .glyph and then the .xfont for the font the EVE Asset Builder automatically changes the data in the .xfont file to match the .glyph file so you can add a couple of fonts without the need to convert each font to the specific address it later ends up in the flash.

>before xfont and that's why there is a big jump between the address of MEM_BATTERY and FONT?

The glyph data is not copied to RAM_G, it remains in the flash.
And no, as explained above there is no particular reason for the jump from the end of MEM_BATTERY to the start of MEM_FONT.

>Then the xfont file knows how to access each glyph?

Yes, it has all the offsets to the glyphs so EVE can calculate the adresses for the characters from it.

>I had to change tft.c to tft.cpp for it to compile, otherwise I got warnings about SPI.  Also I changed your tft.h to:

Then you are using a slightly older version of my library, I changed it two weeks ago adding EVE_cpp_wrapper.cpp / EVE_cpp_wrapper.h and also splitting EVE_target into EVE_target.c and EVE_target.cpp.

I did this to remove the need to rename all the .c files to .cpp when compiling for the Arduino framwork with its C++ SPI class.

Currently I am doing more structural changes so it might not be the best time to update now. :-)
I removed the define to select the display from EVE_config.h yesterday for example. The idea with this is to remove the need to edit the file by setting the define in the build-enviroment.
When I changed the Readme.md I realized though that this needs to be done for the pin defines in EVE_target.h as well.
At least when the goal is that PlatformIO adds the library files from the repository and they are not supposed to be changed anymore.
The new PlatformIO/Arduino example already builds this way for all targets - but you can not change the pins, yet.

[LaZorraBRT]

Or even an example with two or three custom fonts would help me immensely and most likely answer my question.  I've tried multiple configurations to get a second font to work and I am scratching my head.  Thank you!

[Rudolph]

Adding more fonts is really just more of the same.
Well, except for the font-cache as there is only one font-cache.

So, first step, I checked what fonts I already had and in which sizes and decided to convert a Notosans to size 40.

Then I put everything in a new flash image:
unified.blob                                               : 0      : 4096
Funtype_32_ASTC.glyph                                      : 4096   : 145664
Funtype_32_ASTC.xfont                                      : 149760 : 320
battery_white_176x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw     : 150080 : 16896
Numbers_200x384_0_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 166976 : 19200
Numbers_200x384_1_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 186176 : 19200
Numbers_200x384_2_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 205376 : 19200
Numbers_200x384_3_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 224576 : 19200
Numbers_200x384_4_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 243776 : 19200
Numbers_200x384_5_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 262976 : 19200
Numbers_200x384_6_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 282176 : 19200
Numbers_200x384_7_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 301376 : 19200
Numbers_200x384_8_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 320576 : 19200
Numbers_200x384_9_200x384_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 339776 : 19200
NotoSans-Regular_40_ASTC.glyph                             : 358976 : 145664
NotoSans-Regular_40_ASTC.xfont                             : 504640 : 320
Inconsolata-Regular_24_ASTC.glyph                          : 504960 : 32384
Inconsolata-Regular_24_ASTC.xfont                          : 537344 : 320

Next I compressed the resulting .bin with the "Asset Compressor" and converted the .zlib with the "BIN2C" tool in EAB.
I changed tft_data.c and tft_data.h, activated the code to update the flash in TFT_init(), flashed my controller, waited a few seconds untill it started, deactivated the flash-update code again and flashed my controller again.

Well, yes, I could have used a USB/SPI adapter to flash .bin from EAB directly but I did not want to take it apart.

Anyways, it still worked like before which was the goal for the first step.

Next I reworked the memory map and added a couple of new defines for the fonts:
/* memory-map defines */
#define MEM_NUMBERS 0x00000000 /* start-address for 10 number images, ASTC 8x8, 200x384, 19200 / 0x4b00 bytes each */
#define MEM_BATTERY 0x0002ee00 /* start-address for a battery symbol, ASTC 8x8, 176x384, 16896 / 0x4200 bytes */

#define MEM_FONTCACHE 0x000ee000 /* needs to be 64 byte aligned and >16k */
#define MEM_FONT_INCON24 0x000fe840
#define MEM_FONT_FUN32 0x000fe980 /* the .xfont file for the UTF-8 font is copied here */
#define MEM_FONT_NOTO40 0x000feac0
#define MEM_LOGO 0x000fec00 /* start-address of logo, needs 784 bytes of memory */
#define MEM_DL_STATIC (EVE_RAM_G_SIZE - 4096) /* 0xff000 - start-address of the static part of the display-list, upper 4k of gfx-mem */

#define SIZE_FONTCACHE (MEM_FONT_INCON24 - MEM_FONTCACHE)

/* bitmap-handles */
#define FONT_INCON24 20
#define FONT_FUN32 21
#define FONT_NOTO040 22

I added the code to copy the extra .xfont files and switched the font-cache to the largets font:
EVE_cmd_flashread(MEM_FONT_INCON24, 537344, 320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
EVE_cmd_flashread(MEM_FONT_FUN32, 149760, 320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
EVE_cmd_flashread(MEM_FONT_NOTO40, 504640, 320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */

EVE_cmd_setfont2(FONT_NOTO040,MEM_FONT_NOTO40,32); /* assign bitmap handle to a custom font */
EVE_cmd_fontcache(FONT_NOTO040, MEM_FONTCACHE, SIZE_FONTCACHE);
EVE_cmd_dl(BITMAP_HANDLE(0));

In initStaticBackground() the fonts are assigned to their handles:
EVE_cmd_setfont2(FONT_INCON24,MEM_FONT_INCON24,32); /* assign bitmap handle to a custom font */
EVE_cmd_setfont2(FONT_FUN32,MEM_FONT_FUN32,32);
EVE_cmd_setfont2(FONT_NOTO040,MEM_FONT_NOTO40,32);
EVE_cmd_dl(BITMAP_HANDLE(0));

And the lines for the text output in the special fonts got changed as well:
EVE_cmd_text_burst(150, 490, FONT_INCON24, 0, "The quick brown fox jumps over the lazy dog!");
EVE_cmd_text_var_burst(180, 530, FONT_NOTO040, EVE_OPT_FORMAT, "Fontcache total: %d  used: %d", 2, fonttotal, fontused);

And when I use FONT_FUN32 for the long text line EVE does not like that very much as the funtype 32 font no longer is cached.
So there are still limits, you can only cache one font and any uncached font needs to be either small enough to allow EVE to fetch all the glyphs in one line from the flash or you need to limit the amount of different glyphs in one line.


Why are alll the .xfont files the same size although these are completely different fonts?
I used the same charmap file for all three which limits the glyphs to a selected subset.
And my choice right now is this subset:
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûü"
As these are from the first two pages the .xfont file ends up with room for 256 glyphs even though only 187 are in the charmap file.