store fonts in external flash and use codevision functions

[meysam_abbasinia]

hi
I'm use ATxmega128a1 and at45db161 for store my icons, I 'm design my own HMI by this microcontroller and 7 inch tft lcd, everything is OK but I used 6 font that stored in internal flash and now my code is 130% of microcontroller's flash! when i use optimize is 90% and my code still remind.
what should i do? how can i store fonts on external flash and use them by codevision glcd library functions. (like glcd_outtext or glcd_setfont)

thank you.

 

[doraemon]

Hello!

I'm not sure I fully understand what you are saying but here is what I did.
I have stored a Japanese font set in an external flash. It was a 8 pin AT45 something, so
it's pretty close to what you are doing, I guess.
One japanese font set takes about 250 kBytes (in 16 x 16 matrix). Here is how:
1 character: 16 x 16 matrix, therefore 16 x 2 = 32 bytes
1 unicode header for each of the characters, therefore 2 additional bytes. This brings us to 34 bytes.
7000 characters for Japanese, therefore 7000 * 34 = 238000 bytes.
This means that even with your small external flash (the flash you're using is 2 MBytes), you
can certainly store a lot of fonts and icons.

Now if you are using smaller font sets which is likely to be the case for other alphabets, then you
will need only very small sets of memory, even for large fonts.

Now writing text just consists in retrieving a font from the external flash and sending it to the display.
It doesn't take any internal flash space, and you need only a 34 bytes buffer for temporary font
storage. And if you want to prepare data and DMA it to screen, you may also need a buffer of the
same size as your largest font.

Dora.

 

[meysam_abbasinia]

thanks dora,
I don't have any problem for store fonts and icons on AT45 and display them on tft LCD, my problem is speed, in display text you need for every character have a communication by AT45 and read data from it, this is slower than when you store fonts on internal flash, another problem is codevision glcd functions that you can just use them when store fonts on internal flash.

 

[doraemon]

Hello!

What I did was using a MSP430 at 25 MHz. I don't remember where I have put the video, but the demo could write
a full page of japanese characters (15 characters x 20 lines) in about 0.3 second. Therefore, writing one line is
extremely fast. In case you do a menu manager, then it will be extremely responsive.
NB: I was using a 320 x 240 LCD. Of course, if you use a greater one, it

Some things to be aware of:
1. If you read the AT45 byte by byte in a loop, then the speed will be about half (or even less) of the speed you could
reach with a DMA.
2. Similarily, it you send byte by byte to the LCD in a loop, then it will take a lot of time.
3. If you prepare all the data you want to send (for example you prepare a full line of text) and you
send it at once, it will also be faster.

Dora.

 

[meysam_abbasinia]

hello,
I use 800*480 7inch tft lcd,
I read page by page from AT45 (528 bytes),i read a page for a character and write it on lcd, how can i write code for read all of my text characters from memory. i think we can not,
now about speed, for example when i display calibri20 font with 20 character 200ms needed, it is too big for a HMI with a lot of text in window,
can i see your code for display characters?
thank you.

 

[doraemon]

Hello!

First, there is probably a ground problem: the MCU you're using seems not adapted to your LCD, so you have
to understand that it's slow, whatever you do.
My code is spread in many files (spi.c, dma.c, etc...), and not easy to put together as an easily understandable
code. And I have almost no English documentation (only Japanese).
But let's calculate a little bit:
If you use a, say, 20 x 20 (400 pixel, therefore you need 50 bytes). Now for 20 characters, you need 1 kByte.
The time you will need to transfer it from the flash to RAM will be extremely short. If you are using a 25 MHz clock
and SPI with DMA, you should make it at 10 Mbps, 10 MBps for 8 kbit is 0.8 ms.
Then the most time consuming will be to generate color bitmaps. If you're working with 16 bit color,
you have to fill a buffer of about 16 K. If we count 2 MCycles/s for the transformation (text to image), since
you need 8 k cycles, it translates to 4 ms. (I must admit it might be slightly more). And about the same to send
the result to the screen. So I think your code is clearly not optimal.

Beside this, you can optimize (but it will cost you some memory or flash). For example, you can directly translate
all the byte combinations. Example: if you want to write 16-bit pixels corresponding to 00010001 in binary, then
you can pre-translate all the combinations. If we suppose that the foreground is for example black and the foreground
yellow, 0 will translate to 0x0000 (16-bit black) and 1 will translate to 0xFFE0 (yellow in RGB565). Then you can say:
00000000 -> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
00000001 -> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0xFFE0,
00000010 -> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0xFFE0, 0x0000,
00000011 -> 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0xFFE0, 0xFFE0,
And with this you can DMA copy chunks of 16 bytes which will be a lot faster than testing each of the bits.

Today's tendency is to have GBytes of RAM, GBytes of disk GHz processors, which means that there is no optimized code
anymore. But if you think of the old PCs (25 years ago), they were already driving color screens with processors at
20 MHz.

Dora.

 

[Dan Mills]

Also you may be able to do some lookahead so that the next character bitmap is being DMAd from the flash chip while the previous one is being written to the screen (assuming they are on different busses).

Try to track down a copy of "Graphics Gems" by Glassner, the whole series is useful if you are doing CPU based graphics rendering.

Some of us manage colour UIs on 8MHz, 8 bit processors, you just have to be really sneaky (A flash chip with its MISO pin connected to the displays MOSI line for example can let you clock data directly from the flash to the display by just putting the CS lines in the appropriate state, setting up the display controller and making the DMA engine generate the clocks without any processor involvement...).

Regards, Dan.

 

[doraemon]

Hello Dan!

This would work if you transmit bitmaps directly (bitmap that already exist in the flash). But storing raw data
for fonts (16 bit per pixel) is quite a lot of memory. Well, to be accurate, it eats 16 times more flash than a
bitmap font, and you don't have the possibility of changing the color.
For an alphabet, yes, it would be possible but again, no possibility of changing the color, except storing one
set for each background / foreground pair.

Dora.

 

[meysam_abbasinia]

dora you are right we can not use from that code,

my font store is different to your saving, you save 2 bytes for a pixel means you save color of your characters too, I don't store my fonts like this, look at this:

flash unsigned char calibri20[]=
{
0x00, /* Proportional font */
0x21, /* Font height */
0x20, /* First character */
0x60, /* Number of characters in font */

/* Character widths */
0x0E, 0x09, 0x0B, 0x0D, 0x0E, 0x13, 0x12, 0x06,
0x08, 0x08, 0x0D, 0x0D, 0x07, 0x08, 0x07, 0x0A,
0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E,
0x0E, 0x0E, 0x07, 0x07, 0x0D, 0x0D, 0x0D, 0x0D,
0x18, 0x10, 0x0F, 0x0E, 0x11, 0x0D, 0x0C, 0x11,
0x11, 0x07, 0x09, 0x0E, 0x0B, 0x17, 0x11, 0x12,
0x0E, 0x12, 0x0F, 0x0C, 0x0D, 0x11, 0x0F, 0x18,
0x0E, 0x0D, 0x0D, 0x08, 0x0A, 0x08, 0x0D, 0x0E,
0x08, 0x0D, 0x0E, 0x0B, 0x0E, 0x0D, 0x09, 0x0D,
0x0E, 0x06, 0x06, 0x0C, 0x06, 0x16, 0x0E, 0x0E,
0x0E, 0x0E, 0x09, 0x0B, 0x09, 0x0E, 0x0C, 0x13,
0x0C, 0x0C, 0x0B, 0x08, 0x0C, 0x08, 0x0D, 0x0E,

/* Code: 0x20, ASCII Character: ' ' */
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00,

/* Code: 0x21, ASCII Character: '!' */
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x30, 0x00, 0x30, 0x00, 0x30, 0x00, 0x30, 0x00,
0x30, 0x00, 0x30, 0x00, 0x30, 0x00, 0x30, 0x00,
0x30, 0x00, 0x30, 0x00, 0x30, 0x00, 0x30, 0x00,
0x30, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x00,
0x38, 0x00, 0x30, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00,

/* Code: 0x22, ASCII Character: '"' */
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x8C, 0x01, 0x8C, 0x01, 0x8C, 0x01, 0x8C, 0x01,
0x8C, 0x01, 0x8C, 0x01, 0x8C, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00,

this is my format,we save 0,1 format for fonts.
every where we need font set our color and use this variable for writing it to tft by our color.
fonts save in my memory like this.
I will send my function for write to tft.