Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rudolph]

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

[TFTLCDCyg]

I have a BT817 from Riverd like that you refer to, so far it has worked very well with the GDSTx library in teensy 4.1.

In order to experiment with that situation that you mention, you will have a guide on how to use your library in the arduino ide environment (preferably 1.8.19, since 2 seems to me to be an unfinished job and with many errors still), wiring, and what extra device is required to be able to use the onboard flash memory that the display has?

[Rudolph]

I have a BT817 from Riverd like that you refer to, so far it has worked very well with the GDSTx library in teensy 4.1.

I strongly disagree with the "very well" for the Gameduino library and would call that barely working.
That is my low-level assessment from what is actually going on with the SPI.

In order to experiment with that situation that you mention,

What situation?
My post is a question to Bridgetek regarding the claim in the programming guide that CMD_PLKFREQ needs the flash BLOB to be in place while in my experience it works fine with a completely empty external flash.
These are the first 15 lines.

The rest of my post is information regarding how REG_PCLK_FREQ works in the BT817/BT818 now plus a suggestion on how to improve it for a future device.

you will have a guide on how to use your library in the arduino ide environment (preferably 1.8.19, since 2 seems to me to be an unfinished job and with many errors still), wiring, and what extra device is required to be able to use the onboard flash memory that the display has?

While I do support Arduino in general, I do not support the "IDE, there are good reasons why large Arduino projects like Marlin are developed with PlatformIO.
Regardless, attached is a "HelloWorld" example that I have up and running for the Teensy 4.1 board and a RVT50HQBNWC00-B.
And it compiles for the UNO as well.

Here is what I did to make this work:
- created a folder "EVE_HelloWorld_Arduino_IDE"
- copied "EVE_Test.cpp" from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/examples/EVE_HelloWorld_Arduino_PlatformIO
- renamed "EVE_Test.cpp" to "EVE_HelloWorld_Arduino_IDE.ino"
- copied all files from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x
- copied a couple of "EVE_target_Arduino_xxx.h" files from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/EVE_target
- modified EVE_target.h: "#include "EVE_target/EVE_target" -> "#include "EVE_target"
- modifed EVE_config.h by adding a "#define EVE_RVT50H"

For Arduino IDE 2.x fewer steps should be necessary.

The pinout for the Teensy 4.1 is SPI default:
SCK 13
MISO 12
MOSI 11

The CS and PD pins are defined in EVE_target_Arduino_Teensy4.h:
#define EVE_CS 10
#define EVE_PDN 9

There is not much in the .ino but this would for example support DMA transfers on the Teensy 4 with two more lines.

Ok, one more.

- created a folder "EVE_Test_Arduino_IDE"
- copied all the files from "EVE_HelloWorld_Arduino_IDE", except "EVE_HelloWorld_Arduino_IDE.ino"
- copied the files from https://github.com/RudolphRiedel/FT800-FT813/tree/5.x/examples/EVE_Test_Arduino_PlatformIO/src
- renamed "EVE_Test.cpp" to "EVE_Test_Arduino_IDE.ino"

This now runs my basic example code that I use for all the examples, the display code is in "tft.c".
It runs with 50 frames per second and only needs 3µs for the display update on the Teensy 4.1 as DMA is used.

There is a test for the external flash included in this but it is deactivated by default.
At the top of "tft.c" there is this:
#define TEST_UTF8 0

Change this to:
#define TEST_UTF8 1

In TFT_init() you find this:

Code: [Select]

#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 */
        if (E_OK == 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

    if (E_OK == EVE_init_flash())
    {
        EVE_cmd_flashread(MEM_FONT, 61376, 320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
    }

#endif /* TEST_UTF8 */


That "#if 0" needs to be changed to "#if 1" to write a flash image with an UTF-8 font to the external flash of the module.
Let it run once and change it back to "#if 0".

The top line of the screen that reads "EVE Demo" is displayed with the UTF-8 font from the external flash.


Edit: I changed an include line in the EVE_target_Arduino_xxx.h files to make the whole process less complicated.

Now if there would be a way to set defines globally with the Arduino IDE it would not even be necessary to change EVE_config.h and the pins defined in the target files could be changed as well without changing the target files.

I tested this with Arduino 1.8.19 and 2.1.0 now.
Installing 2.1.0 and switching between these is painfull though with Teensy. I had to rename ../Appdata/Local/Arduino15 first or otherwise 2.1.0 would not even start. And starting 1.8.19 with the new folder offers no Teensy option when it is installed for 2.1.0.
Attached are slightly modified archives with the target headers in their sub-folder and EVE_target.h not modified.

Edit2: just noticed that I left the UTF-8 test active with the flashing inactive, changed tft.c to the original version

[BRT Community]

Hi Rudolph,
Thanks for your detailed information, we will review your feedback,
Yes, the main difference is that having the BLOB and Flash in full speed prevents the command from setting a value which exceeds the spec of the PLL frequency. Without these it may set a value which exceeds the allowable spec and so may affect reliable operation.

Best Regards, BRT Community

[Rudolph]

Hi Rudolph,
Thanks for your detailed information, we will review your feedback,
Yes, the main difference is that having the BLOB and Flash in full speed prevents the command from setting a value which exceeds the spec of the PLL frequency. Without these it may set a value which exceeds the allowable spec and so may affect reliable operation.

Best Regards, BRT Community

Thank you for the confirmation!
As I wrote, I never encountered the issue but at the very least my code is running more robust now after I changed it to not use CMD_PLKFREQ anymore.
Not that CMD_PLKFREQ is not working, but as I provide a library for anyone to use I can not rely on the content of an external flash that might not even be there.
I do not even have flash initialization in my init function so it can be done if required.