Print

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

[FlorianG]

Hello everyone,

I propose this new topic in order to give us want / need about the new generation of chip "EVE" which I hope is already in the process of preparation
The current EVE BT81x are good but I'm sure Bridgetek can still boost

For my part I think there is 3 something that the new generation can improve. (In addition to always having more power and why not more features for 3D )

The first is the screen resolution. I would say that HD with 1 megapixel on the screen is the priority point.
But in the circumstance that the chips start to be used in time as GPU HDMI as for example with the project of GD3X HDMI of James Bowman the full hd can be very interesent. Maybe even the 4K, let's go crazy   

The second is a customizable clock frequency. in this way it would be easier to achieve the best performace of the screen use. And in addition to that overclock the chip to exceed 60 ip / s  .
I know that it was not all the objective of this chip but for some people (and I think the arduino community that pushes further and further the limits of the material) it can be very very interesent

The last point is about the memory size of the "RAM_CMD" and the "RAM_DL" which are not great in view of the fact that the memory of the bt81x and 4 times larger than the FT801.
Not to mention the fact that we can multiply it again by 256.
The ideal would be at least 64KB instead of 4KB.

Here is my list, if you want to add or discuss some point this topic is made for this 

[darkjezter]

Based on my own experiences with the BT816:

Control over built-in widget theming (drop shadow on fonts, 3d edges/corners, etc)

Ability to sidestep RAM_DL contention.  This one is a bit open-ended, but in a nutshell, RAM_DL is used both for preparing a new display list (and thus becomes unavailable when a swap is pending), and also for the construction of co-processor widgets.  This is the only case where I've found any issues overrunning the command FIFO.  The most powerful solution would be allowing the coprocessor to target an arbitrary RAM_G location for widget construction, however I have also explored aborting pending swap requests if the commands queued in RAM_CMD are no longer required.

Resistive touchscreen pressure measurement fixes.  After digging into an issue where the touchscreen reports touch events that do not correspond to actual events I found that the pressure measurement will successfully report a touch pressure when the analog measurement never settled during the measurement interval.  As pressure is the only configurable threshold to distinguish between touch and no-touch events, this leads to pressure thresholds that must be far less sensitive then the hardware would actually allow.  This issue allows X&Y coordinates that deviate from actual points of touch to be reported by the EVE in the case where the pressure measurement failed to stabilize.  Making use of the existing oversampling parameter to determine if the measurement did in fact settle to a valid reading would greatly improve this chip's touch reporting.

I can probably come up with some more suggestions, but I would have to say these are my big 3.

Cheers!

[Rudolph]

My additional points would be:

VERTEX2F:
http://www.brtcommunity.com/index.php?topic=10.0

Variants with LVDS interface.

A whole lot more bitmap handles. Like 256 in total.

Additional graphics primitives:
Circle - this needs two POINTS now
Box - like drawing two overlapping RECTS

>Posted by: FlorianG
>The first is the screen resolution.

Well, in theory EVE already supports 2048x2048 pixels. :-)
So to take this point all by itself I would argue that this already is plenty. :-)
But more seriously, yes, I would like to use a panel like this:
https://www.winstar.com.tw/de/products/tft-lcd/ips-tft/ips-lcd.html
In case the link does not work, this is a WF101GTYAPLNG0, a 10.1" LVDS IPS 1280x800.
And this is just the first thing I find with Googe and "ips tft".

>The second is a customizable clock frequency.

The clock frequency already is customizable.
But given the rest of your point it looks like you rather wish for a substantial increase in clock frequency in
order to run higher resolution panels at high framerates.
And yes, I totally agree with this.
What is a bit strange is the pixel clock setup in REG_PCLK as fractions of the main clock.
I guess these need to be in sync but the divider does not really work for higher clocks.
72MHz, 36MHz, 24MHz, 18MHz, 14,4MHz, 12MHz, 10,3MHz
This is perfectly fine for small displays needing low clock rates.
But there is no way to setup 48MHz for example.
Maybe a second PLL would help with this issue.

>The last point is about the memory size of the "RAM_CMD" and the "RAM_DL"

I agree, although even double the amount would be nice, so 16kB and 8kB.


Posted by: darkjezter
>Ability to sidestep RAM_DL contention. 

Seriously?

[Rudolph]

I forgot about CMD_GETPROPS which really does not work for random images.
While the first parameter, the address the image has been decoded to is rather useless since that parameter has been fed into CMD_LOADIMAGE anyways, what is missing from CMD_GETPROPS is the format of the resulting bitmap data.
Depending on the image it could be RGB565, L8, PALETTED565, PALETTED4444 or ARGB4.

This is an issue with user-provided images.

Now that I checked CMD_LOADIMAGE for the resulting formats I wonder why it is ARGB4 and not ARGB1555.


