The use of '__memx' - how can i resolve code issue?

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

Micro: Attiny104

Clock: 1 Mhz

Compiler: AVR 4.9.2

Atmel Studio 7: Ver7.0.1188

OS: Win7

 

I am currently trying to adapt some code to run on an ATtiny104.

 

This i am attempting to do by arranging for data to be stored in Program Memory (flash) in the form of a array, and during program execution for this data to be read from Program Memory.

 

I am using __flash  & __memx for the first time to achieve this.

 

However, the modified code is unable to compile successfully with the implementation of ‘__memx’.

 

Problem:

 

When passing an array address to the following function: 

 

        PlayMusic(const __memx int *pMusicNotes, uint8_t tempo)

 

the following error is raised by the compiler:  

 

Error: Pointer targeting address space ‘__memx’ must be const in function parameter ‘pMusicNotes’.

 

I cannot at the moment see the reasoning behind this error as the array which is being passed contains constant values.

 

Below i have included a sample of the code in question, which contains the main elements.

 

I believe i am applying the ‘__memx’ correctly, but some help in clarifying the issue and some pointers to a solution would be much appreciated…..

 

#include
#include

void PlayMusic(const __memx int *pMusicNotes, uint8_t tempo)
{
   int duration;
   int note;

   uint16_t delay = tempo * 1000;

   while((pMusicNotes))
   {
      note = *pMusicNotes;
      pMusicNotes++;

      duration = *pMusicNotes;
      pMusicNotes++;
   }
}


const __flash int octave[] = {c4, 8, d4, 8, e4, 8, MUSIC_END};


int main(void)
{
   InitMusic();

   while(1)
   {
      PlayMusic((octave), 40);        // an array "octave" being passed as an address
   }
}

 

- Jah

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

It's a question of whether the pointer is const or the thing it is pointing to is const.
.
Bit why _memx anyway? Are you trying to make a routine that is agnostic about whether the data is in flash or RAM? Otherwise why not simply __flash?

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

In PlayMusic, OP's pointer target is const __memx int\

'Tain't obvious why the pointer would have to be const.

If OP has described the situation correctly,

it looks like a compiler bug to me.

Moderation in all things. -- ancient proverb

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

I think you have things in the wrong order. Here's a parameter clipped from my code:

 

const uint16_t __memx * img

 

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

@Torby: Minimal test program that still displays the problem, for you to play around with while I do something completely different.. ;-)

 

void foo(const int __memx * pInt)
{
}

int main(void)
{
}

 

Output from compiler:

		Building file: .././main.c
		Invoking: AVR/GNU C Compiler : 5.4.0
		"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  
		   -x c -funsigned-char -funsigned-bitfields -DDEBUG  
		   -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.2.118\include"  
		   -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall 
		   -mmcu=attiny104 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.2.118\gcc\dev\attiny104"
		   -c -std=gnu99
		   -MD -MP -MF "main.d" -MT"main.d" -MT"main.o"  
		   -o "main.o" ".././main.c" 

C:\Users\johan\Documents\Atmel Studio\7.0\MySolution\avruser\Debug\Makefile(79,1): error: recipe for target 'main.o' failed

C:\Users\johan\Documents\Atmel Studio\7.0\MySolution\avruser\main.c(1,29): error: pointer targeting address space '__memx' must be const in function parameter 'pInt'
         void foo(const int __memx * pInt)
                                     ^

[slightly edited - I broke the compile command into several lines for readability. Marked the interesting lines blue.]

 

Toolchain:

C:\Users\johan\Documents>avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_1734) 5.4.0

 

Have fun!

 

Methinks skeeve is correct, it being a bug.. (Methinks clawson is giving good advice - change parameter to be __flash, rather than __memx.)

 

If you can fix the minimal test program, then that would be good/interesting.

 

If you cant fix it, then we have stronger indication of a bug and could perhaps produce an error report.

 

Would be thrilled to see Georg-Johann Ley pass by here.. ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

This compiles fine:

/*
 * TestMemx.c
 *
 * Created: 8/21/2017 2:50:28 PM
 * Author : User
 */ 

#include <avr/io.h>

void foo(const int __memx * pInt)
{


}

const __flash int F = 7 ;

int main(void)
{
	int R = 8 ;
	foo(&F);
	foo(&R);
    /* Replace with your application code */
    while (1) 
    {
    }
}

 

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

@Torby: I just tested that in Atmel Studio. I got the same error as with my minimal test above.

 

