Matrix Orbital Corp

Good afternoon everyone,
I am seeking help in connecting an Eve 3 Display - https://www.matrixorbital.com/ftdi-eve/ ... e3-50a-ips
This is a non-touch model with 128 mb of flash.

I am trying to connect it to an ESP32 board as per the included photo. I have compiled the https://github.com/MatrixOrbital/ESP-EVE3-Weather-Demo but I am not getting anything from the display.

In Serial, I am receiving Cmd_READ_REG_ID - fail, which I know means that the display is not outputting the 0x7C to initialize communication.

My question is it possible to connect to the display using a direct connection to an ESP32 board or do I need to use the SPI2BBC?
I have checked my wiring multiple times and have tried other ESP32 boards as well.
I appreciate any help and suggestions, I can supply more information, photos, etc. Just trying to get this running in a basic manner. Thank you!

Todd Update:
I have tried this with Rudolph's code (the backlight comes on but nothing displayed) and get the following in Serial:
[17:08:18:941] Backtrace:0x40082183:0x3FFB0D40 0x40082E31:0x3FFB0D60 0x4000BFED:0x3FFB66F0 0x400857B1:0x3FFB6700 0x400D5810:0x3FFB6720 0x400D581B:0x3FFB6750 0x400D58B9:0x3FFB6770 0x40085ED6:0x3FFB6790 0x40085559:0x3FFB67B0 ␍␊
[17:08:18:953] ␍␊
[17:08:23:898] <0x1b>[0;31mE (70452) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:<0x1b>[0m␍␊
[17:08:23:898] <0x1b>[0;31mE (70452) task_wdt: - IDLE0 (CPU 0)<0x1b>[0m␍␊
[17:08:23:898] <0x1b>[0;31mE (70452) task_wdt: Tasks currently running:<0x1b>[0m␍␊
[17:08:23:898] <0x1b>[0;31mE (70452) task_wdt: CPU 0: main<0x1b>[0m␍␊
[17:08:23:936] <0x1b>[0;31mE (70452) task_wdt: CPU 1: IDLE1<0x1b>[0m␍␊
[17:08:23:936] <0x1b>[0;31mE (70452) task_wdt: Print CPU 0 (current core) backtrace<0x1b>[0m␍␊

Thank you to any help!

Using Rudolph's code I got it to work!

I had to change the #define TEST_UTF8 from a 1 to a 0 under tft.c and the display came to life!

I would still like to be able to use the original Matrix Orbital example to connect to the display so I would like to see if anyone has a suggestion as to how I can overcome the 0x7C issue. Thank you in advance.

lazorramatrix wrote: Sat Feb 20, 2021 5:16 pm I had to change the #define TEST_UTF8 from a 1 to a 0 under tft.c and the display came to life!

Thank you, I just made that the default for most of the examples.

Oh, and my library checks for 0x7c as well, if that check times out for any reason it retuns with "0" from EVE_init().

Thank you so much for the quick and helpful reply!

I've made another attempt to get the Weather Demo working but still have init issues.

I have two more questions. For your example Rudolph, the task watchdog is triggered every 5 seconds, is this normal behavior? All seems to be displaying well so I assume so.

Also, what is the best way to display a very large font? A font that would take up 70% of the vertical space of the display for example. Is this possible with custom fonts? I've tried to increase the font size but can only get up to a value of 30 for the standard font.

I highly appreciate any help I can receive, thank you and have a great day wherever you might be!

T

lazorramatrix wrote: Thu Feb 25, 2021 9:53 pm I have two more questions. For your example Rudolph, the task watchdog is triggered every 5 seconds, is this normal behavior? All seems to be displaying well so I assume so.

I have not noticed that but then I am not actively using the ESP32 for anything.
Is this with the native or with the Arduino example?

The Arduino example should behave by itself.
And for the native example I put this at the end of the while() loop in main.c:

rtc_wdt_feed();
vPortYield();

I hoped that would feed the watchdog and I have no observed the display to reset.

Also, what is the best way to display a very large font? A font that would take up 70% of the vertical space of the display for example. Is this possible with custom fonts?

If you really need a complete font, you can put an UTF-8 font in the flash.
I used a 140 point UTF-8 for a projekt on a 5" EVE3 display.
The compression however is extremely poor for fonts, mosty likely because ASTC always is 32 bit and then every glyph
is compressed separately.
My flash-image was 6.2 MiB with the .glyph file alone using 6 MiB.
When compressed into a .zip the .glyph shrinks down to 115 KiB.
It might be better to use a couple of images for only a small set of chars.
Annother idea would be to compose each digit with set of tiles.
Form digits from a set of 40*40 pixel tiles, 4 by 8 tiles for example.
I have no idea though if there is software out there that would break up a font at a given
size into the minimum amount of tiles necessary.
Or simulate a segment-display by drawing lines. :-)
Or like recently suggest over on the BRT forum, use smaller images and scale them up.
There is no "best" way, it depends on what you are willing to accept as result and what resources you are willing to use for it. :-)

I've tried to increase the font size but can only get up to a value of 30 for the standard font.

This should have worked up to 31.
There are three more fonts available but for some bizarry reason even the BT81x are limited to
only 32 bitmap handles so the maximum number directly useable is 31 as the fonts 16 to 31 are mapped
to the bitmap handles 16 to 31 by default.

But there is CMD_ROMFONT to re-assign one of the built-in fonts to a bitmap handle of your choice.
Okay, almost, #15 is used for CMD_GRADIENT, CMD_BUTTON and CMD_KEYS.

EVE_cmd_romfont(16,32);
EVE_cmd_romfont(17,33);
EVE_cmd_romfont(18,34);

EVE_cmd_text(500, 100, 31, 0, "Ding!");
EVE_cmd_text(500, 175, 16, 0, "Ding!");
EVE_cmd_text(500, 250, 17, 0, "Ding!");
EVE_cmd_text(500, 325, 18, 0, "Ding!");

I highly appreciate any help I can receive, thank you and have a great day wherever you might be!

Thank you, have a great day yourself! :-)
I largely identify as web citizen but my router is connected to a landline in Germany. :-)

Thank you again, immensely helpful! I am trying to do things one small step at a time so I can learn what each change equates to on the display.

I started by adding:
//EVE_cmd_romfont(16,32); //First three lines commented out
//EVE_cmd_romfont(17,33); //First three lines commented out
//EVE_cmd_romfont(18,34); //First three lines commented out

EVE_cmd_text(500, 100, 31, 0, "Ding!");
EVE_cmd_text(500, 175, 16, 0, "Ding!");
EVE_cmd_text(500, 250, 17, 0, "Ding!");
EVE_cmd_text(500, 325, 18, 0, "Ding!");

And this resulted in: And I saw that the third number in the command equates to a change in the type of font.

So then I tried:
EVE_cmd_romfont(16,32);
EVE_cmd_romfont(17,33);
EVE_cmd_romfont(18,34);

EVE_cmd_text(500, 100, 31, 0, "Ding!");
EVE_cmd_text(500, 175, 16, 0, "Ding!");
EVE_cmd_text(500, 250, 17, 0, "Ding!");
EVE_cmd_text(500, 325, 18, 0, "Ding!");

And this resulted in: So it looks like fonts 32,33, and 34 are larger versions of font 31. Neat!

Then I tried to get the custom font working so I added:
EVE_cmd_setfont2(12,MEM_FONT,32); /* assign bitmap handle to a custom font */
EVE_cmd_text(200, 100, 12, EVE_OPT_CENTERX, "Arcade Font 12");

And of course that did not display anything until I added the font to the memory of the display by adding:
/* 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

EVE_init_flash();
EVE_cmd_flashread(MEM_FONT, 84608, 4288);

Running that once and the commenting out the flash-image transfer code for successive runs. (I can see why you set the default to not use a custom font, makes sense now.)

That ended up with: (I commented out the romfont portion again)

So then I tried this bit of code to see what happens:
EVE_cmd_setfont2(12,MEM_FONT,32); /* assign bitmap handle to a custom font */
EVE_cmd_text(200, 100, 12, EVE_OPT_CENTERX, "Arcade Font 12");
EVE_cmd_text(200, 200, 24, EVE_OPT_CENTERX, "Arcade Font 24?");

I was hoping that the third item is possibly a scalar and would increase font size but instead I got: I am guessing that there is no way to scale a font, I would just have to upload the larger font and take the memory hit. Is it possible for you to share the tft_data.c file that contains the 140 point UTF-8 font you had used for your project? I'd like to see what that looks like on the display and use it as a reference point for making my own large font.

Or simulate a segment-display by drawing lines. :-)

I thought about this way to do it too, but was hoping for something a little slicker :-)

Your help is very appreciated! Hello from Chicago, pizza and beer is on me if you are ever in town!
T

(I wanted to make a long post in case this info is helpful for others)

I am guessing that there is no way to scale a font, I would just have to upload the larger font and take the memory hit.

That is correct, the fonts use pre-calculated images.
In fact, the display list is only using images, that whole concept of fonts is translated by the command co-processor.
When you place a CMD_TEXT in EVE Screen Editor and change to the "Inspector" tab down at the bottom, you see the
generated display list commands.

CMD_TEXT(119, 250, 28, 0, "Text")

SAVE_CONTEXT()
VERTEX_FORMAT(2)
BITMAP_HANDLE(28)
BEGIN(BITMAPS)
VERTEX2II(119, 250, 28, 'T')
VERTEX2II(133, 250, 28, 'e')
VERTEX2II(144, 250, 28, 'x')
VERTEX2II(155, 250, 28, 't')
RESTORE_CONTEXT()

CMD_TEXT(605, 388, 28, 0, "Text")

SAVE_CONTEXT()
VERTEX_FORMAT(2)
BITMAP_HANDLE(28)
BEGIN(BITMAPS)
CELL(84)
VERTEX2F(2420, 1552)
CELL(101)
VERTEX2F(2476, 1552)
CELL(120)
VERTEX2F(2520, 1552)
CELL(116)
VERTEX2F(2564, 1552)
RESTORE_CONTEXT()

So a font is nothing else than one big image of back-to-back smaller images.

Is it possible for you to share the tft_data.c file that contains the 140 point UTF-8 font you had used for your project?

I would share it but it does not exist.
Putting the data into the controllers memory is only a very cheap and direct way to share this for self-contained example code.
But this method has limits, as the data gets unpacked into RAM-G it can not be longer than 1MiB.
I just converted Funtype.ttf to 140 points using EVE Asset Builder 2.1.0 ( https://brtchip.com/wp-content/uploads/ ... .0-rc2.zip ) using a custom charmap.txt to reduce the included 364 glyphs to 106.

More details on converting fonts are here: viewtopic.php?f=45&t=6894
This is a bit outdated though since EVE Asset Builder contains a BIN2C tool now which is really conveniant.

The reported width in pixels is 180 and the height is 208, so that is not even half the height.
The size of the .glyph file alone is 2.824.128 bytes, the resulting flash image has a size of 2.829.312 byts.
So in order to transfer this the same way as the with the smaller fonts, the flash image would need to split into three parts at least.

What you really would like to have at some point is one of these: https://www.matrixorbital.com/eve2-usb2spi-kit-a
With this you can program the flash image into the display directly using EVE Asset Builder.
Be aware though that there is an issue with all EVE Asset Builder versions so far, they configure and switch on the display
which results in quite an amount of mA beeing drawn from the attached SPI adapter.
So for a larger display you need to use the barrel connector as the current exceeds the USB limit but even then
the LDO on the board heats up pretty quickly which might get to the point where it switches off.

And I just found a new "bug" when playing with EVE Asset Builder, at least new to me.
I used a numbers.txt file containing only " +-.0123456789" to convert about the smallest usefull subset of glyphs with only 14.
Then I tried to convert that into the biggest font possible.
Unfortunately, "Font Size" in EVE Asset Builder maxes out at 255 - which I consider to be a bug or at least a lacking feature.
And the result in pixels for Funtype.ttf and these 14 chars is a width of 180 and a height of 192.
At least the resulting Funtype255_Numbers.bin is "only" 869KiB and 18KiB when zlib compressed.

Hello from Chicago, pizza and beer is on me if you are ever in town!

I am not sure if I can agree to call that pies you do in Chicago a pizza, but I definately would not refuse to try one. :-)

After I wrote that last post to you, I downloaded the EVE Asset Builder and tried to create a font myself. I was able to use the font generator to create a glyph and xfont with a limited character set (0123456789), turn that into a bin, and then convert that into hex with the BIN2C converter. However, the final result is what I have attached, this flash.c file. Opening it up, it appears to be the blob, filler space, the glyph, more filler space, then the xfont possibly. This doesn't match up with the nice font-only data that is in tft_data.c. Were you able to produce clean and nice font-only data using the Asset Builder? A nice thing I discovered about the BIN2C converter is that it will accept the glyph or xfont files and output them as hex data but that still didn't look right. I worked with it for an hour or so but the closest I got is the file I included.

Last night, I downloaded the Hex Workshop you mentioned in the other thread, but it was already too late and I did not try it.

Since the font size is limited to 255 and that still isn't big enough, I am thinking I could create each number as an image file and then just display "12.7" for example as three images and a circle for the period.

So a font is nothing else than one big image of back-to-back smaller images.

Seems like the end result would be the same regardless and at least this way I could upload each image through the controllers memory possibly.

The usb2spi-kit is already in the shopping cart, I fully see it's usefulness now. I'll add that with an order for an EVE4 7" screen now that I've seen how nice and responsive these displays are. I'm glad I hadn't jumped ahead and ordered that with my original order as I might not have learned all this without trying it with just a microcontroller.

Thank you again!

I am not sure if I can agree to call that pies you do in Chicago a pizza

Ha! Deep dish pizza is only for the tourists! This town has some world-class pizza that isn't just a 2-inch slab of cheese, I assure you.

lazorramatrix wrote: Sat Feb 27, 2021 8:54 am After I wrote that last post to you, I downloaded the EVE Asset Builder and tried to create a font myself. I was able to use the font generator to create a glyph and xfont with a limited character set (0123456789), turn that into a bin, and then convert that into hex with the BIN2C converter. However, the final result is what I have attached, this flash.c file. flash.c Opening it up, it appears to be the blob, filler space, the glyph, more filler space, then the xfont possibly. This doesn't match up with the nice font-only data that is in tft_data.c.

The binary in ftf_data.c is not font-only data, it is a flash.bin that has been compressed with the "Asset Compressor" to be used with CMD_INFLATE.
It is in fact the blob (for BT815 this is 312 bytes which seem to be the flash driver code and lots of 0xff bytes), the .glyph and the .xfont.

But there is a comment for that in tft_data.c:
Source File: funtype-webfont_24_ASTC.zlib
unified.blob : 0 : 4096
funtype-webfont_24_ASTC.glyph : 4096 : 212800
funtype-webfont_24_ASTC.xfont : 216896 : 4864
z-lib compressed, unpacked size is 221952

And since I was intensively playing with EAB 2.1.0, converting fonts, I wrote the next bug report over at the BRT forum.
A part of what should be visible on monday is this:

Also the Funtype_12_ASTC.glyph with 106 chars is 48384 bytes long.
But the Funtype_12_ASTC.glyph which should have 364 glyphs since the font does not contain more,
it has a size of 307.072 bytes.
That is almost twice the size that I would expect when going from 106 chars to 364 chars.

And talking about sizes, again, there appears to be a severe issue when converting fonts.
16x20x106 is 33920
So an uncompressed array of 16x20 pixel images in L8 format of 106 individual images would be smaller than
what the font converter currently presents as COMPRESSED_RGBA_ASTC_8x5_KHR.

8x5 is 3.2 bits per pixel and when I compress a single image of 16x20 from this font,
the result is 320 bytes in L8, and only 128 bytes as COMPRESSED_RGBA_ASTC_8x5_KHR -> works.

So the data for the glyhs should be around 13568 bytes but the resulting .glyph file
is over 3.5 times that size.

There also is the option to generate the font in L8 format.
The resulting Funtype_12_L8.glyph for 106 glyphs of 16x20 pixels has a size of 106560 bytes.
Why? That is 3.1 times the expected size.

I thought this might be an issue with alignment of images in FLASH but then the requirement is 32 bytes aligned.
128 bytes for COMPRESSED_RGBA_ASTC_8x5_KHR already is perfectly aligned.
Even adding 32 bytes to every glyph does not account for the size.
And when using RAM_G as a target for the ASTC compressed font the .glyph file has the exact same size.
So no, alignement can not be the issue.
Also L8 does not even allow the data to be in FLASH.

I really do wonder why the generated font files are so excessively large.

Last night, I downloaded the Hex Workshop you mentioned in the other thread, but it was already too late and I did not try it.

The BIN2C in EAB really does the same, only much more conveniant since you do not have to switch the tool.
I only get triggered a little when I see hex values without leading zero. :-)

Since the font size is limited to 255 and that still isn't big enough, I am thinking I could create each number as an image file and then just display "12.7" for example as three images and a circle for the period.

So a font is nothing else than one big image of back-to-back smaller images.

Seems like the end result would be the same regardless and at least this way I could upload each image through the controllers memory possibly.

It is more conveniant as a font, well, maybe not so much when the output is limited to numbers.
When using CMD_NUMBER the command-co-processor handles the width of the different chars for example.

I am not sure if I can agree to call that pies you do in Chicago a pizza

Ha! Deep dish pizza is only for the tourists! This town has some world-class pizza that isn't just a 2-inch slab of cheese, I assure you.

Rofl, this really is not what I expected. :-)

With your help, I was able to create a 255 size font (just numbers, no other characters) with the Eve Asset Builder and get it uploaded to the display. The map file has these values:
unified.blob : 0 : 4096
LemonMilkMedium-mLZYV_255_ASTC.glyph : 4096 : 1032192
LemonMilkMedium-mLZYV_255_ASTC.xfont : 1036288 : 192

The array is a size of 15748.

I agree that it would be much more convenient as a font to get big numbers displayed and I am curious if they are going to expand the EAB to accept larger values than 255. It would help me out for my project for sure. My estimate is that a size 500 font or so would be about right for the 5" pixel display height. Since the 7" I want to order has a 600 pixel display height, I'd need to go even bigger.

Thank you for bringing up the bug report on the BRT forum.

I highly appreciate all the assistance!

I'm following this post with interest as I want to use a very large font size on the forthcoming 7" EVE4 controller (hopefully soon!). My font on requires digits 0 to 9 (sequential gear position indicator). In the past on my 5" EVE2 display I create all icons in L1 pixel data, could the same be done here to reduce font size by a factor of 8? I found the L1 pixel quality more than sufficient with such small pixels.

I just did a round of converting funtype.ttf to different formats with Font Size = 255.
And no matter what format right now, using these glyphs organized as font takes a lot of space.

So, this is only "0123456789" now and the individual images are 180x192.

Funtype_255_ASTC.glyph 864KiB
Funtype_255_L1.glyph 552KiB
Funtype_255_L2.glyph 1080KiB
Funtype_255_L4.glyph 2160KiB
Funtype_255_L8.glyph 4320KiB

So yes, in terms of memory Funtype_255_L1.glyph is the smallest.
And this already shows that memory is an issue, this is not even half of 480 and shy of a third of 600.

This also generates images though: This image has exactly what should be in the font, it is one composed image of ten images with 180x192 resolution.
Now lets convert this image.

Funtype_255_180x1920_L1.raw 44KiB
Funtype_255_180x1920_L2.raw 85KiB
Funtype_255_180x1920_L4.raw 169KiB
Funtype_255_180x1920_L8.raw 338KiB
Funtype_255_184x1920_COMPRESSED_RGBA_ASTC_8x8_KHR.raw 87KiB
Funtype_255_180x1920_COMPRESSED_RGBA_ASTC_10x5_KHR.raw 108KiB

That makes a lot more sense, I really wonder why the .glyph files are ten times the size of the actual images.

And how to use that?
Like this:
CLEAR(1, 1, 1)
CMD_SETBITMAP(0, L1, 180, 192)
BEGIN(BITMAPS)
CELL(0)
VERTEX2F(0, 0)
CELL(1)
VERTEX2F(2880, 0)
CELL(5)
VERTEX2F(5760, 0)
CMD_SETBITMAP(44160, COMPRESSED_RGBA_ASTC_8x8_KHR, 184, 192)
CELL(0)
VERTEX2F(0, 3200)
CELL(1)
VERTEX2F(2880, 3200)
CELL(5)
VERTEX2F(5760, 3200)
END()

I put this together in EVE Screen Editor.

And this is what this looks like: So I would definately go with the ASTC version.

Okay, funtype.ttf might not be the best option, as it turns out the "0" is wider than any other number.
And all the other numbers are left adjusted and not centered.

A font with evenly wide numbers or at least that has the smaller numbers centered would make composing this is
to an overall number easier.

Something like:

if(number_hundreds > 0)
CELL(number_hundreds)
VERTEX2F(0, 3200)
if(number_tens > 0)
CELL(number_tens)
VERTEX2F(2880, 3200)
CELL(ones)
VERTEX2F(5760, 3200)

So lets try that with NotoSans-Regular:
That is nicer in terms of evenly spaced width. The converted image is 140x1920.
NotoSans-Regular_255_ASTC_144x1920_COMPRESSED_RGBA_ASTC_8x8_KHR.raw 68Kib
So the converted image is a little wider to make it evenly divisible by 8.

I attempted to replicate your example and hey, at least I got a zero and half of a number 1 working, ha! I created a font of size 510 which equated to each cell being 224x384. The size of the array is 19655. This font has the number 1 set far to the left in the cell but hopefully I can fix that later.

I don't fully understand how to calculate the memory-map defines and I believe that might be part of the issue. I can modify the value for MEM_BIGFONT value and I get less of the number 1 displayed but I don't know how to increase it or modify it correctly. Hoping you can point me in the right direction. I'm reading the manual but this is all new territory for me! Thank you!