You are here

Easy flash saving method for PSoC3 | Cypress Semiconductor

Easy flash saving method for PSoC3

Summary: 2 Replies, Latest post by rolf on 07 May 2010 04:27 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
user_2405011's picture
88 posts


I noticed that the component configurations in cyfitter_cfg.c could run up easily to 4K of memory. Looking at the configuration data it seems easy flash savings could be made by compressing the data with RLE (bitwise) or Huffman encoding.

I've used Huffman successfully  in a Hydra part using 16 lines of C code and reducing 10K of bitmap graphics to appox. 5K.

Are there plans to do this for the configuration data?


Rolf - CYPros

bjbu's picture
Cypress Employee
23 posts

There are currently several options for the handling of configuration data for PSoC 3 and PSoC 5.  These are all configured using the Design Wide Resources System tab under Configuration:

Default setting:
  - Compressed  stored in normal Flash

Here are the various options:
  - Compressed:  This compression is not Run Length Encoding.  It is taking advantage of the fact that there are many zeros in the configuration of various blocks and that the chip comes up with all these registers set to 0.  This setting will build a table of the groups of non-zero values that need to be written.

 - Uncompressed:  This mode doesn't take advantage of the zeros for blocks of configuration data.  If a block needs some configuration, then the entire block is written.

 - DMA:  This mode uses the DMA engine to copy the configuration from Flash to the configuration registers.  This mode uses an uncompressed version of the data.  That results in it using more Flash, but it configures more quickly.

 - Store Configuration Data in ECC Memory:  There is one byte of ECC flash for every 8 bytes of normal flash (64KB flash part has 8K of ECC flash).  If you don't need ECC protection of the flash, then this ECC flash can be used instead to hold the configuration data.

Generally the ECC Flash area is large enough to store the configuration data.  Provided your application doesn't need ECC protection, then this mechanism effectively hides all the cost of the configuration memory.

Brad Budlong
PSoC Sensei

user_2405011's picture
88 posts

Hi Brad,


Thank you for your clear answer. It didn't came up to me that the data was already compressed, and it's great that it's already taken into account!

Maybe Huffman encoding could squeeze a bit more data. Huffman works great if the same value exists multiple times. The disadvantage is the table can take (too much) space at low data counts.




Log in to post new comments.