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
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.

Discussion - EVE / Bug: invalid options in commands are handled badly
« on: August 22, 2020, 01:39:53 PM »
I am currently rewriting parts of my code library and as part of this I am trying out all the commands that I rewrite.
Oh yes, I am using a BT815 right now.

Currently at cmd_toggle I somehow had the idea to feed it unsupported parameter options.
Listed as having an effect on cmd_toggle are OPT_3D and OPT_FLAT.
And of course, these do work just fine.

OPT_MONO -> black screen
OPT_NODL -> black screen
OPT_CENTERX -> black screen
OPT_CENTERY -> black screen
OPT_RIGHTX -> black screen
OPT_NOBACK -> no effect
OPT_FILL -> black screen
OPT_FLASH -> black screen
OPT_NOTICKS -> black screen
OPT_NOHM -> black screen
OPT_NOSECS -> black screen
OPT_NOTEAR -> black screen
OPT_FULLSCREEN -> black screen
OPT_MEDIAFIFO -> black screen
OPT_SOUND -> black screen

The options I left out either are alias ones use the same values or combinations of those above.
I have no idea how OPT_NOBACK has no effect but any other options makes EVE fail.

Please make the command co-processor filter out invalid options in BT817 and beyond.
And for all commands that take options.

Discussion - EVE / EVE Asset Builder
« on: May 16, 2020, 07:36:35 PM »
I found more issues with EAB 1.4.0 beside the UTF-8 ones that are already under investigation.

The release notes state:
- Add the "Verify" function in flash utility

And yes, there is a checkmark-button for this in the EAB GUI.
However, when you activate the option and click "UPDATE", you only get the default output of "ProgFlash.exe"
in the Log window:
Welcome to BT81X Flash Programming Utility v1.0
Copyright(c) Bridgetek Pte Ltd All Rights Reserved

Usage: ProgFlash [command] [argument]

module       Select Program Module [ FT4222 (default) | MPSSE ]
chip         Select Program EVE Chip [ BT815 | BT816 | BT815A ]
erase        Erase all of flash
newblob      Install blob <file_name> in flash
write        Write <file_name> to flash (assumes flash is already erased)
update       Write <file_name> to flash, erasing if necessary
read         Read all of flash into <filename>

As if the "ProgFlash.exe" is supposed to have a verify command but the version shipped with the EAB package does not.
The "ProgFlash.exe" from EAB 1.2 has the exact same output, the newer version is 512 bytes longer though.
And I have not found a verify command in the .exe but the list above is missing the "detect" command.

Regarding "detect", it does work as a command from the command-line but fails from the GUI.
And the GUI suggests that there is a parameter to avoid measuring the writing speed, I wonder if that is there and what is.

When I use ProgFlash to erase a chip this is what happens:
D:\Chip_Test>ProgFlash module MPSSE erase
 Information on channel number 0:
 Description=Single RS232-HS

handle=0x7197f0 status=0x0
VC1 register ID after wake up 7c

 reg_touch_rz =0x7fff
 reg_touch_rzthresh =0xffff

Switch flash status to FULL. Result: SUCCESS
Erasing Flash...
Progress ERASE 1
Progress ERASE 90
Switch flash status to BASIC. Result: SUCCESS
Progress ERASE 100
Erase Flash successfully

Why does it switch the flash to FULL in order to erase it?
There is no need to this, the chip-erase command will not work any faster.
What it does however is making it impossible to erase chips with EAB that do not work with the "unified.blob".
For example AT25SF641-SUB-T and AT25QF128A-SHB-T from Adesto.

On a side-note, what is a BT815A?

And why does EAB come with a "unified.blob", a "BT815.blob" and a "BT816.blob" now?
Which really is the same file with three different names.

- Replace 'numpy' by 'tinynumpy' to reduce distribution package size

No numpy to be found anywhere in the EVE Asset Builder installation.

Discussion - EVE / BRT AN 033 BT81X Series Programming Guide
« on: March 31, 2020, 07:50:43 PM »
I noticed that version 1.2 has been released and when I checked the revision history I "only" lists clarifications for CMD_ANIMFRAME.
When I compared that to version 1.1 I found that the new document has fewer pages as well.
So I sent it thru a diff tool.

Some reformating, minor fixes, excellent.
The offset for REG_SPI_WIDTH is still wrong though.

Then I found this in chapter 2.4 on page 15:
3. Send Host command “ACTIVE” and wait for at least 300 milliseconds. Ensure that there is
no SPI access during this time.
4. Read REG_ID till it is 0x7C

This is from the version 1.1:
3. Send Host command “ACTIVE” and wait for at least 300 milliseconds.
4. Read REG_ID till it is 0x7C

And for comparision, this is from the FT81x guide 1.2:
2. Send Host command “ACTIVE” to enable the clock to the FT81X. FT81X starts its selfdiagnosis process and may take up to 300ms.
 Alternatively, read REG_ID repeatedly until 0x7C is read.

Why has this changed to a fixed 300ms and why was this made stricter now and forbids SPI access during this time?

I am using this for years now:
Code: [Select]
while(chipid != 0x7C) /* if chipid is not 0x7c, continue to read it until it is, EVE needs a moment for it's power on self-test and configuration */
chipid = EVE_memRead8(REG_ID);
if(timeout > 400)
return 0;