And to add a question are the COMPRESSED_RGBA_ASTC_* formats 32 bit?

[FlorianG]

"Well, in theory EVE already supports 2048x2048 pixels. :-)"
Thank you for this information, I was not aware. It must be said that Bridgetek is not very clear on this subject

-------------------------------------------------------------------------------------------------------------------------------
"The clock frequency already is customizable."

Ok but when i say customizable it is with precision to 1Mhz.
So that everyone can do what they want with these needs, overclooking included.

-------------------------------------------------------------------------------------------------------------------------------
"I agree, although even double the amount would be nice, so 16kB and 8kB."

I think that considering the fact that it is possible today to have 1 + 256M of video memory, we can have this parameter to have 64 - 128kb

[Rudolph]

"Well, in theory EVE already supports 2048x2048 pixels. :-)"
Thank you for this information, I was not aware. It must be said that Bridgetek is not very clear on this subject

That is because the refresh-rate starts to go down rapidly beyond 800x480.
As the base clock is a bit low and because of the way the pixel clock is derived from it.

"The clock frequency already is customizable."

Ok but when i say customizable it is with precision to 1Mhz.
So that everyone can do what they want with these needs, overclooking included.

And the rest of what I posted shows that I am agreeing with you.

A second PLL would be nice.
But not like the current one which only takes the 12MHz clock, allows a multiplier of 6 max so that
you scale this down again.

Instead it would be nice to have a Pixelclock-PLL which has a pre-scaler for the 12MHz
and a multiplier with a larger range and then the result is used as pixel-clock.

Example: 12MHz / 6x Prescaler * 23x Multiplier -> 55.2MHz Pixel-Clock.

"I agree, although even double the amount would be nice, so 16kB and 8kB."

I think that considering the fact that it is possible today to have 1 + 256M of video memory, we can have this parameter to have 64 - 128kb

I agree it would be very nice to have way more.
Embedded memory is driving up the costs though and I assume the FT81x/BT81x already have
around 2M integrated.
And do not forget that the display-list has to be processed, making it 8 times or 16 larger than it currently is may present a whole lot of additional challenges apart from "just" adding more memory.
So better a little more than no increase at all.

Also more GRAM would be handy at times, yes.

[Rudolph]

I have annother one to wish for. 

Unless I am missing something, using CMD_PROGRESS, CMD_SLIDER or CMD_SCROLLBAR are bit weird to use vertically.
The top position is, the bottom is max.
So for CMD_SLIDER and CMD_SCROLLBAR I always have to use position = max - current.
And well, that works okay, no big deal.

But CMD_PROGRESS does not really work.
You can not fill up the bar from bottom to top to for example indicate water level or battery power.
Yes, okay, you can invert the colors but filling the bar looks strange as it is rounded.

So my suggestion is to add an OPT_REVERSE for CMD_PROGRESS, CMD_SLIDER or CMD_SCROLLBAR to not only have them work from left to right and from top to bottom, but from right to left and from bottom to top as well.

[FlorianG]

Ho my god !!!!! https://brtchip.com/ew2020/

A BT817 and 1280*800!

[Rudolph]

There is very little that we know of the BT817 so far, and I know better than asking before the show. :-)


"4th generation EVE products supporting 24-bit interface and up to 1280x800 pixels"

This by itself is not exactly a new feature, you can have that with the FT813 already.
You do need a RGB/LVDS converter chip though as you will not find a TFT with 1280x800
and RGB interface.
I would find an integrated LVDS interfaces a lot more exciting. 

"Fully compatible to BT815 with 50% performance enhancement"

This is what makes the 1280x800 above a whole lot more interesting.
*If* this translates to 108MHz clock and *if* nothing is changed about the clock-system,
this means that REG_PCLK = 2 results in a pixel-clock of 54 MHz.
One display with 1280x800 I just found has typical 823 lines and 1440 clocks per line.
So at 54MHz pixel-clock this would give us 45 frames per second - rather sweet.
If such a board is carefully designed and really allows REG_PCLK = 2.

"Supports for non-square pixel TFT panel"

I can not really put my finger on what this really means.
That you can put in a small factor by which the image is stretched in X or Y direction in order
to make circles appear as circles on panels with non-square pixels?

"Support colour palettes, object creation, anti-aliasing, bimap transformation alpha masking and widgets drawing"

Core features of EVE, no doubt, but not exactly news?

"Capacitive and resistive touch options available"

For the EVE family overall? Or does this mean there also is a BT818?

[BRT Community Admin]

Hello,

Thanks for your interest in the BT817, we are currently working on the datasheet and hope to post it on our web site as soon as possible. We will also update this topic.


best regards

BRT Community

[FlorianG]

Hello, do you have any news about BT 817/818 ?