Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
SprinterSB
PostPosted: Mar 04, 2012 - 12:21 AM
Posting Freak


Joined: Dec 21, 2006
Posts: 1739
Location: Saar-Lor-Lux

wek wrote:
I have no idea what "PR number" is, although I've seen you using that a lot.
PR is short for "problem report".

Bugs, feature requeste etc. in GCC, binutils and other GNU projects have a PR number. For example, GCC's PR52261 is XMEGA enhancement for avr-gcc.

To go to the respective bugzilla page, simply append PR52261 to gcc.gnu.org for GCC PRs, or append to sourceware.org for binutils PRs, e.g.

http://sourceware.org/PR13410

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.

The default linker scripts are supplied by binutils.

I still don't understand what the problem with "(.progmem.gcc_sw_table+0x26): warning: internal error: out of range error" is about.

For example, if I locate .trampolines at 0x30000 everything works smooth and the code is correct (except EIND initialization which must me made by hand).

Size of arrays is limited by the C language and the ABI; even with 3-byte pointers all objects must be smaller than 32768 bytes.

And I am unsure if all that > 64k stuff is supposed to work out of the box. If I had to use such devices (I never used them and will never use them), I'd expect to write my own linker scripts, anyway.

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

You think the far stuff is still needed in times of named address space support?
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
wek
PostPosted: Mar 04, 2012 - 07:56 AM
Raving lunatic


Joined: Dec 16, 2005
Posts: 3218
Location: Bratislava, Slovakia

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" Wink - 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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
SprinterSB
PostPosted: Mar 04, 2012 - 01:34 PM
Posting Freak


Joined: Dec 21, 2006
Posts: 1739
Location: Saar-Lor-Lux

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 Razz 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<n> spaces and .progmem.data<n> 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...
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
clawson
PostPosted: Mar 04, 2012 - 03:31 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 71732
Location: (using avr-gcc in) Finchingfield, Essex, England

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.

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
S_i_v_s_k_o
PostPosted: Mar 04, 2012 - 04:08 PM
Newbie


Joined: Feb 27, 2012
Posts: 11


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.
Code:
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.
 
 View user's profile Send private message  
Reply with quote Back to top
clawson
PostPosted: Mar 04, 2012 - 04:38 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 71732
Location: (using avr-gcc in) Finchingfield, Essex, England

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.

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
wek
PostPosted: Mar 04, 2012 - 04:53 PM
Raving lunatic


Joined: Dec 16, 2005
Posts: 3218
Location: Bratislava, Slovakia

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.
Code:
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.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
SprinterSB
PostPosted: Mar 04, 2012 - 09:46 PM
Posting Freak


Joined: Dec 21, 2006
Posts: 1739
Location: Saar-Lor-Lux

All what you need is a costom linker script. Copy the default for avr6 from, say
Code:
./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.

_________________
avr-gcc NewsABIOptions4.8-WindowsInline Asm
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
SprinterSB
PostPosted: Mar 05, 2012 - 09:55 PM
Posting Freak


Joined: Dec 21, 2006
Posts: 1739
Location: Saar-Lor-Lux

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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
S_i_v_s_k_o
PostPosted: Jul 19, 2012 - 12:34 PM
Newbie


Joined: Feb 27, 2012
Posts: 11


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
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits