How to use progmem on 256kb

30 posts / 0 new
Last post
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
PR is short for "problem report".
[...]simply append PR52261 to gcc.gnu.org for GCC PRs, or append to sourceware.org for binutils PRs[...]
Ah, I see, thanks. I doubt this is common knowledge outside the gcc/binutils developer circles.

SprinterSB wrote:
Quote:
I've requested said changes in original post in https://savannah.nongnu.org/bugs/?26365 [...] I then posted an example modified linker script to that tracker item and explained the changes in the extensive post here I linked above.
As far as I can see it's bunch of changes for _far resp. _PF support for AVR-libc.
And what would you expect exactly from a feature request, and a writeup by a user who does not know how nor want to dig deeper?

SprinterSB wrote:
I still don't understand what the problem with "(.progmem.gcc_sw_table+0x26): warning: internal error: out of range error" is about.
I'd expect that the vast majority of the >64kW devices' users would need the huge flash for extensive data, and the code is less, sometime far less than 64kW - as is the case of our OP, too. Increasingly so in these days of cheap ARM devices with virtually unlimited address space. That voids all concerns with EIJMP-kind of stuff in the majority of cases, as long as the users know how to put the data high enough and how to use them. This is why I'd not put more effort into trampolines etc. and concentrate on methods and documentation on how to handle big constant data.

Actually, I even wasn't aware of the EIJMP-related problems at the time of writing that writeup, even if my code of the project involving 'M256x eventually did cross the 64kW boundary. It was just through trying to support those who posted about these problems here I realized this.

SprinterSB wrote:
In order to locate data in upper part of flack you could use avr-gcc 4.7 and its __flash1/2/3 but there is still still of home brew linker script for that because the default scripts know nothing about .progmem.data1/2/3

This puzzles me. You seem to blame me - who can't tell PR from "public relationships" ;-) - for not pushing through the proposed changes to binutils, yet you - an already established gcc developer - didn't do the very same thing?

SprinterSB wrote:
You think the far stuff is still needed in times of named address space support?
If completed to the point where it's easy to use by the mere users (which involves exhaustive and precise documentation), far/PF might get obsolete by then - but I don't see that coming into mainstream that soon. Please don't take this personally - you hardly can do more for this, but the support your work receives from the "integrators" apparently lags far behind your effort. And seing Atmel refocusing onto ARMs apparently in the belief that that would boost their sales to the skies, I don't see that support to come in the near future either.

JW

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

wek wrote:
SprinterSB wrote:
PR is short for "problem report" [...]simply append PR52261 to gcc.gnu.org for GCC PRs, or append to sourceware.org for binutils PRs[...]
Ah, I see, thanks. I doubt this is common knowledge outside the gcc/binutils developer circles.
You can use bugzilla/bug tracker of the respective project, of course, to go to the report or search for specific problems. But bugzilla is slooow...

wek wrote:
SprinterSB wrote:
Quote:
I've requested said changes in original post in https://savannah.nongnu.org/bugs/?26365 [...] I then posted an example modified linker script to that tracker item and explained the changes in the extensive post here I linked above.
As far as I can see it's bunch of changes for _far resp. _PF support for AVR-libc.
And what would you expect exactly from a feature request, and a writeup by a user who does not know how nor want to dig deeper?
If it's extension to binutils, I'd expect a feature request for binutils.

If a request is hidden between a bunch of other, technical unrelated requests it's not unlikely it's been overseen or no-one gave a hint that some parts of the request aim at a different project.

wek wrote:
SprinterSB wrote:
In order to locate data in upper part of flach you could use avr-gcc 4.7 and its __flash1/2/3 but there is still need of home brew linker script for that because the default scripts know nothing about .progmem.data1/2/3
You seem to blame me [...] for not pushing through the proposed changes to binutils, yet you - an already established gcc developer - didn't do the very same thing?
I am not a GCC developer. I am AVR hobby guy that is more focused at avr-gcc than at AVR at the moment. BTW, it's quite comfortable to have this second degree of freedom: If some code sequence is suboptimal, hack the compiler instead of the application :P So you can blame me for doing co-development of a hobby project and a hobby compiler, and for doing Atmels homework.

For the __flash spaces and .progmem.data sections: I don't think it would be any good to add them to the default linker scripts. This would assert a certain anatomy of the software, and all sorts of problems would arise with section overlaps, overflows etc. if the software did *not* fit that specific anatomy.

This as all documented:

What's missing is a similar section on RAMP*

And if a feature/extension is needed, I file a feature request for it. See for example

http://sourceware.org/PR13503

IMHO, the very problem is that developers grab some silicon, drop tons of code, drop tons of data, click a button and expect everything to work as if they programmed a PC with gigabytes of memory, and without even thinking a second about the implications made by a segmented Harvard architecture that only supports 16-bit pointers, without even thinking a second about what tools that click triggers, without ever having read a single like of documentation of that tools, etc.

