BRT Community
General Category => Discussion - EVE => Topic started by: Qrenz on June 05, 2020, 09:17:14 AM
-
Hi,
when using CMD_INFLATE we only provide the "Ptr" which is the destination address in RAM_G, then we write stream of bytes of the compressed image. We don't provide the size (total number of bytes) of our compressed image. So, how does the processor know when it is the end of our stream of bytes?
When write the REG_CMD_WRITE > REG_CMD_READ, then wait for a while, then write again another data, it could be the continuation of byte stream, and it could be a new CMD issued. So how the processor distinguish it?
Another question is after issuing CMD_INFLATE, we want to know the end address in RAM_G that was populated by calling CMD_GETPTR. This command returning the end address of decompressed data, so if we want to decompress another image, then the next address we specify in CMD_INFLATE ("Ptr") shoud be +1 from what we get from CMD_GETPTR?
-
Hello
If we take the following usage example:
API_LIB_BeginCoProList();
API_CMD_INFLATE(0);
API_LIB_EndCoProList();
API_LIB_WriteDataToCMD(LeaveItToEVE, sizeof(LeaveItToEVE));
API_LIB_AwaitCoProEmpty();
The data is written to the co-processor. The co-processor will then inflate the data into a format in RAM_G
on the user’s behalf which can be used directly by the GPU.
The library sends the CMD_INFLATE command to the co-processor as a separate command (using
the BeginCoProList and EndCoProList to do this). The parameter 0 indicates that the co-processor
will start outputting the resulting data to address 0 which is the beginning of RAM_G. The coprocessor now awaits the data to be inflated. The data follows immediately afterwards via the
WriteDataToCmd function which sends the array of data created above. This also takes care of
managing the co-processor read and write pointers and splitting the data into smaller chunks of
necessary. Finally, the code checks for completion by ensuring the buffer write and read pointers
are equal.
And yes the CMD_GETPTR will return the ending address of the data in RAM_G, you can load subsequent graphics assets in past this address.
Best Regards,
BRT Community
-
So, how does the processor know when it is the end of our stream of bytes?
From what I understand this is a property of the ZLIB compression that is used.
At the end of the data is a checksum and the decompression if finished when the checksum checks out.
Interesting, I was not aware of this.
And I just tested it, you can throw EVE completely off the roof with editing a single byte in a compressed picture.
I never observed this as an issue though.
-
Since the inflate command can not know how much memory will be required to store the result of inflation, EVE writes back the last memory location used in a unconventional place. In the "EVE School" example from Matrix Orbital, you can see this in action on the last line of the LoadJPG() function in "process.c".
https://github.com/MatrixOrbital/EVE-School (https://github.com/MatrixOrbital/EVE-School)
-
Hi, i'm following the example source code (sample project) provided.
Inside the function "API_LIB_WriteDataToCMD" it call the function "EVE_IncCMDOffset" and give 'CurrentChunk' as input. But CurrentChunk is uint16_t, while "EVE_IncCMDOffset" take unsigned char commandsize as input.
Just want to clarify?
-
Since the inflate command can not know how much memory will be required to store the result of inflation, EVE writes back the last memory location used in a unconventional place. In the "EVE School" example from Matrix Orbital, you can see this in action on the last line of the LoadJPG() function in "process.c".
https://github.com/MatrixOrbital/EVE-School (https://github.com/MatrixOrbital/EVE-School)
Well, the question was about CMD_INFLATE, not CMD_LOADIMAGE.
And you are using CMD_GETPTR after CMD_LOADIMAGE in your example.
The Programming Guides up to 1.2 for BT81x state for CMD_GETPTR:
"Get the End Memory Address of Data Inflated by CMD_INFLATE"
For CMD_LOADIMAGE we have CMD_GETPROPS - although this is kind of useless.
The pointer returned is the start-address which we already fed as parameter into CMD_LOADIMAGE.
And width and height are not helpfull without the format of the decoded image.
I just gave it a quick try with a FT813 and CMD_GETPTR does not work for CMD_LOADIMAGE.
EVE_cmd_inflate(MEM_LOGO, logo, sizeof(logo));
test_pointer1 = EVE_cmd_getptr();
EVE_cmd_loadimage(MEM_PIC1, EVE_OPT_NODL, pic, sizeof(pic));
test_pointer2 = EVE_cmd_getptr();
EVE_cmd_dl(DL_COLOR_RGB | BLACK);
EVE_cmd_number(120, 300, 28, EVE_OPT_RIGHTX, test_pointer1);
EVE_cmd_number(120, 330, 28, EVE_OPT_RIGHTX, test_pointer2);
This prints the same number twice and it is the end-address of the deflated logo image.
Hmm, well, it actually is the first address after the deflated data.