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

Pages: [1]
1
Discussion - EVE / Re: Modifying RAM_DL on the fly
« on: October 19, 2021, 03:48:41 PM »
Thanks, this confirms my impression of how it is built and you are right, relying on an implementation detail is not desirable.

I read the application note and both techniques are indeed interesting.
However, as I am using a BT817, I went another route with the use of CMD_NEWLIST to place the VERTEX2F items into RAM_G and then call them from my display list with CMD_CALLLIST.
I thought that this would allow direct modification of the RAM_G content but still, no luck. Apparently, the content of the list is read from RAM_G when the swap is done, not at every raster scan, contrary to what is done for bitamps for instance.

But I went further and used CMD_NEWLIST twice: the first contains the VERTEX2F commands, while the second contains the rest of the display items along with CMD_CALLLIST
Then, at every step of my "animation", I modify the VERTEX2F values in RAM_G and create this display list:

Code: [Select]
CMD_DLSTART
CMD_CALLLIST(BaseListAddr)
DL_DISPLAY
CMD_SWAP

This is not as simple as I would have liked, but at least it works.

2
Discussion - EVE / Modifying RAM_DL on the fly
« on: October 07, 2021, 03:23:04 PM »
Hello,

I have read the documentation where it is said that the BT817 chip is not using a frame buffer, but rather computing each pixel value from items in RAM_DL every time it sends RGB values to the attached LCD.
This gave me the idea to create a display list with the coprocessor, wait for it to have done its job, and then change VERTEX2F values directly into RAM_DL to achieve some nice animation effects without having to resend the entire display list.

So now, in my application, I start with the "main" display list that looks like this:

Code: [Select]
CMD_DLSTART
CLEAR_COLOR_RGB(255,255,255)
CLEAR(1, 1, 1)
COLOR_RGB(0, 0, 0)
CMD_TEXT(100, 100, 29, 0, "Welcome")
DL_DISPLAY
CMD_SWAP


Then after the user has interacted properly with the device, I start a new display list:

Code: [Select]
CMD_DLSTART
CLEAR_COLOR_RGB(0,0,0)
CLEAR(1, 1, 1)
VERTEX_FORMAT(0)
COLOR_RGB(255, 255, 255)
CMD_TEXT(400, 200, 24, OPT_CENTER, "Star field")
POINT_SIZE(32)
BEGIN(POINTS)
VERTEX2F(150,200);
VERTEX2F(450,380);
VERTEX2F(500,20);
VERTEX2F(400,250);
VERTEX2F(50,300);
VERTEX2F(600,400);
END
DISPLAY
CMD_SWAP

With this, I get a nicely written text with a 6 points, all white on a black background, as expected.

After having waited for the co processor to do its, I now use host memory read to look for 0x1F000002 starting at RAM_DL as this would be the location of the BEGIN(POINTS) command. Then I add another 4 bytes to skip the actual command and this gives me an address not too far from 0x300000

Now that I have the address for the first of the six points, I replace the values at those RAM locations at regular intervals with new VERTEX2F commands so as to make the points move.

But to my great dismay, this does not have any effect on the image rendered on the LCD.
I went back to the programming guide which mentions the REG_DLSWAP register which is to be used to signal that a new frame should be taken into account.
So I tried waiting for it to become 0, then write 2 (or even 1) inside it like in this "pseudo" code:

Code: [Select]
                for (int stepIndex = 0; stepIndex < 100; stepIndex++)
                {
                    usleep(50 * 1000);
                    while (EVE_memRead32(REG_DLSWAP) != EVE_DLSWAP_DONE);
                    for (int starIndex = 0 ; starIndex < starsCount; starIndex++)
                    {
                        stars[starIndex].X += stars[starIndex].deltaX;
                        stars[starIndex].Y += stars[starIndex].deltaY;

                        EVE_memWrite32(starsRAMAddress + starIndex * sizeof(int32_t), VERTEX2F(stars[starIndex].X, stars[starIndex].Y));
                    }
                    EVE_memWrite32(REG_DLSWAP, EVE_DLSWAP_FRAME);
                }

But this did not have the expected effect as it made the previous display list come back, then the star field one, then the white one and so on, each being activated in turn for the duration of the loop step. As I wait for 50milliseconds at each step, this causes quite a bit of flickering.

I must have missed something here, but what?
I really thought I would be able to perform fast animation by direct RAM_DL manipulation, but right now, I'm quite stuck.

Thanks for any suggestion

3
Discussion - EVE / Re: PALETTED4444 byte count
« on: September 24, 2021, 04:11:40 PM »
Thanks, that clarifies the situation. I believe that page 63 of the datasheet should be reviewed, it gives a wrong sense of what the memory usage would be.

4
Discussion - EVE / PALETTED4444 byte count
« on: September 22, 2021, 11:00:03 AM »
I'm decoding a 64x64 PNG file with CMD_LOADIMAGE and this gives me a PALETTED4444 image.
Looking at page 63 in BRT_000225, I see that it uses 16 bits, 4 for each components of the pixel, which matches the name of that format.
As a result, I give 64*2=128 as the linestride value in the BITMAP_LAYOUT command.
But this gives me a scaled down by 2 bitmap on the TFT.

I thus looked around the datasheet, and at page 60 it says that PALETTED4444 is using 8 bits per pixel which goes against what's shown at page 63. So what's the real value to use as the multiplier for linestride? 1 or 2?

And what is the memory layout for such a bitmap? With ARGB4, it's easy: 64*64*2 = 8192 bytes. But how do I know how much RAM is consumed by a PALETTED4444 image created by CMD_LOADIMAGE?