If I started such a big project, I would not even expect for a single second that this works without juggling data and own sections by means of own linker script. And I am a *hobbyist*!

wek wrote:
SprinterSB wrote:
You think the far stuff is still needed in times of named address space support?
If completed to the point where it's easy to use by the mere users (which involves exhaustive and precise documentation), far/PF might get obsolete by then
It's easy to use. But many people confuse "easy to use" with "what the fuck is documentation?"

wek wrote:
And seeing Atmel refocusing onto ARMs apparently in the belief that that would boost their sales to the skies, [...]
I think they are right moving away from AVR for bolide designs.

Adding even more dreaded features at the upper bound in order to hack a limited design must end up with dead horses...

avrfreaks does not support Opera. Profile inactive.

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

Quote:

I doubt this is common knowledge outside the gcc/binutils developer circles.

I don't know. Anyone using any kindof Bugzilla like system will be familiar with the concept of PRs and CRs (Problem Reports and Change Requests). One being something that needs fixing and the other being an idea for new functionality.

 

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

Lets sume up for a bit, there are 3 bugs here:
1.
When the data in the array is manually placed at specified location in the flash it is being read from some segments wrong.
See the iss file attached, when im trying to read from my segments in 0x20000 the compile generates code that reads from 0x10000, but if i read from 0x30000 the compiler gets it right.

const  unsigned int Lys_tabel_data950[320][12] __attribute__ ((section (".lys950"))) 

pwm_kanal_1=pgm_read_word_far( 0x30000 + (uint32_t)&(Lys_tabel_data80[min_point][0]));// right

pwm_kanal_1=pgm_read_word_far( 0x20000 + (uint32_t)&Lys_tabel_data660[min_point][0]);  // FFFF 

2.
The minor bug in avr studio where your flash segment is multiplied with 2. see posts higher.

3.

The internal error when im storring variables with __pgmx

And if i had the option to change from AVR to ARM yes then i would have done that, but that is not an option.

Attachment(s): 

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

Quote:

The minor bug in avr studio where your flash segment is multiplied with 2. see posts higher.

That's not a bug - Atmel make Studio use word addressing as that's what they always use for flash in their datasheets. It is just a "percularity" of GCC that it uses byte adressing as a lowest common denominator that can apply to all architectures. So this word_addr X 2 = byte_addr thing has existed in AVR Studio right since it first statred interfacing with GCC.

 

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

S_i_v_s_k_o wrote:
1.
When the data in the array is manually placed at specified location in the flash it is being read from some segments wrong.
See the iss file attached, when im trying to read from my segments in 0x20000 the compile generates code that reads from 0x10000, but if i read from 0x30000 the compiler gets it right.

const  unsigned int Lys_tabel_data950[320][12] __attribute__ ((section (".lys950"))) 

pwm_kanal_1=pgm_read_word_far( 0x30000 + (uint32_t)&(Lys_tabel_data80[min_point][0]));// right

pwm_kanal_1=pgm_read_word_far( 0x20000 + (uint32_t)&Lys_tabel_data660[min_point][0]);  // FFFF 

This is caused by the compiler sign-extending the pointer when casting to uint32_t.

The compiler apparently treats pointers as signed int. While this is surprising, it appears to be perfectly legal according to C99 6.3.2.3#6.

You might want to cast the pointer twice, first to uint16_t and then to uint32_t, to avoid this.

JW

PS. You still can use the technique I described in the writeup and you dismissed in your previous post: apply Carlos Lamas's GET_FAR_ADDRESS() macro to the first member of the array and add the calculated offset of the needed member. This alleviates the need to manually locate the arrays and manually add the segment address.

If you don't know how to calculate the offset in a multidimensional array, or you don't want to calculate it for some reason, you can circumvent this problem by placing the array into a struct and taking offsetof() of that member (it's enough to typedef a type of same structure). This all could be hidden into a macro if needed.

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

All what you need is a costom linker script. Copy the default for avr6 from, say

./avr/lib/ldscripts/avr6.x

and arrange the sections according to your needs.

In particular, place .progmem* after .text* and you are done.

Then link with -Tyour-linker-script

That's it.

No hacks in the source.
No pointer mess.

avrfreaks does not support Opera. Profile inactive.

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

S_i_v_s_k_o wrote:
i still get "internal error: out of range error" to my array file
Filed a binutils bug for this one. If the default linker script from binutils is not changed to avoid the problem, there should be a descriptive error message at least:

http://sourceware.org/PR13812

avrfreaks does not support Opera. Profile inactive.

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

Ok i got it all to work now, also with studio 6.

in avr studio i have define the memory space for each variabel and the first part is the block off set, then to make it work i needed to double cast the adress like:

pgm_read_word_far( 0x30000 + (uint32_t)((uint16_t)&Lys_tabel_data80[min_point][0]));

Now it all works:-)
Thanks all for the help

Pages