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 ... 21 22 [23] 24 25 ... 27
331
Discussion - EVE / Re: FT810 @ AtSamE70 interrupt-driven GUI (ESD4.5)
« on: December 16, 2019, 02:21:40 PM »
The interrupt is only the signal that a touch event occured.
So yes, you still need to assign touch tag values in order to get events
and at least read the current value when an interrupt occors.

But since reading the touch tags over SPI takes time as well (8 bytes) I would only set a flag
to indicate that touch should be looked at in my main loop (and only if that flag is not set already).
At 12MHz SPI it takes about 5,5µs to read REG_TOUCH_TAG.
This could be shortened by only reading the low byte to around 3,5µs.
That is like forever in IRQ for a 300MHz controller.

I am not using interrupts though because of how much time it takes to read the tag value and because
of the unpredictable nature of these interrupts.
I am just polling the tag value(s) once every 5ms as reading the values is necessary either way.

Hmm, I should update my sample-code: https://github.com/RudolphRiedel/FT800-FT813

Right now I am looking at 26µs idle for a two-point "multi-touch" function (BT815) that also includes making sure that EVE ist not currently otherwise busy.

If a touch event is registered only global vars are changed by my function.
Like which screen is to be displayed or how a toggle-switch or button is to be displayed.

Every 20ms my display gets refreshed, regardless if there are changes or not.
Tracking all possible changes and only updating on change only works with a static display.
But I am displaying for example measurements as well and use the timed refresh for animations.

My current GUI is processed in <250µs and then send over SPI using DMA.

The result is a 354µs load for the display within a 20ms intervall when idle, that is less than 2%.
I set myself a "limit" of 1ms for processing the GUI, that would be an allowable load of ~5%.
And the reaction to touch events feels instant.

Well, that is at least what works for me.

332
Discussion - EVE / Re: Fonts and xxx.ttf files
« on: December 12, 2019, 08:49:42 AM »
>What else do I have to consider to display the xxx.ttf files correctly?

You have not told us if you are using EVE2 or EVE3.
If you are using EVE2 things are a lot more complicated.
If you are using EVE3 then just convert the font to extended format,
put the .glyph and the .xfont file in the external FLASH,
copy the .xfont file to G-RAM on start of your programm,
use cmd_setfont2() in your display list to assign a bitmap handle to your custom font
and last but not least make sure you are using UTF-8 encoding for your source-file in
order to have your cmd_text() commands behave like you expect them to.

Something to be considered is the size of the resulting .glyph file.
If you are using a font like NotoSans from Google it contains a lot of glyphs and it might be a good idea
to convert the font first in order to remove several languages that you do not want to support.

333
Discussion - EVE / Re: Filled Irregular Polygons - Mission Impractical. Also, compressed data.
« on: December 11, 2019, 03:07:47 PM »

Quote
>2) Compressed data is sent in two packets - one for the command, one for the data.
>No interruptions, no checking for command buffer space, no breaking up into 4092 byte chunks to fit the buffer.
>Send the whole compressed data in one go. It is consumed from the buffer as fast as you can send it.

This makes no sense at all since nothing is processed untill you set the end-address.
So writing more than 4096 bytes in one go will make the FIFO loop around and overwrite itself.
Unless you are using REG_CMDB_WRITE to write to the FIFO but this still requires precautions.

What you can get away with is setting the end-address, wait a little, write the next chunk of data, set the end-address, write the next chunk of data...
How long you need to wait before you can write again depends on what type of data you are writing, how fast your SPI is clocked and of course on the clock of the EVE chip you are using.
And of course there is REG_CMD_READ and REG_CMDB_SPACE.

I tested .jpg versus .png on the FT813 a while ago.
I used a very simple 100x100 icon that I made with paint and compared the processing time for a .png version with 3867 bytes to a .jpg version with 3903 bytes.
The .jpg version needed 480µs to process after setting the end-adress, the .png version needed 53ms to process.
So that was 110 times slower processing of .png over .jpg.

