Hi Craggan,

We have been doing some testing and we were able to see the issue on some compiler platforms, where it seemed to be caused by the encoding.

For example, we can see the issue on Visual Studio but the same string and the same code on various MCUs is fine, and so it seems to be data type related. If the wrong data at byte level is passed into the EVE Text command by the IDE (which may not be apparent from the top-level code that you run) then you could see issues like this. This may explain why Rudolph also did not see the issue,

A second factor is to ensure that you convert all of the characters needed. If converting in higher quality and larger sizes of font, make sure that your converted data all fits into RAM_G depending on data size and address where you load it etc. With this you may see the wrong character in the string (as opposed to the 'tab' effect which seems caused by the compiler handling of unicode as above)

Best Regards, BRT Community

Hello,

Unfortunately the developers cannot provide the source code at this moment in time for the conversion utilities.

However I have requested an update on the progress of the Unix build for the command line tools

Best Regards,
BRT Community

Hi,
Thanks for your update, we are doing some testing and are discussing with our R&D team to understand this issue, and will update very soon,

Thanks Rudolph, we have also passed those to our R&D team, they seem like some good suggestions:

In regards of EAB 2.10.2 I found a couple of things a bit odd.
- why is "Reserve Space" not set as default?
- why is "L8" selected by default for "Extended Format"?
- why is the ASTC set to 4x4 by default instead of a more reasonable 8x8?
- why is this SampleApp generated every single time? can we please have a switch for that which defaults to off?

Best Regards, BRT Community

Hi Rudolph,
We checked with a 7" 1024x600 and also with a 10.1" 1280x800 screen.
Here is an example on the 10.1" screen

Best Regards, BRT Community

 

Hi,

Could you please advise what settings you used to convert the font in EVE Asset Builder and also which version of the EAB you use?

Best Regards, BRT Community

Hello,

Thank you for your question.

We utilise the following LED backlight drivers on our development modules, maybe these would be suitable for your application:
IS31BL3506A
IS31BL3506B

Best Regards,
BRT Community

Hi,
Yes, unlike the compressed png/jpg formats, the compressed file for an inflate could have different types of content and so there will not be standard image data in all cases. As Rudolph mentioned, since you will create the file in most cases, you can include our own header containing the details before compressing, and then when using it in EVE, you can parse that after inflating it (and then exclude that header data when you display the resulting raw image in EVE).

Best Regards, BRT Community

Hello,

Thank you for the clarifications, I think in the case that both the older version of the same display and the fact that rerunning the calibration routine results in the display working as expected means we can rule out an issue with the I2C data coming from the touch controller. And similarly it would rule out a hardware issue such as the CTP connector being misaligned.

I would be interested to know if the saved matrix values that you are noting are captured before you write them into the EERPOM or afterwards? This, as you have noted, may be related to an overflow issue or potentially an endianness issue.

Best Regards,
BRT Community