What version of avr-gcc are you using?

 

E.g. in Atmel Studio select Tools menu, Command prompt. On that prompt, do

avr-gcc --version

copy the output and post here.

 

As far as I know, I am running the toolchain that comes with Atmel Studio 7.0.1417 - see my post above for my avr-gcc version. If you're on an earlier version we might be looking at a regression in avr-gcc 5.4.0. (And you might be interested in knowing this if you rely on __memx - i.e. to avoid an upgrade right now.. ;-) )

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

Torby wrote:
This compiles fine:

JohanEkdahl wrote:
@Torby: I just tested that in Atmel Studio. I got the same error as with my minimal test above.

It depends on the selected MCU. It compiles fine for "normal" AVRs, but gives the error for the "new style" Tinys.

Stefan Ernst

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

Doh! Never thought of changing device built for.. Thanks sternst.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Has someone told Georg-Johann or has anyone raised a bug on the GCC Bugzilla about this? If not I fear little will happen.

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

Cliff,

I'm not friends with the GCC Bugzilla (at least wasn't last time I tried - didn't even understand their explanation of how to create an account - but I guess I'm stupid..).

I wasn't even sure all avr-gcc bugs should go into the generic GCC Bugzilla (I suppose that is what you're saying).

And AFAIK Georg-Johann does not take PMs.

I'm clueless as to how to progress.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Oh! A key piece of info there!

 

sternst wrote:

Torby wrote:
This compiles fine:

JohanEkdahl wrote:
@Torby: I just tested that in Atmel Studio. I got the same error as with my minimal test above.

It depends on the selected MCU. It compiles fine for "normal" AVRs, but gives the error for the "new style" Tinys.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

> "new style" Tinys.

 

These devices have a linear address space.  You don't need __flash or __memx or progemem at all and you can just use vanilla C without any RAM overhead.  Requirement is that you use a reasonable linker script that leaves .rodata in flash, see https://sourceware.org/PR20849

If your default linker script doesn't come with that obvious addition, you can augment them as indicated my the patch to PR20849 resp git diff.

 

avrfreaks does not support Opera. Profile inactive.

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

These devices have a linear address space.  You don't need __flash or __memx or progemem at all and you can just use vanilla C without any RAM overhead.  Requirement is that you use a reasonable linker script that leaves .rodata in flash, see https://sourceware.org/PR20849

Thanks for all the responses so far for this issue;

 

I have tried the suggestion by Torby

const uint16_t __memx * img

but still get the same problem as described in my initial post.

 

Clawson Replied:

 

Bit why _memx anyway? Are you trying to make a routine that is agnostic about whether the data is in flash or RAM? Otherwise why not simply __flash?

 

Ans: No, the whole point was to place all my array data into Program Memory to save RAM space. 

       I initially tried using _flash

void PlayMusic(const __flash int *pMusicNotes, uint8_t tempo)

      to begin with but the complier kept responding with the following error: 

 

Error: illegal opcode elpm for mcu avrtiny 

 

Hence, i went on to try _memx as a solution, but this too raised the issue described in the initial post.

 

SpinterSB Replied:  

 

These devices have a linear address space.  You don't need __flash or __memx or progemem at all and you can just use vanilla C without any RAM overhead.  Requirement is that you use a reasonable linker script that leaves .rodata in flash, see https://sourceware.org/PR20849

 

But i have no idea what to modify for this workaround, to prevent .rodata from being moved from Flash (if this is what is causing the problem)?

 

Any help?

- Jah

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

The thing to modify is the linker script, as per the Bugzilla item sbsprinter pointed to. Alas my PC is running its backup over night so I cant point to details right now. Tomorrow perhaps, if no-one else chimes in..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

This entire discussion reminds me of the debate 400 years ago concerning whether the earth moved around the sun or the sun moved around the earth.  Back then it was obvious that the sun moved around the earth, and that God made the earth the center of the universe.  Anyone who questioned this assumption was by ipso facto questioning God, committing blasphemy, and was put to death.  Nevertheless there were "irregularities".  Planets occasionally seemed to move backwards.   Huge amounts of scientific energy and research was expended to explain this.  Eventually with the invention of Calculus,  and a heliocentric model, everything just fell into place, and the orbits of the planets were able to be predicted to the point where we can now put an car on Mars.

 