While only using REG_CMDB_WRITE with a .jpg at full SPI speed might work with buffers larger than 4k, it will fail with .png unless REG_CMDB_SPACE is read for every step.

334
Discussion - EVE / Re: How to upload raw image into vram of FT8000
« on: November 21, 2019, 07:26:01 PM »
And to repeat myself here, you were actually looking for cmd_inflate(). :)

335
Discussion - EVE / Re: The Christmas list for BT82X
« on: November 21, 2019, 07:25:10 PM »
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????

336
Discussion - EVE / Re: BT81x and Animation support
« on: November 18, 2019, 08:10:44 PM »
There is a new EVE Asset Builder - v1.2.0 - and I like it.  :)

With regards to this thread it is now possible to set the tiling manually or disable it entirely.
Thanks!

Also interesting is the option to feed it GIF animations. :)

337
Discussion - EVE / Re: fading screen flicker
« on: November 18, 2019, 07:47:21 PM »
Okay, I received a new EVE3-50G today and have it up and running.

The good news is, I have no problem at all displaying the full set of 28 different icons directly from flash
with this display.

The bad news is, I still have no idea why it fails on the other display with the same resolution using the same code with an identical micro-controller and using the same pins.

With the EVE3-50G I can attach a USB adapter and flash from EVE Asset builder.
This works fine.
And erasing the flash and re-writing it from my Controller like I had to with the other displays also works fine.

There is a W25Q128JVSIQ FLASH on the display that fails and a 25Q32JVSIQ on the EVE3-50G.
The BT815 on the display that fails is labeled: K1COK BT815Q 1905-A
The BT815 on the EVE3-50G is labeled: K61TL.03 BT815Q 1842-A

And just for reference, I bought a chip from DigiKey that also is labeled like the on the EVE3-50G.
And the one on the RVT43 I have from Riverdi is labeled: K61TL.13 BT815Q 1802-A

So the "wafer lot number" looks different on the BT815Q from the display that fails but it still is
a revision "A" chip so it should just behave like the one on the EVE3-50G.

Whatever the heck is going on there?

338
Discussion - EVE / Re: fading screen flicker
« on: November 14, 2019, 09:45:11 PM »
Interesting, what about using more different pictures?

And you changed the code, you used VERTEX2II() as well.
I tried this as well and it still does not work with

Code: [Select]
0 1 2 3 4 5 6
7 0 0 0 0 0 0

This works:

Code: [Select]
0 1 2 3 4 5 6
0 0 0 0 0 0 0

And more interestingly this works as well:

Code: [Select]
0 1 2 3 0 0 0
4 5 6 7 0 0 0

So I tried to leave out the last two images in the row for which I use VERTEX2F().

This works:

Code: [Select]
0 1 2 3 0
4 5 6 7 0

Code: [Select]
0 1 2 3 4
5 0 9 0 0

This fails:
Code: [Select]
0 1 2 3 0
4 5 6 7 8

Code: [Select]
0 1 2 3 4
5 6 9 0 0


Okay, it looks like I really have to get annother display.
The one I have from Riverdi unfortunately is only the 4.3" version.
And my EVE3-50G for some unknown reason died a while back, just stopped working for no apparent reason.

Well, annother EVE3-50G it is then.

Edit: I maybe need to clarify this a little, I really have no idea why it stopped working, I had it on my desk, connected to my target board and it worked, I uploaded a new software to my board like I did a couple of times this evening, and the BT815 did not respond anymore and the panel stayed black.
There was no magic smoke involved and there was no visual clue on the board that something failed.
Since it was send to me from Digikey on the other side of the globe it did not even occur to me to send it back.
Instead I decided to try to fix it myself by replacing the BT815Q.
Well, that did not work out either but I learned that I am not ready yet to solder VQFN-64 packages. :-)
Whatever, I would not have bought just annother one from probably even the same batch if I were suspicous that there is anything wong with the EVE3-50G.

339
Discussion - EVE / Re: fading screen flicker
« on: November 10, 2019, 05:35:49 PM »
I really am a bit suprised that I can apparently demonstrate that ASTC support is broken and yet get no reaction at all from Bridgetek.

