I want to store 16x16 font image in EEProm. My MCU Rom size is 512. So the total number of fonts stored is 512*8/16/16=16. Do anyone know if there exist font compression algorithm in the world which can compress one font in the eeprom so that I can get more fonts.
However, you have to select the compression order to be match the display controller protocol or display memory organisation.
If the display requires that horizontal scan line is written in a single operation and the lines under it in separate operations, use the same RLE algorithm as in a telefax machines, i.e. use a full horizontal RLE of the _first_ scan line only. When compressing further scan lines, compare the scan line to the line just above it and note the differences. RLE encode the differences. When decoding, uncompress the first line, save it (requires as many bits as the character is wide:-) and write it to the display. When decoding the subsequent lines use the decoded and saved previous line as a starting point and apply changes.
If the display expects that a column is written at a time, RLE encode the leftmost column of the character. For subsequent columns, encode differences compared to the column immediately to the left. When decoding RLE decode the leftmost column and save it (requires as many bits as the character height) and write it to display. For the other columns, apply changes to the saved version and write result to display.
"terry" schreef in bericht news: email@example.com...
How do you calcultate that? 512 bytes rom size? 16x16 pixel characters?
512*8/16/16=16 -> characters, not fonts. Not even enough for a complete character set.
RLE encoding is a rather simple encoding scheme to implement, and probably the best choice for monochrome bitmaps. Or emulate 14 segment character display, two bytes for each character needed, and draw lines to display your characters, at any size you want.
(remove 'x' and 'invalid' when replying by email)
Yes, you can get algorithms that are character-aligned, but that can restrict the savings. Compression is a trade off, you need to define before you start:
CODE & RAM size that can be used for the algorithm ? EEPROM size needed/available to store the fonts ? Options during un-compress : do they have to come out in raster-order ?
Next, you should analyse the characters/fonts themselves, and their bit-spreads, and coherence.
The best compression schemes use the non-random nature of the data to best effect, and you can also use the users eyes.
Call this compression by pixel reduction :)
eg a very simple one, is to take your 16x16 char area, and encode as
8x8 where possible : Customer may decide 4 times as many, but chunkier, soft characters is a good idea. LCDs are workable down to ~5x7 fonts : that's a 7.3:1 compression
Or, going further to a 14 or 16 segment stroke- font, and stroke-decode sw, turns the 256 bits into 16 bits, for 16:1 compression. If you design your own 32 segment font, that's 8:1 compression, so you get the general idea.
Of course, serial memory is also very cheap, and starts in SOT23 packages...