Print

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

[rascalito]

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,

[BRT Community]

Hello,

Thank you for your question.

Could you provide details on the DrawBitmap() function and how you have converted the image asset in EVE Asset Builder (i.e. what format you have used)?
Several different approaches are required depending on how you have converted the image, you can find some useful examples within EVE Screen Editors examples folder.

Best Regards,
BRT Community

[rascalito]

Hello!

Thanks for your reply!
In the meantime, I have found the problem, so here is a short report of what was wrong.
1. I was using a raw bitmap, defined as a const uint8[], sequence of 256 values in uint16
format (ARGB1555). No asset builder.
2. Drawing directly from GRAM works fine, so I wanted to draw to Flash (raw) and then
move flash to GRAM before drawing.
3. As you can notice, there are a few pink points in the drawing that failed, and since it's
the same color as the original picture, it gave me a hint that the flash was not empty.
Only the flash spaces containing FFFF were replaced with the pink color.
As a result, I checked my flash erase function, and the mistake was there.

By the way, in my function to write to flash, I always set an offset of 4096 bytes in order
to skip the BLOB. Is this necessary? Is there a mechanism in the chip, that would protect
the BLOB? An in this case, how do I update the BLOB?

Thanks,

Hello,

Thank you for your question.

Could you provide details on the DrawBitmap() function and how you have converted the image asset in EVE Asset Builder (i.e. what format you have used)?
Several different approaches are required depending on how you have converted the image, you can find some useful examples within EVE Screen Editors examples folder.

Best Regards,
BRT Community

[BRT Community]

Hello,

If you are not utilising a flash binary file generated from EAB which includes the .blob then you will also need to upload the .blob file to the flash IC as the CMD_FLASHERASE function willerase this. this can be done in the following manner:

Code: [Select]

1) Obtain the “unified.blob” file from the EAB installation folders, which is 4096 bytes only.
2) Ensure that the EVE board is properly booted up by following the known sequence.
3) Read the file “unified.blob” and download the whole 4096 bytes into RAM_G ( using EVE_MemWrite)
4) Send the command cmd_flashupdate(0,  RAM_G, 4096) to RAM_CMD, update the write pointer(REG_CMD_WRITE) properly
5) Wait till REG_CMD_WRITE is equal to REG_CMD_READ
6) The flash has been programmed with BLOB file.

Then you can use the CMD_FLASHUDPATE or CMDFLASHWRITE function to write your image files into flash from memory location 4096 onwards.


Best Regards,
BRT Community

[rascalito]

Hello!

Thanks for your reply.
In fact, I did it in the meantime like this:

1. od -tx1 unified.blob
Outputs the blob bytes (I'm working on Linux Ubuntu).

At that point, I noticed that the blob is mostly empty, merely 400++ bytes, so it's not worth
storing all the FFs. Fortunately all the FFs are grouped. Basically there is one group at the start
of the 4K block and one at the end. I stored the array without the FFs, defined HEAD_END and
a TAIL_START values.

2. Do the same command with a sed -e editing, in order to obtain a sequence of 0x values.

3. After erasing the memory, make a buffer to restore the blob as it should be (pad the empty
area with FFs), and write the 4K block (your points 2 to 6).

It works fine, and I will keep this RestoreBlob method in the library. I could verify that the
status indicates now fast mode (3).

Thanks,

[BRT Community]

Hello,

Thank you for the update, I'm glad you have managed to get the flash into FAST mode.

Are you still struggling with displaying images from flash?

Best Regards,
BRT Community

[rascalito]

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?

Code: [Select]

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.

[BRT Community]

Hello,

Could you share the options you have used in EAB to generate the ASTC output?

Please note: CMD_FLASHWRITE will erase the flash IC before performing the desired write, please use CMD_FLASHUPDATE to load the image data to the flash IC if you are not writing the flash IC with a .bin image (including .blob) file generated from EAB.Can you update your code to use the CMD_FLASHUPDATE command?

Also, yes you will need to load this data into RAM_G so that it can be written to the flash IC using the CMD_FLASHxxx commands. Please also pad the data to the next 256 byte multiple, some details can be found in the programmers guide:
https://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/BRT_AN_033_BT81X_Series_Programming_Guide.pdf

Best Regards,
BRT Community

[rascalito]

Hello!

I got close to the result. I have compressed the image with Brigetek's tools
and got output data, with the proper parameters. The linestride for some reason
is 496 (the bitmap itself is 364 x 364). As for the width and height, it became
372 x 372, probably because 364 cannot be divided by 12. (ASTC12x12 here).

By the way: is this a problem, or is it better to make bitmaps with sizes multiples
of the compression scheme (i.e. 12 x 12 in the case of ASTC12x12)?

See attachments for the results I get. Any comment is welcome to solve the problem
at the bottom of the picture.

Thanks,

[BRT Community]

Hello,

Thank you for the update.

I will  need to clarify with the development team, but I believe that the image will scale to a multiple of the ASTC block size used during conversion.
In this case it may be beneficial to use a compression scheme which is divisible by the size of the bitmap being used.

I gave the attached image a try on EVE Screen Editor both with a native conversion and a conversion carried out in EVE Asset Builder, and I couldn't recreate the behaviour you are seeing.

Could you provide the display list you are using?

Best Regards,
BRT Community

[rascalito]

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,

[BRT Community]

Hello,

Thanks for the details, but I was looking for the code used to display the image, could you provide this?
Sorry if I was ambiguous in the previous post!

Best Regards,
BRT Community

[rascalito]

Hello!

Thanks for the details, but I was looking for the code used to display the image, could you provide this?
Sorry if I was ambiguous in the previous post!

The code didn't change. The image is stored at the first 4K block after the BLOB. I'm using the
parameters from the json file.

Code: [Select]

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,

[BRT Community]

Hello,

Thanks for the update.

I decoded your commands and it gave the following:

Code: [Select]

CMD_DLSTART()
CLEAR_COLOR_RGB(48,96,144)
CLEAR(1,1,1)
BITMAP_SOURCE(524416)
BITMAP_LAYOUT(31,496,372)
BITMAP_EXT_FORMAT(COMPRESSED_RGBA_ASTC_12x12_KHR)
BITMAP_SIZE(NEAREST,BORDER,BORDER,372,372)
BEGIN(BITMAPS)
VERTEX2II(100,100,0,0)
DISPLAY()
CMD_DLSTART()
Using the above display list I was able to recreate the behaviour you were seeing.

After some testing it appears when using ASTC images the LAYOUT commands height parameter must be set to the height divided by the ASTC block size, in your case this would be 31 (not 372). Using the following command in ESE resolved the issue for me:

Code: [Select]

BITMAP_LAYOUT(31,496,31)
I would recommend however utilising the CMD_SETBITMAP command to mitigate any similar future issues:

Code: [Select]

CMD_SETBITMAP(0x800000 | 128, COMPRESSED_RGBA_ASTC_12x12_KHR, 372, 372)
BEGIN(BITMAPS)
VERTEX2II(100, 100, 0, 0)
CMD_BITMAP will automatically configure the BTIMAP_xxxx calls related to the image.

Best Regards,
BRT Community

[rascalito]

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.