340
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??

341
Discussion - EVE / Re: BT815 to HDMI or VGA
« on: October 22, 2019, 05:51:45 PM »
You could try to contact these guys:
https://blackmesalabs.wordpress.com/2015/08/30/mesa-video-800x600-digital-video-for-arduinos-over-2-wire-serial-mesa-bus/

I am not sure though if this is available, at least there is nothing for this project on the github repository.
https://github.com/blackmesalabs

342
Discussion - EVE / Re: fading screen flicker
« on: October 17, 2019, 05:36:47 PM »
>Tried to display 28 different ASTC8x8 images(each image is 100x100) : 7 from flash and 21 from RAM_G.
> Found no issue at my side, see the picture attached.

Okay, what about really different images and all from flash? :-)
I have attached my flash file.

And why all these "BEGIN(BITMAPS)"?
One for a block of bitmaps is enough.
Also there is no END() in your posted code.

>Can you have a test on the flash read speed?

Not directly but I can measure how much time cmd_flashread() takes.
There is not much to gain from this as we have no information about how EVE is actually processing
the display-list and displaying anything.
A SPI trace would be more interesting, but my logic analyzer is way too slow to capture a QSPI which I expect to run at a minimum clock of 36MHz (half of EVEs clock).

An EVE_cmd_flashread(0,0,86784); takes about 4700µs.
An EVE_cmd_flashread(4096,4096,4752); takes about 320µs.
An EVE_cmd_flashread(0,0,256000); takes about 13720µs.
An EVE_cmd_flashread(0,0,384000); takes about 20550µs.

In Bytes/µs this is 18.46, 14.85, 18.66 and  18.69

So there is some overhead from my function which has less influence on the time with more data copied.
So lets say the flash can transfer 18 bytes per µs.
That results in 264µs for 4752 bytes.
And this also is close enough to show that the QSPI runs at 36MHz.

> I guess the issue may be related to flash read throughput.

Yes, maybe.
But then reading chunks of 2752 bytes from the very same flash chip that Bridgetek is using on their boards really should not be an issue.
And it could very well be that EVE is processing the images line by line and reading only the necessary data with every line.

Speculation.

Again, it does not seem to work like it should and I would apreciate a statement from Bridgetek regarding the issue.



Edit:
I just converted the set to 96x96 pixels.
And it has the same issues, directly using the icons from FLASH does only works up to a certain amount of different icons.
I can use 28 different icons from RAM_G without any issue.
And I can display 28 times the same icon from FLASH without issue.

Now I tried something new.

I changed the code to display only two lines of icons from FLASH:

0 1 2 3 4 5 6
0 0 0 0 0 0 0
This works.

0 1 2 3 4 5 6
7 0 0 0 0 0 0
This fails.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Okay. less icons overall (the '-' means the icon is not displayed):

0 1 2 3 4 - -
7 8 9 10 0 - -
This fails.

0 1 2 3 0 - -
7 8 9 10 0 - -
This works.

0 1 2 3 - - 6
7 - 9 - 0 - 0
This works.

0 1 2 3 - - 6
7 - 9 - 10 - 0
This works.

0 1 2 3 - - 6
7 - 9 - 0 - 10
This works.

0 1 2 3 - - 6
7 - 9 - 10 - 10
This fails.

0 1 2 3 - - 6
7 - 9 - 10 - 11
This fails.


Now this is interesting, if this would be an issue with the speed of the FLASH it should work better if there are less icons
on a single row and when there is more space between the icons - this is not the case.

Okay, annother idea, I added
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
lines after each VERTEX2F(), initally one line, then two lines.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Now I added BEGIN/END lines to each row of icons.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Now I added BEGIN/END lines to every single icon.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.


It still looks like something in EVE is broken and it is not getting any clearer what.

343
Discussion - EVE / Re: fading screen flicker
« on: October 16, 2019, 09:37:47 PM »
We can try to workaround it all we want, but what would be the point of this?
That code is perfectly fine.

And on the topic of bitmap-handles, 32 in total really is not enough, even more so when you take into account that one is for scratch and half are setup for the fonts.