The analogy here is not how __memx works and the endless discussion of how to use C++ on non-Von CPUs, but whether it is reasonable to actually use C or C++ on a microcontroller that has 1K of memory.  I believe that one should not.  The overhead is so high that any application devolves into an esoteric academic exercise of no utility or consequence.  In other words, it doesn't make any difference how C works on a Tiny104, because the tiny104 is just too tiny to use high-level languages for application development. 

 

You should be programming this device in assembly language.   In that case, you point the X, Y, or Z register pair at the beginning of the array and then read the array values using LPM or LDS instructions.  Write source code for a 1K microcontroller in assembler, and everything will just fall in place without all these retrograde complications.  PS: don't trust your first-born child to anyone would put TWO underscores before a variable name.  Everyone uses different editors and font displays, and trying to tell the difference between one stupid underscore and two of them together gets annoying really fast.

Last Edited: Tue. Aug 22, 2017 - 11:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

of no utility or consequence

To you.

 

You should be programming this device in assembly language

I'll inform the tens of thousands of embedded engineers and hobbyists using C for the t13, t104, etc.  They'll be pleased with your insight.  If only it had come sooner, it could have prevented any number of products and projects from seeing the light of day :)

 

PS: don't trust your first-born child to anyone would put TWO underscores before a variable name.  Everyone uses different editors and font displays, and trying to tell the difference between one stupid underscore and two of them together gets annoying really fast.

An excellent example of the rubbish you spew on a regular basis.  I think perhaps you should get your eyes checked? ;-)

 

Not even a 'variable'!

 

The C standard is very specific.  Here's what it has to say on the subject (section 7.1.3):

  • All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
  • All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.

(The section goes on to list specific identifiers and sets of identifiers reserved by certain standard headers.)

Since __flash and __memx are specific to the AVR backend of GCC, they are implementation-specific identifiers fully reserved by the implementation.  Identifiers with single leading undersores are typically used for library implementations (think _delay_ms).

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

You should be programming this device in assembly language.

Anyone else getting a whiff of:

 

http://2.bp.blogspot.com/_owDRpQ-h95Y/S6oPx_T-k8I/AAAAAAAAAYI/8uTqhS7ZV7g/s1600/Thomas+M+Cooley+pile.jpg

 

avruser wrote:
But i have no idea what to modify for this workaround, to prevent .rodata from being moved from Flash (if this is what is causing the problem)?

Anyway I fear you have missed the point that SprinterSB was making to you. In "traditional" AVRs the memory is Harvard so you have LD/ST to access data in RAM and LPM to read data from flash. In C code you need some mechanism to say "read from flash using LPM here". Traditionally you used PROGMEM (to say which data should be stored in flash alone) and then pgm_read_byte() (etc.) to get the compiler to emit LPM code to read it. Thanks to SprinterSB (Gerog-Johann) the avr-gcc compiler now has __flash that can be used to say "this data to be stored in flash alone" but there is a secondary effect in that when that data is later accessed the compiler knows it must use LPM to read it back - so pgm_read_*() functions are not needed any more.

 

All that was for "traditional" AVRs. But the Tiny104 is (apparently) different in that it does not need LPM. Both flash and RAM are accessible using LD. So __flash (or the more general __memx) is not the solution here. Georg-Johann already pointed you to the PR. From that you can get to :

 

https://sourceware.org/git/gitwe...

 

Now that is a change to be made in the "build tree" for GCC and binutils but what it's actually affecting is file that is ultimately created in <install>\avr\lib\ldscripts. There is a .x file there that will be used for Tiny104. You need to apply the change to the .x file for 104.

 

Any data that is "const" with initial values given should then locate to .rodata and, because of the linker script change, that will in turn be located in flash.

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

avruser wrote:
SpinterSB Replied: These devices have a linear address space. You don't need __flash or __memx or progemem at all and you can just use vanilla C without any RAM overhead. Requirement is that you use a reasonable linker script that leaves .rodata in flash, see https://sourceware.org/PR20849 But i have no idea what to modify for this workaround, to prevent .rodata from being moved from Flash (if this is what is causing the problem)?

If __memx or __flash is accepted by the compiler (v7+), then you are not compiling for avrtiny.  avrtiny will reject named address spaces.

 

error: address spaces are not supported for reduced Tiny devices

 

For older compiler versions, you will just get garbage, for example use of [E]LPM.

avrfreaks does not support Opera. Profile inactive.

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

The diff to the linker script looks as follows:

