search

oscaralcalde12 / u8glib

Automatically exported from code.google.com/p/u8glib
Other
0 stars 0 forks source link

Eliminate unconditional placement of font data in AVR-specific sections under GCC #160

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
I see this is one of the changes in issue #134, but think it's worth calling 
out:

The unconditional assignment of font data to ".progmem.fontXXX" sections is a 
problem for any target that uses GCC but does not have .progmem sections in its 
linker script.  In particular, the mspgcc compiler will place these .progmem 
sections into RAM.

Although mspgcc could instead use ".rodata.fontXXX", when compiling with 20-bit 
support ".far.rodata.fontXXX" might be preferred.  It would be better to 
eliminate these annotations entirely and rely on -fdata-sections for non-AVR 
targets (and even for AVR if current compiler versions have been updated to 
correctly place read-only data).

Original issue reported on code.google.com by pabi...@gmail.com on 24 Apr 2013 at 9:59

GoogleCodeExporter commented 8 years ago 
Example of one way to approach this.

Original comment by pabi...@gmail.com on 24 Apr 2013 at 10:06

Attachments:

GoogleCodeExporter commented 8 years ago 
As of now, i need to live with the ".progmem.fontXXX" notation because of the 
Arduino Environment (old gcc release and g++ is in use).

Next step:
Make the ".progmem.fontXXX" notation depend on the target controller and the 
target environment.

Note on issue #134: i do not know how to proceed here. The msp430 release is 
based on u8glib 1.09, but u8glib has been independently moved to 1.12.
I do not have the time (and knowledge) to bring the clones back in sync. Any 
ideas?

Oliver

Original comment by olikr...@gmail.com on 24 Apr 2013 at 5:25

GoogleCodeExporter commented 8 years ago 
Another note: I can still implement small and understandable issues, like your 
three issues.

Original comment by olikr...@gmail.com on 24 Apr 2013 at 5:27

GoogleCodeExporter commented 8 years ago 
applied patch, fonts must be rebuild

Original comment by olikr...@gmail.com on 5 Jun 2013 at 8:07

GoogleCodeExporter commented 8 years ago

Original comment by olikr...@gmail.com on 5 Jun 2013 at 8:09

GoogleCodeExporter commented 8 years ago 
fonts are regenerated, this issue can be closed

Original comment by olikr...@gmail.com on 5 Jun 2013 at 8:27

GoogleCodeExporter commented 8 years ago

Original comment by olikr...@gmail.com on 5 Jun 2013 at 9:32