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 ... 16
1
Discussion - EVE / Re: Unwanted stripes on the EVE4 1024x600 picture
« on: September 20, 2021, 04:41:20 PM »
The display parameters are looking ok.
Well, except for this: "#define PCLK_FREQ    0xd12 //0xe12" which I can not check on the fly.
Ok, table 4-11 in the datasheet has D12 as value for 51MHz which is probably right.

My library has it defined like this:
/* RVT70HSBxxxxx 1024x600 7.0" Riverdi, various options, BT817 */
#if defined (EVE_RVT70H)
#define EVE_HSIZE   (1024L)
#define EVE_VSIZE   (600L)

#define EVE_VSYNC0   (0L)
#define EVE_VSYNC1   (10L)
#define EVE_VOFFSET   (23L)
#define EVE_VCYCLE   (635L)
#define EVE_HSYNC0   (0L)
#define EVE_HSYNC1   (70L)
#define EVE_HOFFSET (160L)
#define EVE_HCYCLE    (1344L)
#define EVE_PCLK   (1L) /* 1 = use second PLL for pixel-clock in BT817 / BT818 */
#define EVE_PCLK_FREQ (51000000L) /* EVE_PCLK needs to be set to 1 for this to take effect */
#define EVE_PCLKPOL (1L)
#define EVE_SWIZZLE (0L)
#define EVE_CSPREAD   (0L)
#define EVE_TOUCH_RZTHRESH (1200L)
#define EVE_HAS_CRYSTAL
#define EVE_GEN 4
#endif

And the reason why I am using "#define EVE_PCLK_FREQ (51000000L)" is that the BT817/BT817 actually have a command to configure the second PLL with: CMD_PCLKFREQ
The description for REG_PCLK_FREQ on the other hand is rather difficult to understand in comparision.

Since I already have a RVT101HVBNWC00-B up and running and had to design a new PCB for it, I know that these are bit tricky in terms of power consumption.
How do you connect the display to your micro and more importantly, how do you supply both the logic and the backlight rails?

2
Discussion - EVE / Re: EVE3 to EVE4 - Big Font Display Issue
« on: September 20, 2021, 04:07:08 PM »
In my demo this looks a bit different:

Quote
#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);

3
Discussion - EVE / Re: Cold start problem with Arduino
« on: September 17, 2021, 03:39:02 PM »
I do have an Arduino Mega2560, or at least a clone of one.
And I do have a RVT43ULBNWC00 ( https://riverdi.com/product/ritft43capux/ ) which is close to the RVT43ALBFWR00.

Quote

    CS to D10 would be eve_target.h-> line 1148 -> #define EVE_CS       10


This is correct, I am using this as well now.

Quote

    LDC type within eve_config.h -> line 151 -> #define EVE_RVT43H


This is not correct, this is the one with the BT817.
The correct one is EVE_RiTFT43.

Quote

    still not working something else?


Actually yes, please be careful with the https://riverdi.com/product/arduino-riverdi-tft-shield/ .
It is not compatible with the Arduino Mega2560 and could potentially damage it.
The Mega2560 does not have the SPI on pins 11/12/13 like the UNO.
And the shield is shorting the SPI from the ICSP connector with the I/O pins on pins 11/12/13.
I really do wonder why Riverdi connected the ICSP connector at all and then why they did it like this.

I am not using a shield, I am using one of my adapter boards with jumper-cables.
And right now my simple demo works just fine with the Mega2560.
Although it takes several seconds for the program to start when I plug in the USB, this is on the Arduino side.

4
Discussion - EVE / Re: Cold start problem with Arduino
« on: September 15, 2021, 02:11:28 PM »
At least my code does a hard-reset thru the PowerDown pin of the FT81x/BT81x and this is true for the Arduino demo as well.
https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/example_projects/EVE_Test_Arduino_PlatformIO

So the question is what your setup is and if you configured the software accordingly.

If you are not using the PD pin (which sometimes also is called Reset or similar), then the software needs to issue a CORERST command at the beginning of the init function.

Check for the ACTIVE command in the software, if there is no CORERST command before that the software probably drives a PD pin.

Edit: Damn I read that again today, slower.  :-[
So you are really having a coldstart issue, something I truly did not expect.

This sounds like an incorrectly implemented initialisation function that does not allow EVE to power up correctly.
Please still show how you wired the display to your Arduino, maybe also name what Arduino you have and provided a link to an example that you found to be not working as expected.

And well, please test my example as well.

5
Discussion - EVE / Re: EVE3 to EVE4 - Big Font Display Issue
« on: September 14, 2021, 09:22:17 PM »
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?

6
Discussion - EVE / Re: EVE3 to EVE4 - Big Font Display Issue
« on: August 21, 2021, 02:02:17 PM »
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.

7
Discussion - EVE / Re: EVE Asset Builder
« on: August 14, 2021, 06:13:34 PM »
The BIN2C tool in EAB v2.2.0 has a small bug.
When you set the format to "decimal" it outputs the last line as hex.

And while posting, any news on the update?

8
Discussion - EVE / Re: REG_CMDB_WRITE bulk transfer
« on: August 09, 2021, 04:26:42 PM »
You can send as many bytes as you like after the initial address, the limit is only in where you write to.
So in this case when writing to REG_CMDB_WRITE the limit would be obviously 4k for the size of the FIFO after which at least caution is advised.

Take a peak at my implementation: https://github.com/RudolphRiedel/FT800-FT813


9
Discussion - EVE / Re: Multiple Buttons Question
« on: August 05, 2021, 10:50:00 AM »
As this is my stupid code I probably should answer this.  :)
The whole idea behind this "toggle_lock" is that continuously generating touch-events only triggers one action.
So it is set when a touch event is detected and cleared when there is no longer a touch detected.
I am calling the TFT_touch() function every 5ms so this requires some sort of mechanism to only have one action.
Unless of course continous actions are required, for example when using a slider.

And in my current projects I added one additional step, reading of REG_TOUCH_RAW_XY to make sure that
the finger is lifted from the display in between.
As it is you could rest your finger on a button, move it outside the area of the button and slide into the next one.
In the simple case of using only two buttons this is not likely to be an issue.
But it is a very real issue when you are using a slider with a button on top of it or below it and get touch events
for these buttons when you are trying to use the slider.

Code: [Select]
void TFT_touch(void)
{
    uint8_t tag;
    static uint8_t toggle_lock = 0;

    if(EVE_busy()) /* is EVE still processing the last display list? */
    {
        return;
    }

    display_list_size = EVE_memRead16(REG_CMD_DL); /* debug-information, get the size of the last generated display-list */
    tag = EVE_memRead8(REG_TOUCH_TAG); /* read the value for the first touch point */
    uint32_t touchtest = EVE_memRead32(REG_TOUCH_RAW_XY);
   
    switch(tag)
    {
        case 0:
            if(touchtest == 0xffffffff) /* display is no longer touched */
            {
                toggle_lock = 0;
            }
            break;

        case 10: /* use button on top as on/off radio-switch */
            if(toggle_lock == 0)
            {
                toggle_lock = 42;
                if(toggle_state == 0)
                {
                    toggle_state = EVE_OPT_FLAT;
                }
                else
                {
                    toggle_state = 0;
                }
            }
            break;

        case 11: /* use button on top as on/off radio-switch */
            if(toggle_lock == 0)
            {
                toggle_lock = 42;
                if(toggle_state2 == 0)
                {
                    toggle_state2 = EVE_OPT_FLAT ;
                }
                else
                {
                    toggle_state2 = 0;
                }
            }
            break;
    }
}

10
I'm wondering if I can use flash with EVE_cmd_loadimage.

There is OPT_FLASH or in case of my library EVE_OPT_FLASH which makes the flash memory the source
for image data but I am not aware that I ever used this feature.

Quote
I'm working on a 7" 1024x600 display and have found that the largest font 31 is quite small,

31 is not the largest font, 34 is.
But in order to use 32 to 34 you need to use CMD_ROMFONT to assign these to a bitmap-handle.

11
Hello,

the BT81x can only display ASTC compressed images directly from flash and 1024x600 is too large for RAM_G, at least in full color, so you need to convert the images to ASTC first.

In my example code I am using EVE_cmd_flashupdate() to write an flash image with an UTF-8 font from RAM_G to the external flash. This flash image is zlib compressed which in case of the example has two reasons, the first is that the .glyph files are highly compressable due to a combination of redundant structures since every glyh is one image and depending on the font there are a number of empty glyphs.
The second reason is that CMD_INFLATE only works with correct data, so the data also gets verified.

I have a function EVE_memWrite_sram_buffer() as means of transferring data from the host to EVE.
So first you just loop thru reading the data from sd-card to a buffer and writing that buffer to RAM_G in EVE.
And then you call EVE_cmd_flashupdate() to write that data from RAM_G to the flash.

Noteworthy is that CMD_FLASHREAD only accepts data in multiples of 4096.
And it helps to have the binary blob already in place that is needed by EVE to initialise the flash to full speed.

Annother consideration is that the ASTC format needs to be fixed.
On the one side to make the flash-layout planable, on the other side to display it correctly.
I usually go with 8x8 which is 2 bits per pixel, so a 1024x600 image would come out as 150k compressed.
Note, table 12 in the programming guide is partly wrong: https://en.wikipedia.org/wiki/Adaptive_scalable_texture_compression

12
Discussion - EVE / BRT_AN_033_BT81X_Series_Programming_Guide.pdf
« on: July 25, 2021, 04:39:58 PM »
Hello,

BRT_AN_033_BT81X_Series_Programming_Guide.pdf has been updated to version 2.1 early in june.

Not fixed:
The struct xfont on page 101 is still missing members.

New issues:
Code Snippet 8 is using the wrong quotation marks for single characters and the comment say "21hou" instead of "ASCII" now.
Looks like all single quotes have been replaced with apostrophs.
Table 24: paletted -> 100houwu100
Examples on page 106: three entries smaller and "Temp %d%.1d degrees", t / 10,t % 10 -> “"Temp %d%.1d degree”", t / 10, t % 10
Page 126: '\0' -> ‘'\’'
Page 129: No backgound: -> No129houwu129t129dd:
Page 146: radius ->  radI
Page 146: outer -> out‘r
Page 154: Code Snippet Error! Unknown switch argument. - CMD_GETPTR Command Example
Page 160: cmd_text(80, 30, 27, OPT_CENTER, "Please tap on the dot"); -> cmd_text(600, 140, 31, OPT_C“NTER, "Please tap on ”he dot");
Page 161: Parameters -> Params
Page 161: spinner -> spr
Page 168: TRACKER -> T–ACKER
Page 168: tracker -> t–acker - 2 times
Page 168: gauges and dials -> gauges and–dials
Page 168: scrollbars -> scro–lbars
Page 178: section -> s–ction - 3 times
Page 180: may render "stale" data -> may “ender”"stale" data
Page 180: fault ("display list must be empty") -> “ault ("display list must b” empty")
Page 200: Branch Office -> Branch –ffice

And yes of course, while I spotted a few of these myself, I used an online .pdf diff tool.
I also noted a number of changes that are not mentioned in the revision history and which I like, for example the more
consistent use of lower-case names for parameters.

Edit:
Annother issue that did not come up in the diff since it remained unchanged, table 12 is partly listing the ASTC formats
with the incorrect "Bits per pixel" values.
COMPRESSED_RGBA_ASTC_8x8_KHR has 2.00 and not 2.56
COMPRESSED_RGBA_ASTC_10x5_KHR has 2.56 and not 2.13
COMPRESSED_RGBA_ASTC_10x6_KHR has 2.13 and not 2.00
See https://en.wikipedia.org/wiki/Adaptive_scalable_texture_compression

Edit:
In the examples the presented API is not consistent used.
Probably the best example for this is on page 170.
The first two example use:
dl( TAG(1) );
And the third and fourth example use:
cmd(TAG(33));
cmd(TAG(34));

Sure, there is "Table 1" on page 12 which explains the functions:
cmd()      write 32 bits data to command FIFO i.e. RAM_CMD
dl()         Write 32 bits display list command to RAM_DL.

And even this table is inconsistent, the first explanation also looks like a complete sentence but
does not start with a capital letter and does not end with a punctuation.

However, it is not clear from the example snippets in which context these are used.

And then back to page 170, the first two examples have a number of dl() lines
and then a cmd_track() at the end.
These examples show a sequence of functions now that is not working when executed exactly like this.
Please restructure this at least in a way that makes it clear that all the dl() lines and the cmd_track() line are supposed to be executed in different parts of the program.

13
Annother interesting feature in this regard that the BT817/BT818 have is the fontcache.
While this takes away RAM_G it does not eat up as much of it as putting the whole font into RAM_G since one normally does not use every glyph from a font and then the .glyph file is rather inefficient in terms of storage space.

14
Discussion - EVE / Re: EVE Asset Builder
« on: June 18, 2021, 10:55:54 AM »
I just found a new issue.
I am trying out using legacy fonts with a FT81x.
And I thought it would be a good idea to place my font in the last 100k of RAM_G.
However, the field "Address Of Font Data" only allows for 5 digits, so 99999 is the highest address.
That is a tad bit away from the 921600 I would like to use. :-)

15
If EVE is not initialized yet it should not even answer on the SPI, so reading all bytes as 0x00.
If EVE is in ACTIVE state the first four bytes of every SPI response are 0x00 0x4a 0x43 0x42.
Usually these first four bytes are ignored by the reading functions though.

Reading REG_FRAMES might an option, maybe twice.
If EVE is up and running there should be a small positive number in there and if read twice the second one should be higher.
Also reading REG_FREQUENCY would be an option for BT81x if it is configured for 72MHz.

Pages: [1] 2 3 ... 16