BRT Community

Please login or register.

Login with username, password and session length
Advanced search  


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.

Topics - Rudolph

Pages: [1] 2 3
Discussion - EVE / image decoding and OPT_RGB565
« on: September 03, 2023, 09:33:21 AM »
I received an image file to conduct a test with and this image file is a .png.
Long story short, the image gets decoded to ARGB4 and not RGB565.

There is OPT_RGB565 in chapter 5.9:
Decode the source image to RGB565 format - CMD_LOADIMAGE

And the first idea I had was to provide this option in order to make CMD_LOADIMAGE
decode the .png file to RGB565.
But then I saw that the value for the option is actually zero, so this "option" does not actually do anything,
this is just the default value, this is !OPT_MONO.
As I was already using CMD_LOADIMAGE with bit 1 of the options cleared, this "option" OPT_RGB565 has no effect on loading PNG images.

Please consider removing OPT_RGB565 from the table in chapter 5.9.

Test and Review Area / EVE Asset Builder 2.9.0
« on: August 17, 2023, 06:02:33 PM »
I downloaded and installed and I have an odd issue.

The button to open the explorer window to select the output folder is not working for me in "Asset Compressor" / "Compress".
When I use the button on the second tab "Validate" though it works, I can select the output folder, I have to confirm twice and
now the output folder is also changed on the "Compress" tab.

Discussion - EVE / Cake?
« on: August 15, 2023, 04:58:17 PM »
I just realized, it has been 10 years since the launch of the FT800.

Discussion - EVE / What is the purpose of CMD_REGREAD?
« on: May 21, 2023, 03:49:32 PM »
What is CMD_REGREAD supposed to be used for?
It does not seem to have any use when building a display-list and outside of display list handling it is more efficient to read from the address directly.

I am playing with EVE_cmd_regread() and EVE_memRead32() on a BT817 - the results are the same for the most part.

Code: [Select]
for(uint8_t index=0; index < 32; index++)
    test1[index] = EVE_cmd_regread(0x302000UL + (index*4));
    test2[index] = EVE_memRead32(0x302000UL + (index*4));

Some of the not documented registers seem to be pretty usefull, like 0x3021A8UL + 0x3021ACUL, I wonder why these are not documented.
Reading from the not documented REG_DATESTAMP returned a string: "2019-10-28_2.5.3"
Reading from for example 0x303000 returns 0xdeadbeef.
Reading from 0x309218 returns 3, whatever that means. :-)

Reading from RAM_JTBOOT (0x30b000) is returning inconsistent results between EVE_cmd_regread() and EVE_memRead32(), not like EVE_cmd_regread() is executed with higher privilege, more like what is returned for this memory region is not actually accessible for both functions.

The region from 0x309000 to 0x30914e has a few documented registers like REG_TRACKER and REG_FLASH_SIZE,
it is not mentioned in the memory map though, "Table 5-1 BT817/8 Memory Map".

I also had a look at the code for BRT_AN_025.
are not implemented to do anything usefull and all these write out the parameters to EVE that are return parameters.
There is EVE_LIB_GetProps() though.

EVE_CMD_PCLKFREQ() does write the parameter "factual" although this is a return parameter.
EVE_CMD_FLASHFAST() does write the parameter "result" although this is a return parameter.
EVE_CMD_MEMCRC() does write the parameter "result" although this is a return parameter.

Discussion - EVE / CMD_CLEARCACHE with not empty display list
« on: April 27, 2023, 09:56:08 PM »
I am experimenting with making EVE cry in order to test recovering from co-processor faults.

And this might be one for the Bridgetek bug-tracker.
It takes over 12ms from issuing CMD_CLEARCACHE to getting a co-processor fault.
When reading REG_CMDB_SPACE 12ms after CMD_CLEARCACHE is done the result is 0x0FF8.
When reading REG_CMDB_SPACE 13ms after CMD_CLEARCACHE is done the result is 0x0FC3.

In contrast I am getting a co-processor fault after 20µs when issuing EVE_cmd_setscratch(43), did not check how fast actually.

I do not have an issue with CMD_CLEARCACHE, for one it is documented that the display list needs to be empty, my function EVE_cmd_clearcache() clears out both of the display list before issuing CMD_CLEARCACHE and then I can not recall that I ever used this command.
I just found this peculiar and perhaps this is something worth looking into.

Discussion - EVE / CMD_PCLKFREQ requires the flash BLOB?
« on: April 15, 2023, 08:37:54 AM »
I just found this in BRT_AN_033 BT81X Series Programming Guide version 2.3 which was not there in the previous revisions:

Important Note:
When using this command, the flash BLOB is required in order to ensure that the calculated PLL2
setting remains within the specification of 228MHz. Therefore, before using this command, ensure
that the following steps have been taken:
- External Flash chip connected to the BT817/8
- External Flash chip has the BLOB installed in the first 4096 bytes beginning at 0
- External Flash chip has been set to full-speedmode

Is this an editorial error?

I have been using CMD_PCLKFREQ in my init from the very beginning when the documentation for the bits in REG_PCLK_FREQ was not correct.
I have never set the flash to fullspeed mode before using CMD_PCLKFREQ.
Also the the flash was empty for at least the first tries of bringing up a new BT817 module.
It works just fine this way.

What dependency is supposedly between the external flash chip and the PLL2 for the pixel clock?

And I just did what I guess was a bit overdue, I calculated all possible frequencies for the pixel-clock
that can be setup with PLL2 thru writing to REG_PCLK_FREQ.

REG_PCLK_FREQ[11:10] is the range for the PLL2 frequency and not part of the calculation, my guess this is used for validation.
00: 20 – 40 MHz
01: 40 – 80 MHz
10: 80 – 160 MHz
11: 160 – 228 MHz

REG_PCLK_FREQ[9:4] is multiplied by 12MHz and the resulting PLL2 frequency must not be higher than 228MHz,
so the effective range for this 6 bit value is 1 to 19.
I really hope this value can go a couple of steps higher in a future device.

REG_PCLK_FREQ[3:0] is the divider and the pixel clock is calculated with this formula:
PCLK frequency = PLL2 frequency / REG_PCLK_FREQ[3:0] / 2
This makes the useable range for this 4 bit value to go from 1 to 12, at least is unlikely that higher values are of use.
The pixel clock must not be higher than 96MHz.

I put it all in a spreadsheet and sorted it by pixel clock.
These are the top values:

11   10   9   8   7   6   5   4   3   2   1   0         Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
1   1   0   1   0   0   1   1   0   0   0   1   3377   D31   3   19   1   228   114,000
1   1   0   1   0   0   1   0   0   0   0   1   3361   D21   3   18   1   216   108,000
1   1   0   1   0   0   0   1   0   0   0   1   3345   D11   3   17   1   204   102,000
1   1   0   1   0   0   0   0   0   0   0   1   3329   D01   3   16   1   192   96,000 x
1   1   0   0   1   1   1   1   0   0   0   1   3313   CF1   3   15   1   180   90,000 x
1   1   0   0   1   1   1   0   0   0   0   1   3297   CE1   3   14   1   168   84,000 x
1   0   0   0   1   1   0   1   0   0   0   1   2257   8D1   2   13   1   156   78,000 x
1   0   0   0   1   1   0   0   0   0   0   1   2241   8C1   2   12   1   144   72,000 x
1   0   0   0   1   0   1   1   0   0   0   1   2225   8B1   2   11   1   132   66,000 x
1   0   0   0   1   0   1   0   0   0   0   1   2209   8A1   2   10   1   120   60,000 x
1   1   0   1   0   0   1   1   0   0   1   0   3378   D32   3   19   2   228   57,000 x
1   0   0   0   1   0   0   1   0   0   0   1   2193   891   2   9   1   108   54,000 x
1   1   0   1   0   0   1   0   0   0   1   0   3362   D22   3   18   2   216   54,000
1   1   0   1   0   0   0   1   0   0   1   0   3346   D12   3   17   2   204   51,000 x
1   0   0   0   1   0   0   0   0   0   0   1   2177   881   2   8   1   96   48,000 x

