Problems after upgrading GCC compiler to 9.1.0

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


I've created a new flavor for the 9.1.0 GCC compiler and now when I compile I get errors such as those below:

 

 

Not sure why that is?

 

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

As always this Error List is misleading because of the order it chooses to list errors. When a build fails the only really important error is the first one (often fixing that fixes the next 500) so look at "Output" and find the very first failure and work on that.

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


So ATtiny816 is not supported?

Should I copy the same file from the older GCC folder?

 

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

Does the micro have "PORTA"? If it does then the chances are the project is being built for the wrong AVR. If it doesn't then there's your error right there!

 

EDIT: your previous thread about PROGMEM showed 816 and it does have PORTA. So if the error above says there is no PORTA then it suggests you may not be building for 816

Last Edited: Fri. Jul 12, 2019 - 01:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I need my eyes tested a previous line says "device type not defined". So the error IS that it does not know this is an 816.

 

The odd thing is that in AS7 I didn't think you could achieve this - the project is always set for some target and that always leads to some -mmcu being used.

 

Oh, wait a mo, is this about the device pack manager - so you have an up to date device pack that contains 816 ??

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

ATtiny816 was introduced in ATtiny_DFP 1.1.102 (2016-09-29).

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

The project compiled without any problem using GCC 5.4.0 and nothing else was changed other than the compiler.

 

avr-gcc options / flags from the project properties:

 

-x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"../examples/include" -I"../include" -I"../utils" -I"../utils/assembler" -I".." -I"../Config" -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\Atmel\ATtiny_DFP\1.3.229\include"  -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny816 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\Atmel\ATtiny_DFP\1.3.229\gcc\dev\attiny816" -c -std=gnu99 -MD -MP -MF "$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -MT"$(@:%.o=%.o)" 

Last Edited: Fri. Jul 12, 2019 - 03:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would stick with the Atmel built and approved 5.4.0 for now. No point trying an experimental 9.1 at this stage.

Last Edited: Fri. Jul 12, 2019 - 03:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I would stick with the Atmel built and approved 5.4.0 for now. No point trying an experimental 9.1 at this stage.

 

I was started to think the same thing. I would be happy with 5.6 or whatever compiler release had the __flash attribute support added to make the code more readable however I can not find a link to binaries of old releases.

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

5.4.0 most definitely has __flash support. As I say I think it started at 4.6 and ever issue since has had it.

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

5.4.0 supports __flash ... 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

OK so this takes me back to the original question (in a different forum).... let's say I want to use the __flash attribute but my strings are automatic variables so I make them static so this will compile. What about the pointer array, how I can pull of the same trick given it's also an automatic variable?

 

static const __flash char ESP_RST[] = "AT+RST\r\n";
static const __flash char ESP_ATE[] = "ATE1\r\n";
static const __flash char ESP_CWMODE[] = "AT+CWMODE=2\r\n";
static const __flash char ESP_CWSAP[] = "AT+CWSAP=\"HotSpot\",\"12345\",5,0\r\n";
static const __flash char ESP_CIPMUX[] = "AT+CIPMUX=0\r\n";
static const __flash char ESP_CIPSERVER[] = "AT+CIPSERVER=1,80\r\n";
static const __flash char ESP_CIFSR[] = "AT+CIFSR\r\n";
PGM_P ESP_CMNDS[7] PROGMEM = {
	ESP_RST,
	ESP_ATE,
	ESP_CWMODE,
	ESP_CWSAP,
	ESP_CIPMUX,
	ESP_CIPSERVER,
	ESP_CIFSR	
};

 

Last Edited: Fri. Jul 12, 2019 - 03:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PROGMEM and __flash are (by definition) static, and const. It might be that it worked with PROGMEM as it uses sections directly, however I would consider it an error to have automatics with PROGMEM (and __flash has stricter validation of this).

 

Sounds similar to the arguments that __flash has to be const, whereas progmem doesn't actually have to be (although, writing to it without SPM will of course do something completely different than intended).

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Last Edited: Fri. Jul 12, 2019 - 09:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This also seems to work when adding static, however what would I do for the array of pointers for the stings? Is it possible to "bypass" the global attribute requirement?

static const __flash char *ESP_CMNDS[] = {
	ESP_RST,
	ESP_ATE,
	ESP_CWMODE,
	ESP_CWSAP,
	ESP_CIPMUX,
	ESP_CIPSERVER,
	ESP_CIFSR
};

 

Last Edited: Fri. Jul 12, 2019 - 03:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why does it matter WHERE this const, fixed, flash based data is actually defined - the only important thing surely is that there's one copy of it in the flash?

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

clawson wrote:

Why does it matter WHERE this const, fixed, flash based data is actually defined - the only important thing surely is that there's one copy of it in the flash?

 

The top priority is of course to have this in flash and not take up RAM with constants. The reason this got "complex" is because I don't want this code to be in main as some of the compilation is using conditional directives and moving things around will break the sort of "encapsulation" of the libraries and will add even more ugly directives for selective compiling which I really want to avoid.

Last Edited: Fri. Jul 12, 2019 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't want to hijack this thread but does the compilers handle __flash as memory mapped, or does they still use LPM ?

One would hope that 9.1.0 would do it (it should make cleaner code with more than 1 pointer), and I would expect 5.4.0 to use LPM. 

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

I do not know... For PROGMEM there's no logic to access LPM data as LDI data + offset as far as I know.. But I might be wrong... 

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

slow_rider wrote:

So ATtiny816 is not supported?

Should I copy the same file from the older GCC folder?

 

You shouldn't have to copy, at least not that file. When I compile, AS7 generates something like:

 

"C:\avr-gcc\avr-gcc-9.1.0-x64-mingw\bin\avr-g++.exe" -funsigned-char -funsigned-bitfields  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\Atmel\ATmega_DFP\1.3.300\include" (...)

So, avr-gcc is executed from the 9.1.0 directory, but the include files come from a device pack thanks to the -I option.  TBH, I don't remember if AS7 does this automatically, or if I changed some kind of configuration...

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

There's no need for __flash / progmem variables to be global, the only requirement js that such variables reside in static storage (and are const). It makes obviously no sense to have an auto var which lives in registers or on the stack also to live in flash at the same time. You have to decide.
.
v8+ uses memory-mapping of .rodata for devices with linear address space (avrxmega3 and avrtiny). You can just drop __flash without performance loss on these device families. And __flash still implies LPM + .progmem of course.
.
__flash is supported since v4.7, cf. GCC release notes.

avrfreaks does not support Opera. Profile inactive.

Last Edited: Fri. Jul 12, 2019 - 09:39 PM