diff -ur ~/gnu/install/gcc-5/avr/lib/ldscripts/avrtiny.x ~/gnu/install/gcc-6/avr/lib/ldscripts/avrtiny.x
--- /home/georg/gnu/install/gcc-5/avr/lib/ldscripts/avrtiny.x   2016-07-12 10:23:05.496809920 +0200
+++ /home/georg/gnu/install/gcc-6/avr/lib/ldscripts/avrtiny.x   2017-05-18 17:34:39.999382388 +0200
@@ -10,6 +10,7 @@
 __FUSE_REGION_LENGTH__ = DEFINED(__FUSE_REGION_LENGTH__) ? __FUSE_REGION_LENGTH__ : 2;
 __LOCK_REGION_LENGTH__ = DEFINED(__LOCK_REGION_LENGTH__) ? __LOCK_REGION_LENGTH__ : 2;
 __SIGNATURE_REGION_LENGTH__ = DEFINED(__SIGNATURE_REGION_LENGTH__) ? __SIGNATURE_REGION_LENGTH__ : 4;
+__RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ? __RODATA_PM_OFFSET__ : 0x4000;
 MEMORY
 {
   text   (rx)   : ORIGIN = 0x0, LENGTH = __TEXT_REGION_LENGTH__
@@ -162,13 +163,17 @@
     KEEP (*(.fini0))
      _etext = . ;
   }  > text
+  .rodata  ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__    :
+  {
+    *(.rodata)
+     *(.rodata*)
+    *(.gnu.linkonce.r*)
+  } AT> text
   .data          :
   {
      PROVIDE (__data_start = .) ;
     *(.data)
      *(.data*)
-    *(.rodata)  /* We need to include .rodata here if gcc is used */
-     *(.rodata*) /* with -fdata-sections.  */
     *(.gnu.linkonce.d*)
     . = ALIGN(2);
      _edata = . ;
 }

Also notic that it's realm of Binutils, not the compiler (hence the versions in the diff command are misleading).  Default linker scripts are located in $install/avr/lib/ldscripts.

avrfreaks does not support Opera. Profile inactive.

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

Simonetta wrote:
This entire discussion reminds me of the debate 400 years ago [...]

 

That whole argument reminds me that it's neither the Sun moving around the Earth, or the other way around. It's both of them moving around a common center of gravity. Actually, it's not even as simple as that since other massive bodies are also involved. Actually, that's not the only truth either - the Sun and Earth moves in straight lines in a curved space. Now, the proponents of a multiverse theory...

 

And that reminds me of how weak an argument can be if non-fitting likenings are used.

 

In fact, one thing that the "adventures" of Galileo Galileo and his contemporaries (or Newton, or Einstein, or Bohr, Shrödinger, Linde, Hawking..) can teach us is to be wary of proclaiming one thing as the absolute truth, unless there is overwhelmingly compelling formal evidence of it. E.g. claiming that the only way to go about an ATtiny104 is with assembly language.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. Aug 23, 2017 - 11:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh! You can't because you don't have to. That makes sense!

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

Thanks again to all the responses;

 

SprinterSB Replied:  See #21

 

With the diff to the linker script and to what changes are necessary to linker file by the way “+” and “-“ .

 

I in turn located the file “avrtiny.x” on my installation of Atmel Studio.

 

C:\Program Files\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\lib\ldscripts

 

Hence, proceeded to make the necessary adjustments to a copy of the above file. 

 

Outcome: 

After reinstating the modified file and launching Atmel Studio, re-attempting to compile my code once more still resulted in the response obtained in #1

 

So in the event that i have incorrectly modified the file “avrtiny.x”. 

 

I have included a copy here in my post of the original. If you can find a moment to update it for me with the changes necessary, i will give it try once again to compile my code.

 

Thanks in advance…

Attachment(s): 

- Jah

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

Try this.

Attachment(s): 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

SprinterSB wrote:
If __memx or __flash is accepted by the compiler (v7+), then you are not compiling for avrtiny.

 

I can see why this might be very confusing for the OP. I have been using the toochain that comes with the latest Atmel Studio (7.0.1714), and avr-gcc reports itself as

C:\Users\johan\Documents>avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_1734) 5.4.0

So, the latest tool chain from Atmel is two major version behind GCCs head. (It is this 5.4.0 version that generates the error message quoted in several post, by several different posters, above.)

 