The first three are not valid as these are above 96MHz.
The lines with the "x" at the end are also found in the table 4-11 of the BT817/8 datasheet.

This is a bit of a surprise for me as I went the first time thru this, there are very few frequencies to choose from above 60MHz.
Totally plausible when put in a table like this.

I was feeding CMD_PCLKFREQ with 71MHz for the 1280x800 displays.
And now I see that this is not even possible and the result likely was 72MHz.
The reason why I even looked into this is that the 10.1" panel with 1280x800 that I am trying to add a configuration for
is using a pixel clock of 72.4MHz (typical).
Ok, no problem, 72MHz it is.

I went with using CMD_PCLKFREQ as my first calculations with the previously incorrectly documented bits for REG_PCLK_FREQ got me nowhere.
And using CMD_PCLKFREQ did not only work, it looked like it allowed more flexibility over the apparently select "few" values
for REG_PCLK_FREQ in the datasheet.
Now I will remove the call to CMD_PCLKFREQ.

And as a final thought, these are the values if the PLL2 frequency would be allowed to go up to 480MHz:

   Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
E02   3   32   2   384   96,000
DF2   3   31   2   372   93,000
DE2   3   30   2   360   90,000
DD2   3   29   2   348   87,000
DC2   3   28   2   336   84,000
DB2   3   27   2   324   81,000
E83   3   40   3   480   80,000
DA2   3   26   2   312   78,000
E73   3   39   3   468   78,000
E63   3   38   3   456   76,000
D92   3   25   2   300   75,000
E53   3   37   3   444   74,000
D82   3   24   2   288   72,000
E43   3   36   3   432   72,000
E33   3   35   3   420   70,000
D72   3   23   2   276   69,000
E23   3   34   3   408   68,000
D62   3   22   2   264   66,000

The granularity is only a little higher so "just" allowing the PPL2 to run much higher does only achieve very little.

Adding a pre-scaler to bring down the 12MHz to a lower value before it is fed into the PLL2 would be much simpler to implement,
under the assumption that the multiplier already works all the way up to 63x.
So I kind of wish now that a future device would feature a clock pre-scaler for PLL2.  :)

This is the top of the table with a pre-scaler of 4 so the PLL2 gets 3MHz as input frequency:

   Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
FF1   3   63   1   189   94,500
FE1   3   62   1   186   93,000
FD1   3   61   1   183   91,500
FC1   3   60   1   180   90,000
FB1   3   59   1   177   88,500
FA1   3   58   1   174   87,000
F91   3   57   1   171   85,500
F81   3   56   1   168   84,000
F71   3   55   1   165   82,500
F61   3   54   1   162   81,000
F51   3   53   1   159   79,500
F41   3   52   1   156   78,000
F31   3   51   1   153   76,500
F21   3   50   1   150   75,000
F11   3   49   1   147   73,500
F01   3   48   1   144   72,000
EF1   3   47   1   141   70,500
EE1   3   46   1   138   69,000
ED1   3   45   1   135   67,500
EC1   3   44   1   132   66,000

Discussion - EVE / Reading BT815 font metrics
« on: February 20, 2023, 06:38:03 PM »
I am playing with reading the BT815 font metrics and the results do not match the "Table 4-8 ROM Font Table" in version 1.2 of the BT817/BT818 or version 1.0 of the BT81x datasheet.
For font 28 I get L4/9/18/25 while the datasheet has L4/9/19/25.

Now table 4-9 lists a width of 19 pixels for "@" and "M" and the width value I am reading from the table is indeed 19.
For "W" I get a value of 18, for "R" I get a value of 13 and both match table 4-9 as well.

There seems to be at least a bug with rom_font.pixel_width of font 28?

