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.

Topics - rascalito

Pages: [1]
1
Discussion - EVE / Linux ASTC encoder
« on: July 16, 2022, 11:14:05 AM »
Hello!

I'm trying to make it easier to display bitmaps (i.e. without having to fetch width, height, data name, etc.. here and there).
I made a php script with Ubuntu (PHP8).
Basically I dump a bunch of files in a folder, run the script, and get all the corresponding .h and .cpp files with an option to copy
them directly in the bitmaps folder of my application. And I can call the bitmaps by name.
I'm using Linux' astc encoder (called astcenc), and here is the problem. There are quite a few parameters, a bit obscure to me.
Here is the result. It looks like the keyboard is splitted in two parts, there is a kind of interlace, etc. I'm sure there are people
here who know what happens and could help me.
There are myriads of parameters, and I can't try them one by one.
Does anybody know what parameters are used in EVE asset builder? The output name (the normal image below) is *RGBA_ASTC_8x8_KHR.
Any relation between KHR and LDR / HDR of the linux encoder?

Thanks for any hint!

R



2
Discussion - EVE / BT815 flash storage.
« on: January 27, 2022, 02:30:58 AM »
Hello!
I have a problem which doesn't seem to be documented.
I am using bitmaps stored in flash in format ASTC8x8.
I have written a function EveDisplay::StoreToFlash(uint8 * data, uint32 flash_add, uint32 len).
As if worked when debugging step by step and didn't work when running free, I suspected
a speed problem. I verified the speed from the datasheet, and it's 33 ns period.
In my case, I'm running at 13.5 MHz (MCU frequency = 216 MHz divided by 16.
And on the scope, I measure a periode in the 17 ns, so this is just fine.
Now I'm wondering about the CMD_FLASHWRITE command.
I'm sending data by blocks of 4K. If I set a delay between each block, then it works,
but otherwise it doesn't, and the screen gets lost.
I thought about checking if the screen is busy, but that would break the whole
CMD_FLASHWRITE command.

Sorry for the length, here are my questions:
1. Is there a need for some delay within the CMD_FLASHWRITE command?
2. What does the BT815 do exactly> Does it simply pipe the bytes into the flash
directly? Or does it store the bytes into a buffer that has to be flushed?
3. Is there any limit of the data buffer length of CMD_FLASHWRITE when doing
it in a single DMA burst?

Thanks for any hint.

R

3
Discussion - EVE / Flash busy detection
« on: June 17, 2021, 06:10:24 AM »
Hello!

I'm trying to use the external flash, and I have one problem:
When erasing the flash, I know by experience that it can take time.
On a 256MB flash, it may take about one minute. The one I use right now is
a 4MB, so I have made a workaround by setting a delay long enough.

Is there a way to check the flash status to be sure that it's actually erased,
and that it doesn't depend on the size?

I checked the status, but there are only 4 of them, FLASH_STATUS_INIT or
DETACH or BASIC or FULL.

As soon as I send the command for erase, the status is FLASH_STATUS_BASIC,
and I suppose it doesn't even change.

Is there another register to check for the flash status?

Thanks,

4
Discussion - EVE / Using flash for bitmaps
« on: June 17, 2021, 05:54:05 AM »
Hello!

I would like to use the flash, but I got some problems.
I reported earlier that I'm able to use bitmap when directly written to G_RAM.
Now I would like to use the flash and store compressed image, but first I want
to test the simple write to and read from flash.

Method: I'm going to use a bitmap known to work. It's a 16 x 16 bitmap.
Here is my code.

It's the same for both experiments, the only changing part
is the USD_FLASH value. The second part (when no flash is used), works.
As for the first part, it should be the same if I write the data first to flash,
then move it to G_RAM.

The first experiment, without flash, gives this result

The second experiment, with flash, gives this result.

Note that it's not exactly random, there are some pink pixels, which makes
me think I'm close to the goal, but something is wrong or missing.

Just in case: here is how I store the data to flash: (oscilloscope capture)

Code: [Select]
B0 25 78 // REG_CMDBWRITE
45 FF FF FF // CMD_FLASHWrITE
00 10 00 00 // Destination (4096 = 0x1000, just after the blob)
00 02 00 00 // Length (0x200 = 512, which is 16 x 16 x 2bytes per color)
00 00 00 00 // Start of the bitmap, these pixels are transparent
[...]
00 00 00 00 // End of bitmap, 512 bytes sent, which is a multiple of 256 as required

Here is how I move data from flash to GRAM (oscilloscope capture)