5
Discussion - EVE / Re: Tracking is shifted to the top
« on: September 17, 2021, 12:47:25 PM »
Ok, I went back to a "blank" display list, and the more I place the slider to the top right, the more the tracking gets shifted.

So I reran the calibration routine, this time taking the time to place myself right in front of the screen and taking the time to tap precisely.
And sure enough, now that I am using those 6 new values (A to F), there is no longer a shift at the top right location.

In the end, the error was on my side but it was very hard to track down because it was only occurring in a corner of the screen.
I'll now make sure I always calibrate properly.

6
Discussion - EVE / Tracking is shifted to the top
« on: September 14, 2021, 02:52:36 PM »
Hello,

I'm trying to use the CMD_TRACK method with a slider and started with this command list for a BT817 chip:

Code: [Select]
CLEAR_COLOR_RGB(255,255,255)
CLEAR(1, 1, 1)
VERTEX_FORMAT(0)
LINE_WIDTH(80)

CMD_TRACK(20, 30, 100, 10, 26)

COLOR_RGB(255, 170, 0)
CMD_FGCOLOR(0x999999)
CMD_BGCOLOR(0xDDDDDD)
TAG(26);
CMD_SLIDER(20, 30, 100, 10, OPT_FLAT, 45, 100)

This draws a nice looking slider but trying to "track" it I can only get REG_TRACKER to update if I place my finder above the slider bar itself. To illustrate, I added a blue and a green rectangle to give this display:


The blue rectangle is the slider itself, but I have to place my finger in the green rectangle to get any tracking effect.
At first, I thought that the calibration was not done properly, but the buttons with a tag get detected properly when pressed at their location, not above.

So to go further, I decided to change the value for y0 in the CMD_TRACK command, thinking there maybe was a need for an offset. As it did not have an effect, I went even further and created this display list:

Code: [Select]
CLEAR_COLOR_RGB(255,255,255)
CLEAR(1, 1, 1)
VERTEX_FORMAT(0)

LINE_WIDTH(80)

BEGIN (RECTS)
COLOR_RGB(255, 0, 0)
VERTEX2F(20, 200)
VERTEX2F(120, 240);
END;

BEGIN (RECTS)
COLOR_RGB(0, 0, 255)
VERTEX2F(20, 30)
VERTEX2F(120, 40)
END

BEGIN(RECTS)
COLOR_RGB(0, 180, 0)
VERTEX2F(20, 10)
VERTEX2F(120, 20)
END

CMD_TRACK(20, 200, 100, 40, 26)

COLOR_RGB(255, 170, 0)
CMD_FGCOLOR(0x999999)
CMD_BGCOLOR(0xDDDDDD)
TAG(26);
CMD_SLIDER(20, 30, 100, 10, OPT_FLAT, 45, 100)

This gives this display:


The red rectangle represents the area given to CMD_TRACK which you can see is clearly outside the slider. But it does not have any effect on the "hot zone" that is still inside the green rectangle.
I tried replacing the slider with a simple rectangle, it shows the same behavior.

What have I missed? Is there some special option to have the tracker consider the middle of the slider and not something above it?

For now, I have made a workaround by tracking a transparent rectangle placed below the slider itself, but it's really strange to have to resort to this.

7
Discussion - EVE / Rotating a text
« on: September 06, 2021, 04:44:06 PM »
I'm trying to write text at an angle of 15° and so I tried this set of commands:

Code: [Select]
BEGIN(BITMAPS)
CMD_LOADIDENTITY()
CMD_ROTATEAROUND(0, 0, 2731, 65536)
CMD_SETMATRIX()
CMD_TEXT(100, 100, 29, 0, "Test")
END()

But each letter is rotated individually, not the entire text by itself.

How can I achieve this rotation, so that the text looks like this:


8
Hello,

In the demo, there is this rendering:



I'm trying to replicate it, to get a green circle outline on top of a blue line, like this:



But with the given set of commands, all I'm getting is the line by itself:



Clearly, I have missed something, but I can't figure out what.

9
Discussion - EVE / Reproducing the demo outline circle in the screen editor
« on: September 02, 2021, 02:45:09 PM »
In the SampleApp, there is set_07 that displays only the outline of a circle by means of multiple points drawn with different blending functions.

I'm now trying to use this kind of effect in my own system and it does not work at all, nothing is displayed.

I thus went to the EVE Screen Editor application and tried to reproduce ConcentricCircles from set_07 with the following coprocessor list:


CMD_DLSTART()
VERTEX_FORMAT(0)
CLEAR_COLOR_RGB(255, 255, 255)
CLEAR(1, 1, 1)

BEGIN(LINES)
LINE_WIDTH(16)
COLOR_RGB(0x0, 0xFF, 0xFF)
VERTEX2F(200, 200)
VERTEX2F(400, 400)
END()

CLEAR_COLOR_A(0)

BEGIN(POINTS)

COLOR_MASK(0, 0, 0, 1)
BLEND_FUNC(ONE, ONE_MINUS_SRC_ALPHA)

POINT_SIZE(1600)
VERTEX2F(300,300)

BLEND_FUNC(ZERO, ONE_MINUS_SRC_ALPHA)

POINT_SIZE(1400)
VERTEX2F(300, 300)

COLOR_MASK(1, 1, 1, 0)
BLEND_FUNC(DST_ALPHA, ONE)

COLOR_RGB(0, 255, 0)
POINT_SIZE(1800)
VERTEX2F(300, 300)

BLEND_FUNC(SRC_ALPHA, ONE_MINUS_SRC_ALPHA)

END()


I was expecting this to give me a diagonal blue line with a green circle outline drawn on top of it.
But all I get is the blue line, nothing else.

What have I missed?

Pages: [1]