Print

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

[lorcap]

Hi everyone,

I'm trying to wrap my head around CMD_INFLATE2. I'm always getting ERROR: corrupted DEFFLATE data in cmd_inflate2(). FLASH is in attached state and I can read/write to it in no-fast mode. No blob is present in the FLASH.

First of all, am I wrong in assuming that CMD_INFLATE2 reads the FLASH from an address given by CMD_FLASHSOURCE? Something like:

Code: [Select]

cmd_flashsource(flash_addr);
cmd_inflate2(ram_g, 64);
Secondly, which kind of flash_addr does CMD_INFLATE2 need? A physical address or a BITMAP_SOURCE-like one (i.e., 0x800000 | phy_addr/32)? Chapter 2.1 Addressing Space cites CMD_INFLATE2 when talking about Flash memory. Chapter 5.86 CMD_FLASHSOURCE – Specify the Flash Source Address doesn't say anything about address space.

Thirdly, what does CMD_INFLATE2 exactly do? Does it read data from FLASH and inflate them on-the-fly, writing the result to RAM_G? Or does it read from FLASH, write data to RAM_CMD, then command CMD_INFLATE to RAM_G?

By the way, byte₁ at page 115 starts at byte 12, doesn't it?

[Rudolph]

>FLASH is in attached state and I can read/write to it in no-fast mode. No blob is present in the FLASH.

For this to work the FLASH has to be in full-speed mode and for full-speed mode a .blob must be installed.

>First of all, am I wrong in assuming that CMD_INFLATE2 reads the FLASH from an address given by >CMD_FLASHSOURCE? Something like:

Code: [Select]

cmd_flashsource(flash_addr);
cmd_inflate2(ram_g, 64);
Yes, it works this way.

>Secondly, which kind of flash_addr does CMD_INFLATE2 need? A physical address or a >BITMAP_SOURCE-like one (i.e., 0x800000 | phy_addr/32)?

The adress is relative to the FLASH itself, so exactly like in the map file:
unified.blob            : 0     : 4096
map_64x64_ARGB1555.bin  : 4096  : 7040
Wolf_96x96_ARGB1555.bin : 11136 : 5184

Code: [Select]

EVE_cmd_flashsource(4096);
EVE_cmd_inflate2(MEM_PIC2, EVE_OPT_FLASH,0,0);
EVE_cmd_flashsource(11136);
EVE_cmd_inflate2(MEM_PIC3, EVE_OPT_FLASH,0,0);

>Thirdly, what does CMD_INFLATE2 exactly do? Does it read data from FLASH and inflate them on-the-fly,
>writing the result to RAM_G? Or does it read from FLASH, write data to RAM_CMD,
>then command CMD_INFLATE to RAM_G?

As there are no precautions listed this should decompress directly from FLASH to RAM_G.
Otherwise it would destroy whatever commands that are waiting to be executed in RAM_CMD.
And RAM_CMD is only 4kB anyways.

>By the way, byte₁ at page 115 starts at byte 12, doesn't it?

Yes, I would think so as well.
And to be consistent with other commands it should be called byte0.



Since cmd_inflate2() is practically a twin of cmd_loadimage() I wonder why we even have cmd_inflate2().
A flag OPT_INFLATE for cmd_loadimage() would have been nice as well, and it could have been defined to include OPT_NODL.

[pauljiao]

To use the compressed assets in flash by cmd_inflate2, you need send cmd_flashsource to specify the address, which is offset from address 0.  In the image enclosed,you can see the number 4096
is the parameter of cmd_flashsource, which is the first asset after flash driver (unified.blob).

Check the image enclosed for details.

Code: [Select]

CLEAR(1, 1, 1)
CMD_FLASHSOURCE(4096)
CMD_INFLATE2(0, OPT_FLASH)

CMD_SETBITMAP(0, RGB565, 128,128)

BEGIN(BITMAPS)
VERTEX2II(104, 93, 0, 0)

[pauljiao]

Forgot to mention one point: The cmd_inflate2 fetching data from flash only works correctly when flash is in full speed mode.  So remember to issue command cmd_flashfast before all other commands are sent.

[lorcap]

Thank to everyone. Working in full speed mode fixed my issue with CMD_INFLATE2.