General Category > Discussion - EVE

Using flash for bitmaps

(1/4) > >>

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

--- End code ---

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


--- Code: ---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)

--- End code ---

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,


--- Quote from: BRT Community on June 17, 2021, 04:17:06 PM ---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

--- End quote ---

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: ---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.

--- End code ---

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,

Navigation

[0] Message Index

[#] Next page