Discussion - EVE / API inconsistencies
« on: October 31, 2022, 11:17:01 AM »
As I am going thru the MISRA-C report for my library I am finding API inconsistencies.

The given C prototype has "uint16_t result" as last parameter.
While this by itself is not correct and "result" should either be the return value or a pointer,
the description for result is:
"result return. Set to -1 on success, or 0 if it is not possible to find the solution matrix."

Which one is it, uint16_t or int16_t?
And actually the native type for RAM_CMD would be uint32_t.

Discussion - EVE / RST_PULSE after ACTIVE
« on: May 13, 2022, 09:39:12 PM »
Continuing from here since this is kind of off-topic there.

So, there is the recommendation that appeared in the version 2.2 of the BT81x programming guide to issue a host command "RST_PULSE" right after "ACTIVE".

I was concerned that this would further delay the startup by at least 20ms.

I just tried this with a RVT101HVBNWC00-B since the board that is connected to my RVT70HSBNWC00-B does not have pins attached to connect a logic-analyzer.

The good news is, adding a "RST_PULSE" after "ACTIVE" makes no difference at all.
The bad news is, well, it makes no difference at all.

The trace shows there is an inital group of host commands.
0x44 0x00 0x00 CLKEXT
0x61 0x46 0x00 CLKSEL to configure 72MHz
0x00 0x00 0x00 ACTIVE

0x68 0x00 0x00 RST_PULSE

Then there is 41ms delay from my software before the next activity on the SPI starts.
0x30 0x20 0x00 0x00 0x00 - reading the chip ID

On the first two reads there is no answer from the BT817.
On the third read there is a reaction on the MISO line:
0x00 0x4A 0x43 0x42 0x7C - chip ID sucessfully read

This sequence is exactly the same with or without RST_PULSE.

Next reading REG_CPURESET and the return-value is 0x02 - the touch-controller still is in reset.
On the next read 1ms later the return-value is 0x00.
Again, same with or without RST_PULSE.

The BT817 is doing just fine.
I can not even make it not start right now, no RST_PULSE, no toggle of the PD line, cold-start, warm-start, it always starts.
Three host commands, 41ms pause, 0x7c response on the third read.

I changed my delay to 42ms -> 0x7c response on the first read.

Now this is interesting, when I extend the delay, REG_CPURESET does not return 0x00 earlier.
44ms, 54ms, 154ms - the first reading of REG_CPURESET, after REG_ID returned 0x7c, always returns 0x02.
The second reading with 1ms delay in between returns 0x00.
Removing the 1ms delay between REG_CPURESET reads shows that 0x00 is returned on the tenth read with my SPI settings.
So there actually is a connection between reading REG_ID, EVE needs about 50µs after REG_ID returned 0x7c before REG_CPURESET returns 0x00.
There is the potential to shave off 900µs from the startup-time. :-)

More seriously, I am not sure what to take away from this experiment.
From what I have seen so far the requirement of having a RST_PULSE right after ACTIVE makes no sense since it
does not seem to change the startup in any way.
Same as adding a plain 300ms delay makes no sense when the BT81x are up and running much earlier.

Discussion - EVE / Font-Cache
« on: October 05, 2021, 07:06:14 PM »
There is only a single font-cache, correct?

I am asking because the documentation for CMD_FONTCACHE does not explicitly state that there is only one font-cache.
cmd_fontache(20, 0xa0000, 0x10000);
cmd_fontache(21, 0xb0000, 0x10000);
cmd_fontache(22, 0xc0000, 0x10000);

This could be valid and would perfectly make sense given the bandwidth for the flash is rather limited.

However, then there also is CMD_FONTCACHEQUERY and the API for this one is:
C prototype: void cmd_fontcachequery( uint32_t total, int32_t used );

Which btw. is not valid c-code for the intended functionality as passing these parameters by value would not do much.

Anyways, since there is no parameter to identify a font-cache this probably means that there is only one.

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

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.

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

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:

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.

