BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rudolph

Pages: [1] 2 3 ... 27
1
Discussion - EVE / Screen rotation issue with BT817 on 1280x800
« on: May 01, 2024, 12:00:41 PM »
I am using a RVT101HVBNWC00-B from Riverdi which is a BT817 with a 1280x800 panel.
And to rotate the screen does not work properly, just flipping it with either REG_ROTATE set to 1 or using CMD_SETROTATE(1) causes major distortion.

When I use CMD_SETROTATE(5) it curiously works fine though, I have no use for a mirrored image though.

0 - image is fine, just for reference
1 - image is distorted
2 - image is fine
3 - image is distorted
4 - image is distorted
5 - image is fine
6 - image is fine
7 - image is distorted

And right now it does not have to display much at all, it looks like this with more empty pixels:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/CFAF800480E0_050SC_Arduino_Uno.jpg

Pixelclock is 72MHz with REG_PCLK_2X set to 1.

Hmm, I dropped the pixel clock to 51MHz with REG_PCLK_2X set to 0 and now the flipped image is fine.
But this dropped the frames/s as well and the pixel-clock is now well below the minimum of 66.3MHz that is listed in the datasheet.

I set REG_PCLK_2X to 1 while still using 51Mhz -> image is distorted when flipped.
I set REG_PCLK_2X to 0 while using 72MHz -> image is fine.
I set REG_PCLK_2X to 0 while using 66MHz -> image is fine.

Any more advice on this why REG_PCLK_2X = 1 with REG_ROTATE = 1 leads to a distorted image?

At 72MHz pixel-clock with 72Mhz system clock the datasheet says that REG_PCLK_2X needs to be set to 1.
And 66MHz is out of spec for the panel, although barely, it is not possible though to set PLL2 to anything between 66MHz and 72MHz.

I reduced the pixel clock to 38MHz and it still works, here at my desk.
But there is no way to tell what will happen out in the field with -20°C....+60°C.

2
Discussion - EVE / Re: Eve3 built-in fontset
« on: April 27, 2024, 09:57:44 PM »
I need to use Roboto and compared what I converted to builtin font 31, looked really similar.
Now I remembered this post and it turns out that fonts 26 to 34 *are* Roboto. :-)
I need more than "Basic Latin" though, at very least some from "Latin-1 Supplement" as well.

Ok, I have a couple more questions now.
I am using a BT817 and the datasheet says that the four largest fonts are encoded in ASTC 8x8 format.
And using both ROM fonts and custom fonts would mean that I could reduce the usage of custom fonts.

What are the font sizes the internal fonts are converted to?
To match font number 31 I had to convert to a font size of 43, at least when viewed in ESE side by side.

But when I zoom in it does not look exactly the same although I used ASTC 8x8 and I have to move my converted font one pixel down.
The anti-aliasing is not the same.
See, the attachments, I used the Roboto-Regular.ttf from the archive you attached and converted it with EAB 2.11.0.
This Roboto-Regular.ttf is version 1.000 from 2011.

Generated Folder: Roboto-Regular_43_Extend
Format:           ASTC 8x8
Compressed:       exhaustive
Layout Width:     96
Layout Height:    6
Pixel Width:      48
Pixel Height:     48
Number of characters provided by the user: 119
Number of characters in xfont file: 256
Number of characters eligible for conversion: 119
   Success: 119
   Fail:    0

The Roboto-Regular_43_ASTC.glyph has a size of 103104 bytes.

When I convert Roboto-Regular.ttf version 2.137 from 2017 though I get a much different result:

Generated Folder: Roboto-Regular_43_Extend
Format:           ASTC 8x8
Compressed:       exhaustive
Layout Width:     128
Layout Height:    7
Pixel Width:      64
Pixel Height:     56
Number of characters provided by the user: 119
Number of characters in xfont file: 256
Number of characters eligible for conversion: 119
   Success: 119
   Fail:    0

The Roboto-Regular_43_ASTC.glyph has a size of 160384 bytes.

But a font size of 42 comes out like this:
Generated Folder: Roboto-Regular_42_Extend
Format:           ASTC 8x8
Compressed:       exhaustive
Layout Width:     96
Layout Height:    6
Pixel Width:      48
Pixel Height:     48
Number of characters provided by the user: 119
Number of characters in xfont file: 256
Number of characters eligible for conversion: 119
   Success: 119
   Fail:    0

The Roboto-Regular_43_ASTC.glyph has a size of 103104 bytes.

So the V2 font changed something which requires to use a font size of one less.

I also converted the font to L4 and L8 which results in the same "wrong" anti-aliasing.
But now I need to move the converted font two pixels down to match the ROM font.

The shift and the change in anti-aliasing is odd, is that due to EAB using different parameters now compared to when the fonts for the BT817 got converted?
The ROM fonts do look more sharp, again, at least in ESE.

3
Test and Review Area / Re: EVE Asset Builder 2.10.2
« on: April 18, 2024, 08:12:36 PM »
Well now, EAB 2.11.0 is out and it clears the Input Character file when you change fonts.
L8 is still selected when going for extended format, "Reserve Space" is still not selected by default and ASTC 4x4 is still the default.

And it still generates the 7.4MB "SampleApp" everytime.
At least there is a way to stop this, rename C:\Users\Public\Documents\EVE Asset Builder\tools\SampleApp

4
Discussion - EVE / Re: UNIOCDE fonts bigger than 18
« on: March 28, 2024, 04:26:19 PM »
Hmm?
Check my footer, it is *all* public.  :)

5
Discussion - EVE / Re: UNIOCDE fonts bigger than 18
« on: March 25, 2024, 03:12:13 PM »
I did compress Ubuntu-Light.ttf with 4x4, although this makes the binary pretty huge without benefit.
I also saw this huge "layout width" but it just worked for me.

Very strange.

6
Discussion - EVE / Re: List of QSPI FLASH Chips for BT81x
« on: March 22, 2024, 01:37:03 PM »
I added the MT25QL01GBBB, thank you, but I wonder if it actually works properly since I saw in the datasheet that it uses two 512MBit dies in the package.

But now I wonder what Flash exactly is Riverdi using on their EVE4 modules.
My RVT70HSBNWC00-B is populated with a chip from Micron, the markings are "MT" "IGA17", "RW213" and "FBNP".
My RVT50HSBNWC00-B is populated with a chip from Micron, the markings are "MT" "IIA17", "RW213" and "JBRQ".
My RVT101HSBNWC00-B is populated with a chip from Micron, the markings are "MT" "0DA17", "RW256" and "J2F1".
All do have BGA cases.

A quick search for Micron 512MBit flash chips did not tell me what devices exactly these are.

7
Discussion - EVE / Re: UNIOCDE fonts bigger than 18
« on: March 21, 2024, 01:31:30 PM »
Ok, I went back and converted Ubuntu-Light.ttf with exactly your settings.
The output is the same, only my "Font Preview" is showing the font at perhaps half the size than in your screen shot.
My .map file has the .xfont at 113536.

I almost copied your code:

Code: [Select]
    if (E_OK == EVE_init_flash())
    {
        EVE_cmd_flashread(MEM_FONT1, 113536, (309|3)+1); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
    }

    EVE_cmd_dl( CMD_DLSTART );
    EVE_cmd_dl(CLEAR_COLOR_RGB(51,51,51));
    EVE_cmd_dl( CLEAR( 1, 1, 1 ) );
    EVE_cmd_dl( VERTEX_FORMAT(0) );
    EVE_cmd_setfont2( 12, MEM_FONT1,       0 );
    EVE_cmd_dl( DL_END ); // does not do anything here
    EVE_cmd_dl( DL_DISPLAY );
    EVE_cmd_dl( CMD_SWAP );
    EVE_execute_cmd();

Code: [Select]
    EVE_cmd_dl( CMD_DLSTART );
    EVE_cmd_dl(CLEAR_COLOR_RGB(0,0,18));
    EVE_cmd_dl( CLEAR( 1, 1, 1 ) );
    EVE_cmd_text( 10,  10, 12, 0, "Quick fox at 120°C ");
    EVE_cmd_dl( DL_END ); // does not do anything here
    EVE_cmd_dl( DL_DISPLAY );
    EVE_cmd_dl( CMD_SWAP );
    EVE_execute_cmd();

And it still works, I get the line displayed at the top of the screen.

I am re-installing EAB now, I may have changed something before.
I redid it all, looks like I either modified EAB or previously did not install from scratch, or both.
The new .glyph file is different for some reason.
But the result is still the same, the line is printed just fine.

8
Discussion - EVE / Re: BT817Q's DL memory gets full with only 4404 bytes
« on: March 19, 2024, 05:37:42 PM »
I am trying to reproduce your output but I am not getting up to your number.
I am not using an UTF-8 code to not extra complicate things.

With this:

Code: [Select]
{
    static uint32_t alive = 0;
   
    if(tft_active != 0U)
    {
        EVE_cmd_dl(CMD_DLSTART);
        EVE_cmd_dl(DL_CLEAR_COLOR_RGB | WHITE);
        EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

        EVE_color_rgb(BLACK);
        for(uint8_t lines = 0; lines < 15; lines++)
        {
            EVE_cmd_text(10, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!");
            EVE_cmd_text(400, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!");
        }

        EVE_cmd_number(150, 570, 28, 0, alive++);

        EVE_color_rgb(BLACK);
        EVE_cmd_number(100, EVE_VSIZE - 30, 26, EVE_OPT_RIGHTX, display_list_size); /* number of bytes written to the display-list by the command co-pro */

        EVE_cmd_dl(DL_DISPLAY);
        EVE_cmd_dl(CMD_SWAP);
       
        EVE_execute_cmd();
    }
}

I do get 15 lines of text just fine, no problem.
But I "only" get 5284 printed for the size of the display list.
Increasing the lines to 19 this passes 7000 depending on the value of the alive counter.
And yes, still no issue.

Modifying the loop to this:
Code: [Select]
    for(uint8_t lines = 0; lines < 16; lines++)
    {
        EVE_cmd_text(10, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!123456789!");
        EVE_cmd_text(490, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!123456789!");
    }

It gets up to 8052 - no issue.

Modifying the alive counter to run from 1000 to 9999 to avoid extra digits and adding one extra line:
EVE_cmd_text(10, 540, 28, 0, "123456789!123");
Results in a display list of 8184 bytes.

So well yes, I need more text to get there, but like this I can really use the full display list.
No flickering, just works this way.

9
Discussion - EVE / Re: UNIOCDE fonts bigger than 18
« on: March 19, 2024, 12:24:27 PM »
As I just got a new company style guide to comply with I went thru a number of different fonts and font-sizes today using EAB 2.10.2.
I am using the fourth flash image now with only Roboto font in sizes 12/14/16/18/20/22/24/26/28.
I also tried Ubunto-Light, a couple of other fonts and using odd sizes 19/21/23/25/27.

And well, it just works in all sizes.
My input character file is this:
" !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~©«°±²³´µ¹»¼½¾ÄÖ×Üßäëö÷øü"
So only "Basic Latin" and a selection from "Latin-1 Supplement".


I encountered three "issues".
First one was that EAB 2.10.2 is using the correct size for the .xfont files now and adds a meta-file .pad in between the entries.
And at first I just copied the size for the .xfont file from the .map and used it with CMD_FLASHREAD - but the number of bytes read must be a multiple of 4.
In earlier versions of EAB there was no .pad and the .xfont ended up beeing shown with a size of 320 bytes.

My second issue was that I tried to use bitmap handle 15 for one of the fonts, just counting up from 12, which does not work by default as this is the scratch bitmap handle.

And my third issue was that the bandwith of the external flash is of course limited, even more so with random access, so I can not use the six fonts I set up for display from the external flash at the same time.
Well, I could use the font-cache for at least the largest font and copy all 9 fonts to RAM_G as the flash image is only 275kiB (copying the .glyph to RAM-G also requires to adapt the .xfont file to use the new memory location).
But this is not a real project anyways.

Edit: I tried a couple of things including over-clocking (looked stable at 96MHz but I went back to 72MHz)
I set REG_AH_HCYCLE_MAX to 4000 and now I have the line "Quick fox at 120°C" printed out in six different sizes: 18/20/22/24/26/28 and reading REG_FRAMES once per second and calculating the delta to the previous value shows rather stable 58 to 59.
So that really makes the last point a non-issue as well, even without copying any of the .glyph files to RAM_G.



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?

10
Discussion - EVE / Re: BT817Q's DL memory gets full with only 4404 bytes
« on: March 19, 2024, 10:40:27 AM »
Quote from: BRT Community on March 19, 2024, 10:25:45 AM
Just to update, We were able to fill RAM_DL to 7964 by using text commands with this string (on BT817)

What resolution does the panel have you tested this with?

11
Discussion - EVE / Re: BT817Q's DL memory gets full with only 4404 bytes
« on: March 18, 2024, 10:39:14 AM »
Quote from: Craggan on March 16, 2024, 01:00:26 PM
cmd_text( 10,  10, 1, 0, "\u00D6sterreicher \u00E4rgern sich \u00FCber \u00E4gypter");

Besides the issue, that is an odd way to work with strings.
I just use UTF-8 encoding for my source files, so in this case I would have "Österreicher ärgern sich über Ägypter" in the text.

12
Discussion - EVE / Re: BT817Q's DL memory gets full with only 4404 bytes
« on: March 12, 2024, 06:31:51 PM »
I have a RVT70HSBNWC00-B and I am using the exact same controller board with it, I only modified the regulator for the backlight to only do 5V since this is what the RVT70HSBNWC00-B requires while the RVT101HVBNWC00-B needs 7...14V for the backlight.

So on my side the same controller on the same board and therefore the exact same software using the same compiler etc.
With the 1024x600 RVT70HSBNWC00-B I can increase the NOPs to 1794 which results in a display list of 7272 bytes.
One more and it starts to flicker.

13
Discussion - EVE / Re: BT817Q's DL memory gets full with only 4404 bytes
« on: March 11, 2024, 09:19:33 PM »
That is interesting, I converted that code to work with my library to see if your library is at fault.

Code: [Select]
void TFT_display(void)
{
    if(tft_active != 0U)
    {
        EVE_cmd_dl(CMD_DLSTART); /* start the display list */
        EVE_cmd_dl(DL_CLEAR_COLOR_RGB | BLACK); /* set the default clear color to black */
        EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

        for(uint32_t i = 0; i < SENDNOPS; i++)
        {
           EVE_cmd_dl(DL_NOP);
        }

        EVE_color_rgb(0x600060);
        EVE_cmd_dl(VERTEX_FORMAT(3));
        EVE_cmd_dl(DL_BEGIN | EVE_LINE_STRIP);
        EVE_cmd_dl(LINE_WIDTH(5 * 16));
        EVE_cmd_dl(VERTEX2F(10 * 8, 10 * 8));
        EVE_cmd_dl(VERTEX2F(500 * 8, 500 * 8));
        EVE_cmd_dl(DL_END);
       
        EVE_cmd_button(250, 100, 100, 100, 28, 0, "Button");
        EVE_cmd_button(400, 100, 100, 100, 28, 0, "Button");
        EVE_cmd_button(550, 100, 100, 100, 28, 0, "Button");

        EVE_color_rgb(WHITE);
        EVE_cmd_number(100, EVE_VSIZE - 50, 26, EVE_OPT_RIGHTX, display_list_size); /* number of bytes written to the display-list by the command co-pro */

        EVE_cmd_dl(DL_DISPLAY); /* instruct the co-processor to show the list */
        EVE_cmd_dl(CMD_SWAP); /* make this list active */
       
        EVE_execute_cmd(); /* wait for the display list to be processed */
    }
}

And like this I can set SENDNOPS to 1003 with a resulting display list of 4784 bytes before the display glitches out.
Commenting out the three buttons I can set SENDNOPS to 1334 which is a display list of 5432 bytes.
So I can go higher, but I can not use the full 8kiB of the display list either.

One thing that could go wrong is that the CMD-FIFO is getting full since it only has 4kiB.
But that is not the issue, I am using individual commands in this example, no DMA, chip-select low, address, command, chip-select high.
It should not be possible to throw in more in the FIFO like this than the co-processor can handle.
But to make sure I slowed down the SPI and also added a busy-wait for the FIFO to be empty in the loop - makes no difference.

In a different project that really is putting stress on the BT817 with thousands of line-strip segments, I am using DMA and fill the FIFO with 3676 bytes with a resulting display list of 6108 bytes - but it glitches out after a minute or less.
When I put in less it runs longer without issue - and by less I mean less iterations, like "only" using 36 points per line strip instead of 64.
It looks like my BT817 is overheating, pretty sure it is not, but it looks like it is.

Oh, another observation out of a hunch, updating the display list less often seems to help as well, I am at 20Hz / 50ms now with 5672 bytes in the display list.

This does not help with the program above though, the limit is still 1334 NOPs with a display list of 5432 bytes.

14
Discussion - EVE / Re: How can I get image height and width after cmd_inflate?
« on: February 29, 2024, 05:21:47 PM »
CMD_INFLATE "only" unpacks data so the only information you can get additionally is the end address using CMD_GETPTR and therefore you could calculate the size of the uncompressed file.
So what you could do is to add extra information in front or after the data before compressing it.

15
Discussion - EVE / Re: BT817 Calibration has strange matrix, sometimes don't work.
« on: February 20, 2024, 05:58:43 PM »
Quote from: KarolBob on February 16, 2024, 12:30:17 PM
Also, I want to express my gratitude to Rudolph for his amazing work. Big thanks for that!

Thank you!


This made me realize that I probably never tried to calibrate my RVT101HVBNWC00-B. :-)
The touch worked ok as is.

Quote
TransMatrix1 = 65536;
TransMatrix2 = 0;
TransMatrix3 = 0;
TransMatrix4 = 0;
TransMatrix5 = 65536;
TransMatrix6 = 0;

These are the reset values for the registers, I am getting the same values here with no calibration.

The values I am getting after calibration are all over the place:
REG_TOUCH_TRANSFORM_A : 0x0000FF2F
REG_TOUCH_TRANSFORM_B : 0xFFFFFEAB
REG_TOUCH_TRANSFORM_C : 0x0005CACE
REG_TOUCH_TRANSFORM_D : 0xFFFFFCAA
REG_TOUCH_TRANSFORM_E : 0x00010116
REG_TOUCH_TRANSFORM_F : 0x00044696


And now I know again why I usually keep the RVT101HVBNWC00-B up on the shelf. :-)
It is big.
It is bright.
It is big.

Pages: [1] 2 3 ... 27