Hello!

What I would like to know is how to convert with Linux. Apparently you are also using a program named astcenc.
There is a program with a similar name on Linux. I have noticed that the linux version has a 16-byte header,
and the asset builder's raw format doesn't. What I would need to know s whether the asset builder is a regular
astcenc  like the one that can be found on GitHub, or whether it's a BridgeTek proprietary format.
For instance Linux' astc encoder does not have a -f option and -g either.

Thanks for any hint.

R

Hello,

The method we advise using utilises Eve Asset Builder’s (EAB) command line mode and should save you a lot of time.

After installing EAB, you can run the image converter from the installation folder, for example:

“eab_tools  img_cvt  -i C:/Users/Pictures/appleicon.png -f 20 -o C:/Users/Pictures/temp -e thorough -x "C:/Users/Public/Documents/EVE Asset Builder 2.6.0_3.0.0/tools/astcenc.exe" -g”

The input file is “appleicon” and output folder is “C:/Users/Pictures/temp”.

Best regards, BRT Community

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

Hello!

I have modified my code to take into account the new height. Basically it works, and nothing is written
outside of the picture frame anymore. However, there is a tiny flaw as shown in the attached picture.
There is one little square at each of the corners of the bitmap I would like to write.
Is this an artefact of the compression method? I'm using the highest ratio, and for example a JPEG
image with a high compression ratio is blocky. So is it the reason why I get one block at each of the
corners? On the other hand, everything else looks perfect, so  that can be something else.

Thanks for any hint.

Hello!

Thanks for your reply.
The display I'm using is a 7 inch, 800 x 480, with capacitive touch.
The display's board has no reference I can see, but it's written BT815/816.

Thanks,

Hello!

Yes, I'm still struggling in getting images from flash.
I'm trying to display a bitmap directly from the flash this time. As I read in the documentation,
there are 2 conditions:
1. The flash must be in fast mode (solved)
2. The bitmap must be in ASTC format (not sure of what I did).

As I'm not sure what to choose for the encoding, I first tried with the ASTC12x12,
encoding code = 0x93BD. The output of Bridgetek's converter tells me that the stride
is 496 (1E0), so I will use this value as a linestride. As the format cannot be set
directly, I will use the format_ex setting.

By the way I wrote the data to flash direcly using cmd_flashwrite (directly from a const uint8[]
made by BT's bitmap converter). Is there any difference with writing it first to GRAM and use a
command to move it to the flash?
I'm asking that because that's how I was adviced to write the BLOB to the flash, first write to
G_RAM, and then move G_RAM to flash). Is there any problem in writing it directly?

Beside this, the documentation says that the number of bytes has to be a multiple of
256 bytes. The length of my data is 15376 bytes. What should I do? Pad to the next 256
multiple? In this case, pad with what? FF? 00? Something else?
I have used that kind of flash many times, and I know that stopping in the middle of a buffer
will just stop there, so I don't think there is a need of padding, and all the bytes
will stay as they were befor writing. Any hint?

Here is what my program sends to the LCD, and the analyzis of the SPI frame. It doesn't
work, it just displays a uniform square. The image is pretty simple, it's a uniform
dark blue with circles, as the background of a polar curve drawing program. So supposing
the image is properly written in the flash at 4096, what can be wrong?
B0 25 78 // CMD register
00 FF FF FF // BEGIN
90 60 30 02 // Color
07 00 00 26 // Erase with all flags (7)
80 00 80 01 // Bitmap source. 01800080 specifies the flash (8) and the address
// 80 is 128. 128 x 32 = 4k, the place in flash where the data is written
74 E1 FB 07 // 07FBE174 in this order: layout(07), format = ext (31 shifted gives F8)
// 1F0 is 496 (linestride). shifted and combined with the F8 gives FBE
// and finally 0174 which is 372, the width of the pixmap
BD 93 00 2E // Format EX is 93BD (37821 as explained page 58 of the documentation,
// for encoding ASTC12x12)
74 E9 02 08 // Size (without filter and repeat)
01 00 00 1F // Begin bitmap
00 40 86 8C // 8C864000 Vertex, 100x100
00 00 00 00 // END
01 FF FF FF // Swap
Thanks for any hint.

Hello!

Thanks for your reply.
I noticed from the documentation that 2 conditions have to be met to read directly bitmaps from flash.
1. The bitmap has to be one of the ASTC modes
2. The flash has to be set to fast mode.

Beside this, fast mode would allow me to check if it's erased (if it's back to basic, then it's erased).
So I tried to set fast mode. But without success. Here is what happens:
- Read the flash status gives me 2
- Write the command CMD_FASTFLASH returns 0, therefore I suppose it's fine. No E1_** code
- Read the flash status returns 2 (BASIC), not 3 (FAST).

Here are the scope captures.
1. For read status (that's basically a rd32 function that works everywhere else)
MOSI MISO //
30 25 F0 00 00 4A 43 42 // Flash status register (3025F0)+ extra byte, reply from MISO
00 00 00 00 02 00 00 00 // Send dummy data, get status

2. As for CMD_FLASHFAST, the documentation is a bit ambiguous.
It says: command layout
CMD_FLASHFAST // Offset = 0
result // +4
But as far as I understand SPI, the result cannot be part of the command (MOSI), it can just come from the
MISO. So I think it should be (on MOSI)
MOSI MISO
CMD_FLASHFAST dummy // Offset = 0
dummy result // +4

Similarily, the C interface should not be void cmd_flashfast(uint32 result);
but rather void cmd_flashfast(uint32 &result); or uint32 cmd_flashfast(void);

However it doesn't work, so I may be wrong.
Here is my CMD_FLASHFAST scope recording:
MOSI MISO
B0 25 78 00 4A 43 // Command register
4A FF FF FF 42 00 00 00 // CMD_FLASHFAST
00 00 00 00 00 00 00 00 // Dummy bytes on MOSI, reply on MISO

Is there anything wrong in this sequence?

Thanks,

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,

Hello!

Thanks for your reply. Ok, that explains it all. I should have thought about it or at least read the docs more accurately.

Thanks again!