Fonts stored on flash

[thexeno]

Hi,
After I've made HUGE progresses in the uGFX integration, I now step into text. And of course, with any text, I go just above 2kB of RAM. I was wondering if you have some support for the text to be handled byte by byte from the flash, natively. I thought that the static prefix would just suffice, but instead...

Thanks and apologize for the many questions. Keep up!

[Joel Bodenmann]

Hi,

I'm not sure whether I understand you correctly. Fonts are always handled in that manner. Fonts are never loaded into RAM by gdispOpenFont(). The requirement for using fonts is that the font is available in a byte addressable memory. Microcontroller FLASH usually fulfills this requirement. gdispOpenFont() will just prepare the font but the font data is not actually loaded into RAM.

You can also store your font in a non-byte-addressable memory and use gdispAddFont() to add it to the font engine during runtime once you loaded it into an addressable memory.

[thexeno]

On 10/25/2017 at 12:22, Joel Bodenmann said:

Hi,

I'm not sure whether I understand you correctly. Fonts are always handled in that manner. Fonts are never loaded into RAM by gdispOpenFont(). The requirement for using fonts is that the font is available in a byte addressable memory. Microcontroller FLASH usually fulfills this requirement. gdispOpenFont() will just prepare the font but the font data is not actually loaded into RAM.

You can also store your font in a non-byte-addressable memory and use gdispAddFont() to add it to the font engine during runtime once you loaded it into an addressable memory.

Hi, sorry for the delay.

As far as I know, with certains compilers, it is sufficient declare stuff as static to store in flash. Now, of course don't doubt that what are you actually implementing is designed to be stored in flash, but what I miss is how you can make it compatible with gcc. I am saying that because I had to setup a small project with a an Atmega using a big LUT, and the only way to tell the compile to store in flash, was to use the PROGMEM directive, and reading writing with the related macros. But seems that in uGFX something different is used, which I do ignore. And seems to store in RAM just because when loading a certain font (it goes on overflow RAM by some hundreds of bytes, meaning that is not only  variables used by the functionality). To be exact, without any fonts, FLASH is 9614B, RAM is 1542B. With fonts loaded, FLASH is 11208B (+1500B) and RAM is 2126(+580B), with the fixed_5x8 loaded.

Do you know a way to actually have something similar to PROGMEM? Or is it already optimized at maximum? Other libraries like U8g2 seems to occupy less memory, but I never analyzed them directly to be honest, I just compiled some open projects which are using graphics and text. If this was a just a bug in the gcc compatibility of uGFX, I see in it a huge improvement, that's why I tried at least to ask.

Thanks

Edited November 15, 2017 by thexeno

[inmarket]

When gcc compiles it places static const data into its own linker segment. It is up to the linker, the link map and the flash loader to ensure that is put in flash rather than RAM.

On most platforms that results in it being in flash. An example where it does not is the esp8266. For that processor everything is put into RAM because of addressing restrictions and alignment issues with the flash.

On your processor you will need to examine the linker scripts to see where static const data is put. In ugfx we define fonts as static const data and therefore expect it will arrive in flash. If it is not on your platform you may need to play with your linker scripts.

[thexeno]

43 minutes ago, inmarket said:

On your processor you will need to examine the linker scripts to see where static const data is put. In ugfx we define fonts as static const data and therefore expect it will arrive in flash. If it is not on your platform you may need to play with your linker scripts.

Nice to know, that is the issue I was talking about. In the Atmega processors (I expect others too) with gcc compiler, they need the pgmspace.h functionality and declare variables as one of these two options:

• const type name PROGMEM or type name PROGMEM (the const is just a good habit, but is not functionally needed here to work)
• const __flash type name

Using the static const only do not save in flash. I don't know if it is possible to tweak this on the linker. Any Atmel example and documentation use massively these two approaches. I am not sure, but I read that is the GCC way of working.

Edited November 15, 2017 by thexeno

[inmarket]

It should be possible to tweak the linker scripts as all the __flash directive is doing is to mark the data to be put into a special linker segment.

[thexeno]

On 11/15/2017 at 23:42, inmarket said:

It should be possible to tweak the linker scripts as all the __flash directive is doing is to mark the data to be put into a special linker segment.

After more investigation and asking also on more specific forums, the AVR8 (these 8bit Atmega) platforms are needing dedicated instructions for accessing data in flash, but also a dedicated address space, which is somehow coded in the pgmspace.h. So apparently I can adjust the linker for storing, but then I had to modify all the access in reading and writing, because the Atmega (8bit) are not supporting the flash visible in RAM address space.
So in the end is not compatible with a 8 bit Atmega family. Now I wonder if this is a limitation of gcc or of the MCU, but I think it is the latter.
If I really want to use such uGFX, I had to modify all the variable access and declaration, a thing that no one like.

But please, if I am wrong tell me. Thank you.

[inmarket]

We will look to add something like a GFLASH directive in ugfx v3.

Note the esp8266 has similar problems as the flash is only 32bit addressable, not byte addressable, even for byte level data. To work around the compiler places everything in RAM.