I have released a small example project that displays the same image compressed with different ASTC profiles from 5x5 to 12x13:

Discussion - EVE / cap-touch: configure / gesture ?
« on: March 25, 2021, 06:31:05 PM »
I have been asked how to configure the sensitivity for a cap-touch controller connected to EVE.
That would be for GT911 but would also be interesting to  know if this is even possible for focaltech touch controllers.

I checked the datasheet and the programming guide and it looks like there is no way to configure anything for a cap-touch controller.

But what I found and what brings me to my second point, the datasheets have this:
"In extended mode a new set of readout registers are available, allowing gestures and up to five touches to be read."

As far as I can tell there is no gesture support and no way to activate an existing gesture mode in the touch-controller.
Is that correct or am I missing something?

Discussion - EVE / BT817 / BT818 new features
« on: October 29, 2020, 06:07:26 PM »
As the BT817 / BT818 are officially released now, let's talk about it. :-)

These are the new registers:
#define REG_UNDERRUN     0x0030260c
#define REG_AH_CYCLE_MAX 0x00302610
#define REG_PCLK_FREQ    0x00302614
#define REG_PCLK_2X      0x00302618
#define REG_ANIM_ACTIVE  0x0030902C

This are the new commands:
#define CMD_APILEVEL       0xFFFFFF63
#define CMD_CALLLIST       0xFFFFFF67
#define CMD_ENDLIST        0xFFFFFF69
#define CMD_GETIMAGE       0xFFFFFF64
#define CMD_HSF            0xFFFFFF62
#define CMD_LINETIME       0xFFFFFF5E
#define CMD_NEWLIST        0xFFFFFF68
#define CMD_PCLKFREQ       0xFFFFFF6A
#define CMD_RETURN         0xFFFFFF66
#define CMD_RUNANIM        0xFFFFFF6F
#define CMD_TESTCARD       0xFFFFFF61
#define CMD_WAIT           0xFFFFFF65

The first thing to note for me was that the BT817 / BT818 do have a second PLL now for the pixel clock.
The easiest way to setup the second PLL is using CMD_PCLKFREQ.

I have this in my code-library now:
Code: [Select]
#if EVE_GEN > 3
uint32_t frequency;

#if defined (EVE_PCLK_FREQ)
 frequency = EVE_cmd_pclkfreq(EVE_PCLK_FREQ, 0);
 if(frequency == 0) /* this failed for some reason so we return with an error */
   return 0;

EVE_memWrite8(REG_GPIO, 0x80); /* enable the DISP signal to the LCD panel */
EVE_memWrite8(REG_PCLK, EVE_PCLK); /* now start clocking data to the LCD panel */

Note, EVE_PCLK has to be defined to "1" to use PLL2.

With a define like this:
#define EVE_PCLK_FREQ (51000000L)

The resulting pixel-clock is 51MHz and the 1024x600 display I configured this for runs at 60Hz.:-)

What also got my attention is CMD_NEWLIST, CMD_ENDLIST, CMD_RETURN and CMD_CALLLIST.
Looks like we can expand display list now. :-)

And now I go on reading. :-)

Discussion - EVE / CoProcessor faults and REG_CMDB_SPACE
« on: August 30, 2020, 05:48:25 PM »
The programming guide states for REG_CMD_READ:
"In the case of an error, the co-processor engine writes 0xfff to this register."

As I was reading REG_CMD_READ for my  EVE_busy() function anyways I put the reset-on-fault code
in EVE_busy() as well.

Now I changed my library from writing to RAM_CMD+offset to use REG_CMDB_WRITE.
And it seems obvious to use REG_CMDB_SPACE in EVE_busy().
When the FIFO is empty the value in REG_CMDB_SPACE is 0xffc.

Now my question is, does the coprocessor also write 0xfff to REG_CMDB_SPACE in the case of an error?
The documents do not say anything about this but it seems logical.

Pages: [1] 2 3