avr-gcc never ending problems with pgmspace

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Long time ago I was involved in a project using AT8535 (replaced later by ATmega32) and avr-gcc. Now I was asked to do some upgrades. I loaded a new version of avr-gcc and had a thousands of warnings after recompiling an old code (no errors or warnings before).
All warnings are related to pgmspace. It the worst thing in avr-gcc and not to be seen in any other port of gcc.
Why the good people, who created avr-gcc do not fix it once for good ?
Why don't use const. like everyone else instead of all PGM junk ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Janek,

Don't complain, your company is too cheap to buy a compiler. Who's "everyone else" what are you talking about ? There are numerous people on this GCC forum that volunteered (not paid) their time to help. This PGM junk you're talking about must be making money for your company, otherwise you would be using another compiler by now (Oh I forgot your company is too cheap to buy a compiler).

Sonny

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

janek wrote:
Why the good people, who created avr-gcc do not fix it once for good ?

Because of the lack of volunteers. The way to fix it is to fix it in GCC not avr-libc, and fixing it in GCC is not trivial.

janek wrote:

Why don't use const. like everyone else instead of all PGM junk ?

Because using const in this manner goes against the C Standard. Unfortunately the C Standard doesn't yet, say anything about how to handle multiple address spaces such as in a Harvard Architecture chip (as the AVR is). So currently, any compiler vendor is free to do anything they want about it. However, overloading the meaning of the const keyword is generally not a good idea. There are drafts of documentation about that will correct the C Standard and will provide a way to handle multiple address spaces, but it has to go through the standards process.

But if you prefer other compiler's methods you're always free to choose and pay for those products.

So why don't you say what your problem actually is, instead of complaining about it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Because using const in this manner goes against the C Standard.

How?? Const data is not supposed to be modified later on, how does this not fit with the usage of program memory for data??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>> Because using const in this manner goes against the C Standard.

> ?? Const data is not supposed to be modified later on, how does this
> not fit with the usage of program memory for data??

(Your question mark key is bouncing. Better replace it.)

If you abuse `const' to force constant data into a different memory
space in a Harvard machine, you make the data declared by it
incompatible with standard functions, for example strcpy(). (IMHO,
it's thus not even enabled by default on compilers like IAR.)

The correct solution is to implement multiple memory spaces that each
get their own memory space identification. There does exist a
standards proposal for it, but so far, it has not been implemented in
GCC. (Svein Seldal volunteered to implement something based on that
proposal, but don't hold your breath until he might be ready doing
that.) All the main targets of GCC (which naturally do get the most
volunteer's time being spent) are von-Neumann machines, so they do not
suffer from that problem. On a von-Neumann machine, it's perfectly
valid to use `const' as an indication to place the data in ROM, as
they do not live in a different memory space there, so they are still
compatible with standard functions. See the MSP430 port of GCC for an
example that is roughly comparable with the AVR port.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would agree that the pgmspace macros are a bit of a hack. A true native AVR cross compilier might treat all constants as being program space constants and generate the required code to access them as such. Extending this code generation would also allow putting structures into program space and allow you to access them as easily as data space structures.

But AVR-GCC is NOT a native avr cross compilier, it is a von-neuman compilier modified to cross compile code for a havard class cpu. It's behavior for constants is reasonable, it DOES store them in program space in the init section, and copies them to data space. Acessing data from data space is more efficient than the program space method, though it DOES eat up sram. (If you are using a mega64/128 with external sram this isn't
a big issue unless we are talking HUGE constant arrays)

By clever use of pointers and casting (ugly?) you CAN access const structures in pgmspace. Your code will end up being non-portable to a commerical AVR c compilier perhaps.

The bottom line is that AVR-GCC is a good low cost (I didn't say no cost because
your time is worth something and therefore will be an expenseto port existing code to compile under AVR-GCC) development tool, though perhaps a bit non-standard.

(It's not that the bear can dance well, it's that it can dance at all)