And i works just fine with BT81x as well, I only increased the timeout to 400ms.

But for this post I went a step ahead and measured how long a couple of displays actually need:

EVE2-35G: 69
EVE3-35G: 42
EVE3-35G initialised as EVE2-35G: 75
EVE3-43G: 42
EVE3-43G initialised as EVE2-43G: 69
RiFT43: 42
EVE2-50G: 77
EVE3-50G: 42
EVE3-50G initialised as EVE2-50G: 72

No, these are not all my displays but the pattern is obvious.
FT81x need less than 80ms.
BT815 need less than 45ms since I set their clock to 72MHz.
And when I use a BT815 like a FT813 the startup delay becomes very similar.

Is there any compelling reason why I still should switch to a fixed delay of 300ms with no SPI access?

Discussion - EVE / CMD_GETMATRIX
« on: March 01, 2020, 09:24:13 PM »

why is this command named *GET*MATRIX?
This is not all what it does and it definately does not do the opposite of what SETMATRIX does.

GETMATRIX should be named SETMATRIX.
And the one that is now named SETMATRIX should be named ACTIVATEMATRIX.
And maybe a counter-part to what the current GETMATRIX does is missing.

That is if I am not completely wrong here.

Discussion - EVE / issue with EVE Asset Builder 1.2.0
« on: January 20, 2020, 05:33:17 PM »
Edit: I am not sure where my head was yesterday evening.

Converting images with the EVE Asset Builder v1.2.0 to ARGB1555 with compression results in rather large files and I suspect this is due to dithering beeing turned on by default.

I attached an archive with two button images that I converted using the image convert tool and EAB.
The result from EAB is very similar to what "img_cvt.exe" produces when not switching dithering off.
And the result with dithering off is a lot smaller.

I am using .png images for GUI elements and logos in order to not get compression related noise
in my images, this is kind of pointless when the converter deliberately adds noise.

Can we please have a checkbox in EAB to disable the dithering?
Preferably so that dithering is off by default, please.

Does the converter use dithering for BT81x ASTC images as well? If so - why???

Discussion - EVE / Automotive qualified BT81x?
« on: December 17, 2019, 12:58:18 PM »
What I was meaning to ask since at least this years Embedded World, are there any plans to have AEC-Q100 qualified versions of any of the EVE chips?

I am partly asking because of this:

But mostly as I am working in the automotive industrie.
And even while I am doing mostly prototyping, I prefer parts with AEC-Q qualification, or at least use parts for
which AEC-Q qualified versions are available.

Discussion - EVE / Products with EVE
« on: November 10, 2019, 05:21:38 PM »
EVE is around for some time now and yet I do know any product that has a FT8xx / BT81x inside.
There should be for example Coffee Makers with EVE inside.

Please name any product featuring a FT8xx/BT81x, regardless of what it is,
where are the Coffee Makers, Copiers, Glucose Monitors, Fish finders??

Discussion - EVE / List of QSPI FLASH Chips for BT81x
« on: October 05, 2019, 11:25:31 AM »
Maybe it is time to start a table of FLASH Chips that do or not do work with BT81x.


AdestoAT25SF641-SUB-T128YesYesYes0xE004 - device/blob mismatch
AdestoAT25QF128A-SHB-T128YesYesYes0xE004 - device/blob mismatch
MicrochipSST26VF064BA-104I/SM64YesYesWrite fails-

Please report any other FLASH Chip that you found to be working or not and I will add it to the table.

Shared Projects / EVE code library
« on: August 06, 2019, 09:51:53 PM »
Looks like this is the place to put something like this, I have a code Library up on Github for a while now:

Despite the name it supports BT81x as well.
I just finished a project for which I replaced a defective VM800B50A with a RVT50AQBNWC00.
This unit was driven by an Arduino mini-pro using the Arduino framework.
And in parallel I was testing the exact same display code on an EVE3-50G using an ATSAMC21E18A board with SPI by DMA.

I just released the first interation of V5 of my code library:

Discussion - EVE / BT81x and Animation support
« on: August 02, 2019, 05:19:31 PM »
I played with the new animation support in the EVE Screen Editor.
And I wonder what this is supposed to be used for.

Splitting up the frames of an animation into tiles is nice to save space in the external FLASH I guess.
Although the converter doubles the amount of frames and all the odd frames look exactly the same than
the even ones, so I have to wonder if this really is saving memory.
Without more insight I call this a bug in the converter.

There is a huge issue however, due to the tiling of the frames the display list is getting filled rather fast.
Now the smallest off-the-shelve FLASH on a BT81x module is 32MBit and I can easily replace it.
But the size of the display list is still only 8kB or 2048 commands.
The 124x300 pixel animation I have up in the EVE Screen Editor fills up the RAM_DL to 28% with only four lines
of coprocessor commands.

Am I missing something important here?
Right now this looks like a feature I rather not use.
Just cyling thru images on my controller has zero impact on the display list and while this costs a couple
more lines of code I just got a lot of free space for moving the images into the external FLASH.

And I checked, there is no way to tell the animation converter to drop the tiling.

Pages: [1] 2