Code: [Select]
B0 25 78 // REG_CMDBWRITE
46 FF FF FF // CMD_FLASHREAD
00 00 00 00 // Destination (position = 0 in G_RAM)
00 10 00 00 // Source (0x1000 = 4096, just after the blob)
00 02 00 00 // Length (0x200 = 512, which is 16 x 16 x 2bytes per color)

Is there anything wrong in this?
By the way: is there a way to put the images inline? I suppose the reader will know which
is which, but it would be more readable.

Thanks,

5
Discussion - EVE / Filling a rectangle with tiles.
« on: June 04, 2021, 03:21:24 AM »
Hello!

I have been playing with bitmaps for a while, and I found something odd.
At first, after reading about bitmap layout, bitmap size, I discoverd that wrapx and wrapy
allow to tile a rectangle. Here is an example of tiling a rectangle with a smaller bitmap.
[apparently no way to attach pictures inline. I hope they will be attached below]

In the image IMG_4411.jpeg, the tile can be clearly shown. The tile size is 8 x 8.
The good thing about this is that with a very limited number of commands, you can
tile a large rectangle, even the full screen.

Now if I want to tile with a slightly different bitmap, it doesn't work at all. See the example
with a 8 x 9 bitmap. What I did is simply repeating the last line of the uint8[] array of that bitmap.

Here is what I could capture on the scope. It's the whole SPI communication between
the processor (STM32) and the LCD. Let's examine the 2 captures. Just to make sure
of what changes, I first took the 2 captures, separated everything by 4 bytes except the
3 first bytes, and then ran the diff utility on Ubuntu. I could make sure that only 3 lines
are different.
1. The working bitmap. Not much to say. There are 2 bitmaps, one large bitmap at (100, 0). tiled
with the small 8x8 bitmap that I also wrote at (0, 100).
Code: [Select]
B0 25 78 // Command buffer
00 FF FF FF // CMD_DLSTART
90 60 30 02 // Set clear color to bluish
07 00 00 26 // Clear with the 3 flags (0x07)
00 10 00 01 // Bitmap source (defined as 0x01000000 + address which is 0x1000)
08 20 00 07 // Bitmap layout (defined as 0x07000000. height = 8, linestride = 2 * 8 (0x10), shifted by 9 = 0x2000)
08 10 00 08 // Bitmap size (defined as 0x08000000. height = 8, width = 8, shifted by 9 = 0x1000
01 00 00 1F // DL_BEGIN bitmaps
00 40 06 80 // Vertex
00 10 00 01 // Same bitmap source as above
08 20 00 07 // Same bitmap layout
64 C8 0C 08 // Bitmap size. This time a large bitmap (100 x 100). 100 = 0x64. Shifted left by 9 is 0xC800 wrapx and wrapy flags.
01 00 00 1F // DL_BEGIN bitmaps
00 00 80 8C // Vertex
00 00 00 00 // DL_DISPLAY
01 FF FF FF // CMD_SWAP

2. The incorrect bitmap. Only lines 6, 7, 11 (marked with a * after //) change. The small tile
bitmap height is now 9 instead of 8. The width doesn't change.
Code: [Select]
B0 25 78 // Command buffer
00 FF FF FF // CMD_DLSTART
90 60 30 02 // Set clear color to bluish
07 00 00 26 // Clear with the 3 flags (0x07)
00 10 00 01 // Bitmap source (defined as 0x01000000 + address which is 0x1000)
09 20 00 07 //* Bitmap layout (defined as 0x07000000. height = 9, linestride = 2 * 8 (0x10), shifted by 9 = 0x2000)
09 10 00 08 //* Bitmap size (defined as 0x08000000. height = 9, width = 8, shifted by 9 = 0x1000
01 00 00 1F // DL_BEGIN bitmaps
00 40 06 80 // Vertex
00 10 00 01 // Same bitmap source as above
09 20 00 07 //* Same bitmap layout as above
64 C8 0C 08 // Bitmap size. This time a large bitmap (100 x 100). 100 = 0x64. Shifted left by 9 is 0xC800 wrapx and wrapy flags.
01 00 00 1F // DL_BEGIN bitmaps
00 00 80 8C // Vertex
00 00 00 00 // DL_DISPLAY
01 FF FF FF // CMD_SWAP

I also tried to tile with a 16x16 small bitmap and it works, even if the large bitmap is not a multiple of 16.
But I couldn't tile with a 48 x 48 bitmap.

So I would like to have some feedback. If it's not possible with other formats than
8x8, 16x16 and possibly a few others, I can live with it, but I just need to know.

Best regards,

R

Pages: [1]