Since the vast majority of us has, is and will use a pre-built toolchain - historically e.g. the WinAVR build and currently the builds from Atmel - it is mostly of academic interest to the majority.

 

So, I'd like to start by asking: Can it somehow be confirmed that this was a bug in the 5.4.0 version? This is of more than archaeological interest to most of us since we're using that version of the  compiler. 

 

Second: What would be the relevant/best workaround using that version of the compiler.

 

Third: In general, regarding version of avr-gcc, I am under the impression that Atmel/Microchip still lags behind in pushing their patches upstream - making the Atmel-built toolchains the only reasonable to use for those that do not have the abilities to build a toolchain themselves. Am I wrong?

 

Fourth: If  I'm wrong, where do one get a "complete" collection of sources etc to build the "bleeding edge" tool chain?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Aug 24, 2017 - 05:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OT: has Atmel/Microchip release a more recent 8-bit toolchain for Linux?  Latest I can find is 3.5.4, with GCC 4.9.1. /OT

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Johan, it's not really a bug is it? It's simply the wrong expectation. Tiny104 users don't want to use LPM at all so should not invoke mechanisms to use it. Like a Von Neumann programmer (because that CPU kind of is) they should just apply const to put things in rodata then have the linker script arrange to position that in flash (only). The code will 'LD' and will read it.

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

> Second: What would be the relevant/best workaround using that version of the compiler.

 

As already said, address spaces + avrtiny will just result in garbage code.  Use an updated linker script and vanilla C as explained above.
 

avrfreaks does not support Opera. Profile inactive.

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

joeymorin wrote:
has Atmel/Microchip release a more recent 8-bit toolchain for Linux?  Latest I can find is 3.5.4, with GCC 4.9.1.[
3.6.0 is source code only for Linux though there is a build for macOS.

http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.0/

via

http://www.microchip.com/development-tools/atmel-studio-7/avr-and-arm-toolchains-(c-compilers)

 

"Dare to be naïve." - Buckminster Fuller

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

joeymorin Replied:  Try this:

 

Thanks joeymorin for supplying this.

 

Outcome: 

I replaced the file supplied in post #25, and after re-compiling my code once again, the compiled result still remained the same as that obtained in #1.

 

My GCC version is as follows: 

C:\Users\Dell>avr-gcc --version
avr-gcc (GCC) 5.3.0

Anyone, any further help with this linker file avrtiny.x.zip in post 

 

Thanks !!

- Jah

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

avruser wrote:
I replaced the file supplied in post #25, and after re-compiling my code once again, the compiled result still remained the same as that obtained in #1.
Apparently you still don't get the point.

Changing the linker script does NOT make __memx work, it makes __memx needless.

 

The solution is to change the linker script AND to remove every __memx and __flash from the code.

Stefan Ernst

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

But it's important to retain "const".

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

Too use own linker script "foo", all -T foo to the link command.
 

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB replied: 

 

Too use own linker script "foo", all -T foo to the link command.

 

Okay, taking on board the earlier comments, using a modified linker script...

 

Question: 

 

Can someone show me where within AtmelStudio how do i locate the command line to add " -T foo " to the link command being executed?

 

 - Location (of linker command line)

 - And an example of implementation, would help.

 

Now that my code has been modified as suggested in post #32.

 

 

 

 

 

- Jah

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

Project Properties.

Toolchain.

AVR/GNU Linker, Miscellaneous.

Other Linker Flags: Set the -T option in the text field.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

To be honest, this is one occasion I might be tempted to actually edit a "system file". Consider making the changes in core .x file that will be used for all projects with the chip so you won't have to do the -T thing each time.

 

I know the possible downside is if the toolchain gets updated you may lose the edit.

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

Hi,

 

Does anyone know in which version of avr-gcc __memx modifier was appeared first?

 

Thank you all!

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

It started around 4.6 I believe.

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

Thank you. I found this https://gcc.gnu.org/gcc-4.8/chan...

It seems __memx appeared since version 4.8.0 of AVR-GCC, but I'm not sure 100%.

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

The changelog you quote mentions __memx only w.r.t. static initialisers, not named address spaces in general.

 

In reality, named address spaces like __memx were added to GCC (and the AVR backend and other backends) in 4.7:

https://gcc.gnu.org/gcc-4.7/changes.html

https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Named-Address-Spaces.html

 

EDIT:

Support for named address spaces in general was added to GCC in 4.5:

https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Named-Address-Spaces.html

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Apr 5, 2020 - 05:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller