Help me tweak my 4.19 install

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

:? :roll: I'm trying AS4.19, again since I read that the USB bugs were fixed . I don't get why it's not saying "compiling..." like 4.18 did... I have latest Winavr .

1) Build output doesn't give me the "memory usage" type output and I can't remember/find what it is . It has something to do with avr-size . I thought it was --size-sort . Here's build output for 2 C file pjt. ( spi.c and fong_leds.c ) :

Build succeeded with 0 Warnings...
d-bitfields -fpack-struct -fshort-enums -MD -MP -MT Fong_LEDs.o -MF dep/Fong_LEDs.o.d  -c  ../Fong_LEDs.c

d-bitfields -fpack-struct -fshort-enums -MD -MP -MT spi.o -MF dep/spi.o.d  -c  ../../../../MY_LIBS/spi.c

avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  Fong_LEDs.elf Fong_LEDs.hex
avr-objdump -h -S Fong_LEDs.elf > Fong_LEDs.lss
Build succeeded with 0 Warnings...

2) I don't have ANY objects in "available link objects", IIRC didn't earlier versions add some objects in that field by default ( So I must have to add them myself. Don't think I had to in the past !) ? :roll: ( programmers always gotta be changin' @#$! )

Jerome

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Last Edited: Wed. Dec 7, 2011 - 09:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Those lines above cannot be complete surely? The lines should start "avr-gcc ..." not "d-bitfields ..."

Anyway I suspect you are suffering from the change in 4.19 that is documented here:

https://www.avrfreaks.net/index.p...

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

Cliff I thought it was weird looking, but I can't think of what I'm missing as far as setup . I have Studio pointing to avr-gcc.exe and make.exe. That's all there is in the build output... "Toolchain" is unchecked .

Edit: Lines with green dots won't copy, so here's a pic .

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Last Edited: Wed. Dec 7, 2011 - 09:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well the way Studio works is that it almost certainly uses _popen() to spawn make and then capture the stdout/stderr output that is produced. I've seen occasions on heavily loaded PCs where this doesn't manage to capture the entire output. The fact that it reports build succeeded without warnings seems to suggest that it might have worked despite what you have seen in that output. I guess you could always run avr-size on the .elf file in the output (.\default) folder if you want to know the size.

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

1) Concerning the link you gave me, it's not that , I'd already set the paths correctly . It's showing "avr-gcc..." in the build, but wouldn't copy ( I tried several times ) . What extension do I use so I can post a screenshot ?

Edit: I've found that *.png will work ( it tells me which are permitted ). I save the shot in office photo mgr. and then try to add attachment, but 'freaks just spins its wheels...

Quote:
I guess you could always run avr-size on the .elf file in the output (.\default) folder if you want to know the size.

2) Thanks, but I'd rather it do it as part of the build output. There's an option I can add to make the memory usage show up in the build, what is that option ?

Edit: I looked in Atmel's makefile and there's no

size: ${TARGET}
   @echo
   @avr-size -C --mcu=${MCU} ${TARGET}

section . Yet another thing I have to add myself ? :roll: :?

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Last Edited: Wed. Dec 7, 2011 - 08:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How curious, I'm using 4.19 and the Makefile I get includes:

## Build
all: $(TARGET) test.hex test.eep test.lss size
size: ${TARGET}
	@echo
	@avr-size -C --mcu=${MCU} ${TARGET}

It seems VERY curious if your auto-generated Makefile doesn't include this!

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

Quote:
It seems VERY curious if your auto-generated Makefile doesn't include this!
Your language is ALOT kinder than mine is about this !

Here's the entire makefile .

###############################################################################
# Makefile for the project Fong_LEDs
###############################################################################

## General Flags
PROJECT = Fong_LEDs
MCU = atmega644
TARGET = Fong_LEDs.elf
CC = avr-gcc

CPP = avr-g++

## Options common to compile, link and assembly rules
COMMON = -mmcu=$(MCU)

## Compile options common for all C compilation units.
CFLAGS = $(COMMON)
CFLAGS += -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sections      -DF_CPU=1000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d 

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += $(CFLAGS)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS += -Wl,--relax -Wl,--gc-sections  -Wl,-Map=Fong_LEDs.map


## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom -R .fuse -R .lock -R .signature

HEX_EEPROM_FLAGS = -j .eeprom
HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load"
HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0 --no-change-warnings


## Include Directories
INCLUDES = -I"C:\Program Files\Atmel\Avr Projects 2\Megas\mega 644\Fong_LEDs\..\..\..\MY_Includes" 

## Library Directories
LIBDIRS = -L"C:\Program Files\Atmel\Avr Projects 2\MY_LIBS" 

## Libraries
LIBS = -lm 

## Objects that must be built in order to link
OBJECTS = Fong_LEDs.o spi.o 

## Objects explicitly added by the user
LINKONLYOBJECTS = 

## Build
all: $(TARGET) Fong_LEDs.hex Fong_LEDs.eep Fong_LEDs.lss## Compile
Fong_LEDs.o: ../Fong_LEDs.c
	$(CC) $(INCLUDES) $(CFLAGS) -c  $<

spi.o: ../../../../MY_LIBS/spi.c
	$(CC) $(INCLUDES) $(CFLAGS) -c  $<

##Link
$(TARGET): $(OBJECTS)
	 $(CC) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)

%.hex: $(TARGET)
	avr-objcopy -O ihex $(HEX_FLASH_FLAGS)  $< $@

%.eep: $(TARGET)
	-avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@ || exit 0

%.lss: $(TARGET)
	avr-objdump -h -S $< > $@

## Clean target
.PHONY: clean
clean:
	-rm -rf $(OBJECTS) Fong_LEDs.elf dep/* Fong_LEDs.hex Fong_LEDs.eep Fong_LEDs.lss Fong_LEDs.map


## Other dependencies
-include $(shell mkdir dep 2>NUL) $(wildcard dep/*)

Here's the build shot .

Attachment(s): 

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Here's the path setup .

Attachment(s): 

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Your not playing the game - the text in your first post does not match that in the setup.jpg picture?!?

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

Yup, Cliff. And I can't understand why a screen dump (setup.jpg) was used when the purpose seems to be to show the build output. The net effect is that we can not see complete lines in the build output. A mark-copy-paste would have been better there, Indy.

Nevertheless, if the makefile quoted above is the one that 4.19 generated for building this project, then it is clearly missing any invocation of avr-size.

OTOH, this looks strange:

.
.
.
## Build
all: $(TARGET) Fong_LEDs.hex Fong_LEDs.eep Fong_LEDs.lss## Compile
Fong_LEDs.o: ../Fong_LEDs.c
   $(CC) $(INCLUDES) $(CFLAGS) -c  $< 
.
.
.

Look at the all: rule. What is that ## Compile comment doing at the end of the line? It should be on a line of its own. Looks like something/someone (errr... Indy :wink:) edited something here...

First: Start by making sure that the project does not have "Use external makefile" set.

Second: Perhaps try to delete Makefile and rebuild. Studio should generate a new Makefile IIRC.

EDIT: Slight correction: AVR Studio 4 (in my case 4.18.715) recreates Makefile on every build.

EDIT2: In fact, the all: rule in my 4.18 test has the size prerequisite right at that spot where the odd comment is in Indys Makefile above..

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. Dec 7, 2011 - 10:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Your not playing the game - the text in your first post does not match that in the setup.jpg picture?!?
I'm playing but the system isn't ! The 1st post, IS a copy/paste . But the "avr-gcc" lines won't copy ( other lines will highlight in blue, but not the missing ones . That's why I tried the screenshot

Johan, it MUST have come like that, I didn't touch it . I don't know enough about makefiles to mess with anything . The only I did try was copy/paste the avr-size stuff into the makefile just before clean...It didn't save it even though I hit the save-all button .

Edit: OK ! I couldn't copy the entire field because I was starting the h.light box at lower right corner in the build window ( just after "succeeded with 0 warnings..." I just tried it starting further to the right in lower corner and then it works too ). I just tried doing it from upper right corner and that worked !

Build started 7.12.2011 at 14:07:36
avr-gcc -I"C:\Program Files\Atmel\Avr Projects 2\Megas\mega 644\Fong_LEDs\..\..\..\MY_Includes"  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sections                                           -DF_CPU=10
00000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT Fong_LEDs.o -MF dep/Fong_LEDs.o.d  -c  ../Fong_LEDs.c

avr-gcc -I"C:\Program Files\Atmel\Avr Projects 2\Megas\mega 644\Fong_LEDs\..\..\..\MY_Includes"  -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99 -fno-inline-small-functions -ffunction-sections -fdata-sections                                           -DF_CPU=10
00000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT spi.o -MF dep/spi.o.d  -c  ../../../../MY_LIBS/spi.c

avr-gcc -mmcu=atmega644 -Wl,--relax  -Wl,--gc-sections -Wl,-Map=Fong_LEDs.map Fong_LEDs.o spi.o   -L"C:\Program Files\Atmel\Avr Projects 2\MY_LIBS"  -lm  -o Fong_LEDs.elf

avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  Fong_LEDs.elf Fong_LEDs.hex

avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Fong_LEDs.elf Fong_LEDs.eep || exit 0
avr-objdump -h -S Fong_LEDs.elf > Fong_LEDs.lss

Build succeeded with 0 Warnings...

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Quote:

Johan, it MUST have come like that, I didn't touch it .

OK, but again:

Delete Makefile
Rebuild
Check that the newly generated Makefile has a current timestamp
If the newly generated MAkefile is messed up in the same way then something weird is really going on.

And double-check that the project isn't set to use an external makefile.

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

Sorry about that ! I deleted, hit rebuild all and no change ( current time-stamp though ), INCLUDING the odd line !? I'm using default Makefile ( ext. Makefile unchecked ) . :x I will try to download 4.19 again and see if that gives me joy .

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

I suspect it is a bug in 4.19. Here have two people the exact same problem (German forum):
http://www.mikrocontroller.net/topic/234736

"Use AVR Toolchain" checked -> Makefile looks ok
"Use AVR Toolchain" unchecked -> whole "size" part is missing in the Makefile

Stefan Ernst

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

Thanks for that Stefan . Neither one of those posters found a solution using Winavr, I bet ! The ONLY reason I'm ding-alingin' around with this in the 1st place is so I can go buck-wild with my new Xmega32( builtin USB-ready ) chip . I can live with doing the memory usage the way Clawson said ( I guess there's no way to automate it ? ) , the odd placed line in Makefile is just a comment anyway... I have no other (Windoze) options ?!! Bogus, Atmel, BOGUS ! :x

Edit: 1 bit of good news is my 1st home-made Xmega32A4U board's signature is being read by 4.19 . :)
This is offset by the BAD NEWS that this MCU is ONLY supported by the assembler ! Just found out in the build attempt . :shock:

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

What makes people delete Studio 4.18 files from their system? :roll: I still have V3.56 and backups of Studio V4.12 and up to V4.18, all the versions I have used.

I will feel REALLY sorry if I have to abbandon AVRs because of their LOUSY IDEs. :evil:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I wrote:
The ONLY reason I'm ding-alingin' around with this in the 1st place is so I can go buck-wild with my new Xmega32( builtin USB-ready ) chip .

I agree with your thinking on this, that's why I have a few copies of previous studios including 4.18 and its SPs ! But the Xmega32A4U's calling me ! :mrgreen:

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Quote:
Xmega32A4U's calling me !
Oh darn, I can't use that chip, what a shame. :)
Maybe I'll end up using someone else's chip rather than put up with Studio's nonsense if I need USB. :evil:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

JS wrote:
Maybe I'll end up using someone else's chip rather than put up with Studio's nonsense if I need USB.
Yeah, oh well for the USB. Back to Studio 4.18 for now and I'll just compile for a Xmega32A4 and load THAT to the thing ( so far so good with that ) ! I can at least play with the MCU compatible stuff that's allegedly fixed !

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1