I would apreciate if someone from Bridgetek would step in and explain what is wrong.

344
Discussion - EVE / Re: fading screen flicker
« on: October 14, 2019, 06:42:24 PM »
Thank you for the suggestion!

So I added "EVE_cmd_flashread(0,0,86784);" to my TFT_init() function.
And yes, at this point the FLASH already is in QSPI mode.

Then I changed my code to:
Code: [Select]
EVE_cmd_setbitmap(4096+(2752*0), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(0, 10));
EVE_cmd_setbitmap(4096+(2752*1), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(105, 10));
EVE_cmd_setbitmap(4096+(2752*2), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(210, 10));
...

And now I can display 28 different icons.
Which also verifies in one image that all of the icons in the FLASH are not corrupted.

I switched back to the original code for the first row.
And as you can see in the second attached image it works with 6 different icons from the SPI FLASH
and 21 different icons from RAM-G.
But when I change it to 7 different icons on the first row it completely bugs out and looks like
"20191013_202605s.jpg" of my previous post.


So I guess it is safe to deduce from this observation that the image decoder is not the source of the problem, at least not on its own.

And this looks like a reasonable workaorund, use highly compressed images from RAM-G that are stored in FLASH.
Only 2752 bytes for ASTC 8x8 with 100x100 instead of 20.000 bytes for ARGB1555 is nice.

Yet, this is not as advertised, if there really is a limit to what EVE can display directly from FLASH this should at the very least be documented with details what these limits are and why they exist.

345
Discussion - EVE / Re: fading screen flicker
« on: October 09, 2019, 10:49:50 PM »
I was intrigued by this.
So I converted 30 icons to 100x100 and put them as ASTC into a flash image.
Code: [Select]
unified.blob                                   : 0     : 4096
88_1_104x104_COMPRESSED_RGBA_ASTC_8x8_KHR.raw  : 4096  : 2752
88_104x104_COMPRESSED_RGBA_ASTC_8x8_KHR.raw    : 6848  : 2752
89_1_104x104_COMPRESSED_RGBA_ASTC_8x8_KHR.raw  : 9600  : 2752
89_2_104x104_COMPRESSED_RGBA_ASTC_8x8_KHR.raw  : 12352 : 2752
...

This is rather small, only 85kB in total.

Then I created a simple test-code included lines like this:
Code: [Select]
EVE_cmd_setbitmap(0x800000 | ((4096+(2752*4))/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(0, 10));
EVE_cmd_setbitmap(0x800000 | ((4096+(2752*5))/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(105, 10));
EVE_cmd_setbitmap(0x800000 | ((4096+(2752*4))/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(210, 10));
EVE_cmd_setbitmap(0x800000 | ((4096+(2752*4))/32), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(315, 10));

I can setup any of the 30 icons to be displayed and I am displaying 28 Icons in total right now plus a small monochrome image from RAM_G.
The display-list size is 1252 bytes, bytes send by SPI are 676, refresh is 20ms.
The display is a PAF90 from Panasys with a BT815 which is clocked 72MHz, the flash is a W25Q128JVSIQ.

Now here is the problem, when I display more than eight *different* icons, it starts to bug out.
The first thing that happens with one additional icon is that the display is not properly build anymore.
It kind of resets after the third row, repeating at the bottom what should be on top.
And make the refresh time longer does not help.
Adding annother icon and the colors in that repeated frame at the bottom gets messed up.
Now I added two more and it flickers like crazy displaying only the first row on the top and a portion of it at the bottom.

Going back to only eight different icons for the 28 icons displayed, everything is fine again.

It looks like there either is a bandwidth issue with the BT815 or the image decoder trips and resets or both.
If necessary I can provide pictures but this should be easily reproduceable.

Edit: I played with the code and took a couple of images.

These all use the same code but while the first (20191013_203941s.jpg) is displayed okay,
the display for the other three is messed up.
The only difference between these images is the amount of different icons to be displayed.

Pages: 1 ... 21 22 [23] 24 25 ... 27