cmd_inflate() problems

[jasonharper]

Is there any trick to getting cmd_inflate() to work properly?

I'm using this in my project to compress about 45K of static binary data into about 14K of Flash in the MCU.  Maybe 10% of the time it does produce the expected decompressed data (as verified by calling cmd_getptr() and cmd_memcrc()), but most of the time it produces garbage that is longer - sometimes 4X or more longer - than the original data.  I don't have any convenient way of dumping the entire results, but looking at a couple of small chunks around the start and end of the data, I see that it sometimes at least starts out right, and sometimes is garbage from the very beginning.

Note that I am using the GD2 with custom hardware, not any sort of Arduino, so it's quite possible that I botched something when porting the library.  However, my library works just fine for actual graphics, and I would expect anything I did wrong in issuing the inflate command to result in it NEVER working.  I've run out of things to try except for capturing the SPI transaction with a logic analyzer, but mine has nowhere near enough buffer space to capture the entire data.

[jamesbowman]

There's nothing special about cmd_inflate(), you just append the compressed data into the command buffer.

One thing to check is the code path where the command buffer is full. When doing graphics it is quite possible to never fill up the command buffer. But doing cmd_inflate() on 14K of data will almost certainly mean that the MCU will need to wait for the GPU to drain the command buffer.

As a quick test, split the 14K of data into four chunks of 3.5K each, and call GD.finish() before each cmd_inflate(). The command buffer is 4K, so this will mean that it never gets full.

[jasonharper]

Aha - problem turned out to be that I was writing the compressed data to the command buffer in 255 byte chunks (the longest a string constant can be, in the programming environment I'm using). I was assuming that momentarily being on a non-multiple-of-4-byte boundary wouldn't matter, as long as the total length of the data was padded out to a multiple of 4. I didn't consider that whenever the buffer filled up, the write pointer would be actually written to REG_CMD_WRITE with whatever (possibly odd) value it might have. (My version of getfree() wasn't masking the pointer with 0xFFC. Fixing that, or switching to 252 byte chunks, each resulted in consistently correct decompression.)

I guess that on the rare occasion when decompression actually worked, my writes had managed to stay ahead of the decompressor the whole way, so that the command interpreter never actually reached a partially-written word.