Compile AVR code from windows (and Raspberian) command line

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

I've been using Atmel Studio for so long I forgot how to do this.  I'm trying to re-learn how to compile AVR code from the windows command line.  I remember using mfile, the make file generator that comes with WINAVR and it was pretty simple, but that's about it.  The reason that I am asking is that I am trying to figure out how to turn a Raspberry PI into an AVR compiling and programming station.  I've found a ton of tutorials on programming an AVR with the PI, but very little on actual code compilation.  Has anyone done this or have some links that might point me in the right direction?  

 

Edited title to more accurately reflect the goal of compiling AVR code in Raspberian

Last Edited: Wed. Nov 8, 2017 - 06:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You want to
- Locate the GCC documentation (for reference, at least)
- Possibly look at the Mfile template makefile (but if you don't know Make it might confuse more than help).
- If you have Atmel Studio you can study how it runs the toolchain

A minimal build can be as simple as a single AVR-GCC command (compile and link single source file in one go) followed by a OBJCOPY to convert the ELF from the linker to a HEX to use for programming the flash of an AVR.

For larger projects involving several source files it's one AVR-GCC per source file to create object files, one single final AVR-GCC to link them all together and then the OBJCOPY.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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 is what I use:

 

@echo off
if exist output.txt del output.txt
if exist output.txt echo unable to delete output.txt
if exist output.txt pause
atmelstudio autoprog.atsln /out output.txt /build release
type output.txt
del output.txt

 

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

and Atmel Studio invokes MSBuild.

Atmel Studio

Build and Run Options

http://www.atmel.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-FF965275-375D-42EE-9D87-4725D0BFAAE6

...

MSBuild project build output verbosity

Sets the verbosity level for the build output. For more information, see the /verbosity switch in MSBuild Command Line Reference.

MSBuild project build log file verbosity

Sets the verbosity level for the build log file. For more information, see the /verbosity switch in MSBuild Command Line Reference.

Parent topic: Project Options

Microsoft

Developer Network

MSBuild Command-Line Reference

Visual Studio 2015

https://msdn.microsoft.com/en-us/library/ms164311.aspx

...

https://msdn.microsoft.com/en-us/library/ms164311.aspx#Anchor_0

Syntax

MSBuild.exe [Switches] [ProjectFile]  

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

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

@alank2 & @gchapman: The OP is aiming for a build system on a Raspberry Pi. How will commands for running Atmel Studio, a Windows/.NET-only software, help this poster?

 

Are you suggesting Atmel Studio (or just MSBUILD) on Wine on Raspbian on a memory-challenged machine? (No, of-course not.)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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: Sun. Nov 5, 2017 - 05:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To be fair, the OP did write "Compile AVR code from windows command line". But I agree it seems inconsisten with the rest of the post...

/Jakob Selbing

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

AKnick wrote:
I remember using mfile, the make file generator that comes with WINAVR ...
SCons may be an alternative.

AKnick wrote:
The reason that I am asking is that I am trying to figure out how to turn a Raspberry PI into an AVR compiling and programming station.
PlatformIO has SCons and is a Python install package in ARM Linux.

 


SCons: A software construction tool

http://scons.org/

...

 

What makes SCons better?

  • ...
  • Reliable, automatic dependency analysis built-in for C, C++ and Fortran--no more "make depend" or "make clean" to get all of the dependencies. Dependency analysis is easily extensible through user-defined dependency Scanners for other languages or file types.
  • ...

http://docs.platformio.org/en/latest/platforms/creating_platform.html#packages

...

tool-scons SCons software construction tool

...

http://docs.platformio.org/en/latest/installation.html

...

PlatformIO Core is written in Python 2.7 and works on Windows, macOS, Linux, FreeBSD and ARM-based credit-card sized computers (Raspberry Pi, BeagleBone, CubieBoard, Samsung ARTIK, etc.).

...

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

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

Here's what the Mfile makefile template does when building a hex from a single .c source file named filename.c :

 

Compile .c source file to a .o object file

avr-gcc -c -mmcu=atmega128 -I. -gstabs -Os -Wall -Wstrict-prototypes -std=gnu99  filename.c -o filename.o 

Link .o object file, creating an ELF file

avr-gcc -mmcu=atmega128 -I. -gstabs -Os -Wall -Wstrict-prototypes -std=gnu99 filename.o --output filename.elf -lm

Extract executable code from the ELF into a Intel Hex file:

avr-objcopy -O ihex -R .eeprom filename.elf filename.hex

 

If your project consists of several source files then you need one compilation step for each of them (i.e. filename1.c -> filename1.o, filename2.c -> filename2.o, filename3.c -> filename3.o ...) . Then all those object files get linked together in one go:

 

avr-gcc -mmcu=atmega128 -I. -gstabs -Os -Wall -Wstrict-prototypes -std=gnu99 filename1.o filename2.o filename3.o --output filename.elf -lm

and then you do the ELF-to-HEX step as above.

 

There are a lot of options that you can pass to the compiler-linker tool chain, like different optimization options, linking with different libraries for different levels of floating-point support etc.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

Thanks for all the replies.  I was able to use mfile to generate a template and go from there, single file worked just fine.  My ultimate goal is to use the RPI, but I wanted to do it form windows first because I can remember doing that in the past.  Now I just need to expand upon that base to handle multiple files.  A little more reading and experimenting and I'll get there.

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

Wine on Raspbian

 

Well, wine works as redirecting system calls and keeping instructions. Rapsbian is for a given ARM, not for x86 -> wine cannot work on RPi... (exception I found -and did not dare to try - in https://eltechs.com/run-wine-on-... )

 

mfiles are very simple to adapt (I use it, once adapted ... for my PC).

 

GNU linux command line  (I always use it, either from RPi /nanopi or with cygwin) is more comfortable than windows one....

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

I spent about 10 hours reading the GNU Make manual, Atmel's AVR Libc Reference Manual, Toolchain settings in AS7, and dissecting the mfile template.  My goal was to strip out a lot of things from the mfile template, because I either want to do them with another file (AVRDUDE programming), am only using C source, and I admittedly don't understand all of the manipulation that is going on with lists in the mfile template.  

 

I did scrap the windows compilation piece because AS7 is awesome and compiling simple AVR blink.c was super easy from the Linux command line.  Here is what I have for a reduced makefile so far (just a note I am adding the printf libraries because most of my projects use it, clearly a blinking LED will not):

 

#----------------------------------------------------------------------------
# AVR make file
#based on the mfile template
#just trying to learn makefile syntax
#----------------------------------------------------------------------------

# MCU name
MCU = atmega1284p

# Processor Frequency
F_CPU = 16000000

# Output format. (can be srec, ihex, binary)
FORMAT = ihex

# C Source files
SRC = blinker.c

# Target file name (without extension).
TARGET = YourCompiledThing

# Object files directory
#     To put object files in current directory, use a dot (.), do NOT make
#     this an empty or blank macro!
OBJDIR = .

# Optimization level, can be [0, 1, 2, 3, s, g].
#     0 = turn off optimization. s = optimize for size.
OPT = 1

# Debugging level, can be [0, 1, 2, 3]
DEBUG = 1

# Compiler flag to set the C Standard level.
#     gnu99 = c99 plus GCC extensions
CSTANDARD = -std=gnu99

# Place -D or -U options here for C sources
CDEFS = -DF_CPU=$(F_CPU)UL

#---------------- Compiler Options C ----------------
CFLAGS = -g$(DEBUG) 
CFLAGS += $(CDEFS)
CFLAGS += -O$(OPT)
CFLAGS += -funsigned-char
CFLAGS += -funsigned-bitfields
CFLAGS += -fpack-struct
CFLAGS += -fshort-enums
CFLAGS += -Wall
CFLAGS += -Wstrict-prototypes
CFLAGS += -Wa,-adhlns=$(<:%.c=$(OBJDIR)/%.lst)
CFLAGS += $(CSTANDARD)

ALL_CFLAGS = -mmcu=$(MCU) $(CFLAGS)
#---------------- Library Options ----------------
# Minimalistic printf version
PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min

# Floating point printf version (requires MATH_LIB = -lm below)
PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt

# If this is left blank, then it will use the Standard printf version.
PRINTF_LIB = $(PRINTF_LIB_FLOAT)
#PRINTF_LIB = $(PRINTF_LIB_MIN)
#PRINTF_LIB = $(PRINTF_LIB_FLOAT)

MATH_LIB = -lm

#---------------- Linker Options ----------------
#  -Wl,...:     tell GCC to pass this to linker.
#    -Map:      create map file
#    --cref:    add cross reference to  map file
LDFLAGS = -Wl,-Map=$(TARGET).map,--cref
LDFLAGS += $(PRINTF_LIB) $(MATH_LIB)

#============================================================================
# Define programs
SHELL = sh
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
SIZE = avr-size
AR = avr-ar rcs
NM = avr-nm
AVRDUDE = avrdude
REMOVE = rm -f
REMOVEDIR = rm -rf
COPY = cp
WINSHELL = cmd

# Compiler flags to generate dependency files.
GENDEPFLAGS = -MMD -MP -MF .dep/$(@F).d


# Combine all necessary flags and optional flags.
# Add target processor to flags.
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)

# Define all object files.
OBJ = $(SRC:%.c=$(OBJDIR)/%.o)

# Define all listing files.
LST = $(SRC:%.c=$(OBJDIR)/%.lst)

# Compile: create object files from C source files.
%.o : %.c
	@echo
	@echo $(MSG_COMPILING) $<
	$(CC) -c $(ALL_CFLAGS) $< -o $@ 
	
# Link: create ELF output file from object files.
.SECONDARY : $(TARGET).elf
.PRECIOUS : $(OBJ)
%.elf: $(OBJ)
	@echo
	@echo $(MSG_LINKING) $@
	$(CC) $(ALL_CFLAGS) $^ --output $@ $(LDFLAGS)
	
	# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
	@echo
	@echo $(MSG_FLASH) $@
	$(OBJCOPY) -O $(FORMAT) -R .eeprom -R .fuse -R .lock $< $@

# Target: clean project.
clean: begin clean_list end

clean_list :
	@echo
	@echo $(MSG_CLEANING)
	$(REMOVE) $(TARGET).hex
	$(REMOVE) $(TARGET).elf
	$(REMOVE) $(SRC:%.c=$(OBJDIR)/%.o)
	$(REMOVE) $(SRC:%.c=$(OBJDIR)/%.lst)
	$(REMOVEDIR) .dep

I have a couple of questions:

 

1.) CFLAGS += -Wa,-adhlns=$(<:%.c=$(OBJDIR)/%.lst)

I don't understand this rule text -adhlns, it looks like it is going to create .lst file in the object directory for ever .c file.  And I must not be getting this, because the following statement would be redundant if my understanding was correct:

 

# Define all listing files.
LST = $(SRC:%.c=$(OBJDIR)/%.lst)

 

When I do command line compilation, there are no .lst files.  What are these and why do I need them?

 

2.) Is there any disadvantage to only generating .hex?  This is all I have done in the past even in AS7, just because that is what I learned, but I have no idea why.

 

3.) When creating the .hex file, the line below will create the .hex without overwritting the eeprom, fuse, and lock bits in the AVR correct?

$(OBJCOPY) -O $(FORMAT) -R .eeprom -R .fuse -R .lock $< $@

 

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

AKnick wrote:
1.) CFLAGS += -Wa,-adhlns=$(<:%.c=$(OBJDIR)/%.lst) I don't understand this rule text -adhlns, it looks like it is going to create .lst file in the object directory for ever .c file.

The -Wa is used to send options to the assembler. I believe (might be wrong...) that this only holds for assembler source files passed to the compiler (filetype .S) (not assembler generated by the compiler as an intermediate step, filetype .s). The LST files are simply listings from assembly files, with some extra info (controlled by the -a options. See the GNU Assembler Manual for the details.

 

If you never intend to have projects with .S asssembler files then I believe you can safely  remove the whole 

CFLAGS += -Wa,-adhlns=$(<:%.c=$(OBJDIR)/%.lst)

shebang, and everything else involving LST files. 

 

AKnick wrote:
3.) When creating the .hex file, the line below will create the .hex without overwritting the eeprom, fuse, and lock bits in the AVR correct? $(OBJCOPY) -O $(FORMAT) -R .eeprom -R .fuse -R .lock $< $@

Correct. (The -R option is for "Remove").

 

AKnick wrote:
I spent about 10 hours reading the GNU Make manual, Atmel's AVR Libc Reference Manual, Toolchain settings in AS7, and dissecting the mfile template.

That is a lot of ground covered in 10 hours. Impressive! Gold star for actually wanting to read documentation!

 


 

There might be  some things that has bee nadded to the (avr-)gcc tool chain lately(ish) that are not covered/handled by the Mfile makefile template. "Relax optimizations" come to mind.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

Well I got home and tried that makefile on my Raspberry Pi and no luck.  It's missing some important things that I didn't see due to the text highlighting on my editor.  I did a little more digging and merged the old mfile template with a new/revised template that I found on GitHub.  I simplified it such that it only allows for C source files and will only generate a .hex output file.  I found this version of the makefile much easier to read and have tested it working on my distribution of Raspberian, the contents are below if anyone is curious.

 

Reading the documentation certainly cleared a lot of things up, thanks to everyone who helped out.  I really stoked to be able to use the PI as my sole AVR developing and programming station.  

 

# Hey Emacs, this is a -*- makefile -*-
#----------------------------------------------------------------------------
# AVR-GCC Makefile template, derived from the WinAVR template (public domain)
#
# ---------------------------------------------------------------------------
# On command line:
#
# make all = Make .hex.
#
# make clean = Clean out built project files.
#
# To rebuild project do "make clean" then "make all".
# ---------------------------------------------------------------------------


# MCU name
MCU = atmega1284p

# CPU speed
F_CPU = 16000000

# Output format. (can be srec, ihex, binary)
FORMAT = ihex

# Target file name (without extension).
TARGET = YourCompiledThing

SRC = blinker.c

# Optimization level, can be [0, 1, 2, 3, s, g].
#     0 = turn off optimization. s = optimize for size.
OPT = 1

# Name of this Makefile (used for "make depend").
MAKEFILE = Makefile

# Debugging format.
# Native formats for AVR-GCC's -g are stabs [default], or dwarf-2.
# AVR (extended) COFF requires stabs, plus an avr-objcopy run.
DEBUG = stabs

# Compiler flag to set the C Standard level.
# c89   - "ANSI" C
# gnu89 - c89 plus GCC extensions
# c99   - ISO C99 standard (not yet fully implemented)
# gnu99 - c99 plus GCC extensions
CSTANDARD = -std=gnu99

# Place -D or -U options here for C sources
CDEFS = -DF_CPU=$(F_CPU)UL

# Place -I options here
CINCS =


CDEBUG = -g$(DEBUG)
CWARN = -Wall -Wstrict-prototypes
CTUNING = -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
#CEXTRA = -Wa,-adhlns=$(<:.c=.lst)
CFLAGS = $(CDEBUG) $(CDEFS) $(CINCS) -O$(OPT) $(CWARN) $(CSTANDARD) $(CEXTRA)

#Additional libraries.

# Minimalistic printf version
PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min

# Floating point printf version (requires MATH_LIB = -lm below)
PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt

PRINTF_LIB = $(PRINTF_LIB_FLOAT)

# Minimalistic scanf version
SCANF_LIB_MIN = -Wl,-u,vfscanf -lscanf_min

# Floating point + %[ scanf version (requires MATH_LIB = -lm below)
SCANF_LIB_FLOAT = -Wl,-u,vfscanf -lscanf_flt

SCANF_LIB =

MATH_LIB = -lm


#LDMAP = $(LDFLAGS) -Wl,-Map=$(TARGET).map,--cref
LDFLAGS = $(LDMAP) $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)

#============================================================================
# Define programs
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
SIZE = avr-size
NM = avr-nm
AVRDUDE = avrdude
REMOVE = rm -f
MV = mv -f

# Define all object files.
OBJ = $(SRC:.c=.o) $(ASRC:.S=.o)

# Define all listing files.
LST = $(ASRC:.S=.lst) $(SRC:.c=.lst)

# Combine all necessary flags and optional flags.
# Add target processor to flags.
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS)

# Default target.
all: build

build: elf hex 

elf: $(TARGET).elf
hex: $(TARGET).hex


.SUFFIXES: .elf .hex .eep .lss .sym

.elf.hex:
	$(OBJCOPY) -O $(FORMAT) -R .eeprom -R .fuse -R .lock $< $@


# Link: create ELF output file from object files.
$(TARGET).elf: $(OBJ)
	$(CC) $(ALL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS)


# Compile: create object files from C source files.
.c.o:
	$(CC) -c $(ALL_CFLAGS) $< -o $@

# Target: clean project.
clean:
	$(REMOVE) $(TARGET).hex $(TARGET).elf $(TARGET).map $(OBJ) 

depend:
	if grep '^# DO NOT DELETE' $(MAKEFILE) >/dev/null; \
	then \
		sed -e '/^# DO NOT DELETE/,$$d' $(MAKEFILE) > \
			$(MAKEFILE).$$$$ && \
		$(MV) $(MAKEFILE).$$$$ $(MAKEFILE); \
	fi
	echo '# DO NOT DELETE THIS LINE -- make depend depends on it.' \
		>> $(MAKEFILE); \
	$(CC) -M -mmcu=$(MCU) $(CDEFS) $(CINCS) $(SRC) $(ASRC) >> $(MAKEFILE)

.PHONY:	all build elf hex eep lss sym program coff extcoff clean depend

 

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

Thank you for your make file: it is likely to be very useful for me, as Arduino IDE seems broken on new versions of Rapsbian , as it is very simple to read and understand.

With the help of Arduino compiling messages on a PC, I think now I can manage to program Arduini from my rPI (Arduino IDE still works ... on nanopis -Debian ARM-  and pcduino -Ubuntu-, but I do not like switching keybeard, screen and mice between tiny cards).

Edited : another advantage of such very simple makefiles is ... one does not need graphical screen any more (nanoPi are often  512 M, pcduino can have 256 M RAM; Arduino IDE eats a lot of ressource, whenit works, comapred with remote connections )

 

Edited again :

I often add two lines to my makefiles ,to make a printable, syntax higlighted,  document and  to indent *.c (and *.cpp) with astyle ("indent" does not love *.cpp files; astyle can be installed with sudo apt-get install astyle indent a2ps)

joli : astyle *.c *.cpp

imprime: a2ps-1 *.c *.cpp *.h -o 2Print.ps && ps2pdf 2Print.ps

 

As RPi's "disks" are unreliable, I often save my work (the content of the directory I am working) with a simple, naive shell script :

sh-4.1$ cat  /cygdrive/h/archivefin/archive.sh 

ici=`pwd`
ici=`basename $ici`
ladate=`date +%Y%m%d`

nomtar=${ici}_${ladate}.tar.gz
cd ..
tar cfz $nomtar $ici
set -vx
echo x$1 # should be invoked with ./archive.sh /media/pi/LIVE (or the name of an mounted external partion)
[ x$1 == x ] && exit 0
echo stockege definitif
[ -d $1 ] && cp -uv $nomtar $1/.
[ -d ${ici}/$1 ] && cp -uv $nomtar ${ici}/$1/.

 

Last Edited: Wed. Nov 8, 2017 - 10:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure what you thought was "wrong" with the Mfile template in the first place? Sure it has additional targets but if you don't invoke "make <target>" then those other sets of rules are just inactive.

 

BTW you appear to have removed the rules for generating .eep - do you think that is wise? It means you cannot use EEMEM.

 

In fact the usual "build:" is:

build: elf hex eep lss sym

ALL of these (with the possible exception of "sym") are useful. Are you SURE you will never want an LSS file. I couldn't envisage using avr-gcc without LSS files!

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

You should set if absent some variables, instead of affecting them:

optimisation level (to play with it from the command line, without breaking the makefile : is it efficient; does it change a lot)

OPT = 1 would become OPT ?= 1

MCU and F_CPU (suppose you buy another card with another crystal and you want to test it quickly)

perhaps CINCS

Whatever the processor (arms and PC, too), you might be curious to see, sometimes, the generated assembly (for limited processor, it goes beyond curiosity, as you might want to count cycles for very fast portions of code; even if this hypothesis  seldom occurs, best thing would  to keep this option as it is , without having to (forget to)  activate it when you need it.)

 

 

 

Last Edited: Wed. Nov 8, 2017 - 10:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nothing was wrong with mfile in the first place, although it wouldn't work on Raspberian off the bat.  The modified version of mfile off GitHub required a lot less tweaking to get working on the PI.  I'm just trying to water it down to what I can understand and what I am using in my current AVR projects.  You make a good point about .eep, I just don't frequently use it.  

 

I teach robotics and do small hobby projects with AVR's, I've never had a reason to specifically examine any of the complied outputs.  Not saying it's invaluable, but I don't have the need or skill set to effectively do so.

 

I guess my goal was to create a very basic working makefile that I knew would reliably work on the PI and was within the bounds of what I currently understand about makfefiles.  I just started digging into the guts this week, so I still have a lot of learning and appreciate all of the tips that are continuing to come in.

 

 

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

Yo should have some info on the size of generated code, as avr-s are flash limited (if you want to use, say, a graphical display, even if you choose proven libraries) and of the global variables (does it remain enough RAM for a modification). I agree that, in 80% of the cases, it is unuseful. But adding this option for the rather annoying case one needs it -and , according to Murphy's law, one has no time to look at the manuals)- seems wise.

 

For generated code : the option --save-temps is useful too, in 2 cases - at least; only one case would be sufficeint, anyway-:

 

a) trouble with included files or macro definition (may occur every where, in PC/RPi too )...

 

b) slow parts on an avr : if one thinks it is too slow, and some part should be rewritten, verifying it can be useful ....

If this option exists, the day/year/century you will need it, it can save you extra trouble (else, it eats very small disk space).

 

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

dbrion0606 wrote:
Yo should have some info on the size of generated code

+1

 

And the variable definition of the program name for that is still left in the last makefile we've seen, so it's just a matter of adding it to the ELF-making rule. Or create a separate target (make size ?).

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

Came home and did some more testing tonight, I also moved on from a blink program to a multi file project I build a year ago.  I did add some size outputs to post-build.  Doing so, I learned some interesting things:

 

  1. The current version of Rasperian does not put avr-size in /usr/lib/avr/bin I had to stick a copy in there (even though my atmel toolchain distro is up to date)
  2. You can't use the -mcu=xxxxx option in avr-size with a .hex file, it won't produce meaningful data.  Bummer.
  3. You can use the -mcu=xxxxx option in avr-size with an .elf file, so that is a lot more helpful.
  4. AS7 will correct a LOT of sloppy coding that my makefile called me out on, so I had to fix ;-)

 

Here is the makefile as of my latest round of testing, which was a much more robust test of developing on the PI.

 

# Hey Emacs, this is a -*- makefile -*-
#----------------------------------------------------------------------------
# AVR-GCC Makefile template, derived from the WinAVR template (public domain)
#
# Rev3 - Added .eep generation back into the target list
# Rev3 - Added post build step to show memory usage for the AVR
# ---------------------------------------------------------------------------
# On command line:
#
# make all = Make .hex.
#
# make clean = Clean out built project files.
#
# To rebuild project do "make clean" then "make all".
# ---------------------------------------------------------------------------

# MCU name
MCU = atmega1284p

# CPU speed
F_CPU = 16000000

# Output format. (can be srec, ihex, binary)
FORMAT = ihex

# Target file name (without extension).
TARGET = YourCompiledThing

SRC = ChronoDot.c keypad.c main.c MCP23008.c MCP23008_LCD.c njsTWI.c

# Optimization level, can be [0, 1, 2, 3, s, g].
#     0 = turn off optimization. s = optimize for size.
OPT = 1

# Name of this Makefile (used for "make depend").
MAKEFILE = Makefile

# Debugging format.
# Native formats for AVR-GCC's -g are stabs [default], or dwarf-2.
# AVR (extended) COFF requires stabs, plus an avr-objcopy run.
DEBUG = stabs

# Compiler flag to set the C Standard level.
# c89   - "ANSI" C
# gnu89 - c89 plus GCC extensions
# c99   - ISO C99 standard (not yet fully implemented)
# gnu99 - c99 plus GCC extensions
CSTANDARD = -std=gnu99

# Place -D or -U options here for C sources
CDEFS = -DF_CPU=$(F_CPU)UL

# Place -I options here
CINCS =

CDEBUG = -g$(DEBUG)
CWARN = -Wall -Wstrict-prototypes
CTUNING = -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS = $(CDEBUG) $(CDEFS) $(CINCS) -O$(OPT) $(CWARN) $(CSTANDARD) $(CEXTRA)

#Additional libraries.

# Minimalistic printf version
PRINTF_LIB_MIN = -Wl,-u,vfprintf -lprintf_min

# Floating point printf version (requires MATH_LIB = -lm below)
PRINTF_LIB_FLOAT = -Wl,-u,vfprintf -lprintf_flt

PRINTF_LIB = $(PRINTF_LIB_FLOAT)

# Minimalistic scanf version
SCANF_LIB_MIN = -Wl,-u,vfscanf -lscanf_min

# Floating point + %[ scanf version (requires MATH_LIB = -lm below)
SCANF_LIB_FLOAT = -Wl,-u,vfscanf -lscanf_flt

SCANF_LIB =

MATH_LIB = -lm

#LDMAP = $(LDFLAGS) -Wl,-Map=$(TARGET).map,--cref
LDFLAGS = $(LDMAP) $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)

#============================================================================
# Define programs
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
SIZE = avr-size
NM = avr-nm
REMOVE = rm -f
MV = mv -f

# Define Messages
HEX_SIZE = Size of .hex :
ELF_SIZE = Size of .elf :

# Define all object files.
OBJ = $(SRC:.c=.o) $(ASRC:.S=.o)

# Combine all necessary flags and optional flags.
# Add target processor to flags.
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS)

# Default target.
all: build post-build

build: elf hex eep

elf: $(TARGET).elf
hex: $(TARGET).hex
eep: $(TARGET).eep

.SUFFIXES: .elf .hex .eep 

.elf.hex:
	$(OBJCOPY) -O $(FORMAT) -R .eeprom -R .fuse -R .lock $< $@

.elf.eep:
	-$(OBJCOPY) -j .eeprom --set-section-flags=.eeprom="alloc,load" \
	--change-section-lma .eeprom=0 -O $(FORMAT) $< $@

# Link: create ELF output file from object files.
$(TARGET).elf: $(OBJ)
	$(CC) $(ALL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS)

# Compile: create object files from C source files.
.c.o:
	$(CC) -c $(ALL_CFLAGS) $< -o $@

# Post build action to display file sizes
post-build: build
	@echo $(HEX_SIZE)
	$(SIZE) -B $(TARGET).hex
	@echo $(ELF_SIZE)
	$(SIZE) -C --mcu=$(MCU) $(TARGET).elf

# Target: clean project.
clean:
	$(REMOVE) $(TARGET).hex $(TARGET).elf $(TARGET).map $(OBJ) $(TARGET).eep

depend:
	if grep '^# DO NOT DELETE' $(MAKEFILE) >/dev/null; \
	then \
		sed -e '/^# DO NOT DELETE/,$$d' $(MAKEFILE) > \
			$(MAKEFILE).$$$$ && \
		$(MV) $(MAKEFILE).$$$$ $(MAKEFILE); \
	fi
	echo '# DO NOT DELETE THIS LINE -- make depend depends on it.' \
		>> $(MAKEFILE); \
	$(CC) -M -mmcu=$(MCU) $(CDEFS) $(CINCS) $(SRC) $(ASRC) >> $(MAKEFILE)

.PHONY:	all build elf hex eep clean depend post-build

 

And here is the output of the avr-size.  Since it can give so much more info about the .elf, that seems the better choice.

 

Size of .hex :
avr-size -B YourCompiledThing.hex
   text	   data	    bss	    dec	    hex	filename
      0	  10990	      0	  10990	   2aee	YourCompiledThing.hex
Size of .elf :
avr-size -C --mcu=atmega1284p YourCompiledThing.elf
AVR Memory Usage
----------------
Device: atmega1284p

Program:   10990 bytes (8.4% Full)
(.text + .data + .bootloader)

Data:        624 bytes (3.8% Full)
(.data + .bss + .noinit)

 

Last Edited: Thu. Nov 9, 2017 - 05:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, avr-size is intended for ELFs. Why a bummer it's not for the HEX? Inevitabely, the ELF has been made if the HEX has been made...

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

Well, maybe something is lacking (apart for c++ : if OP wants to reuse Arduino libraries, should be taken into account, even if sleeping) : how to invoke avrdude (has a lots of parameters, which is very typo prone and boring, even if RPi has bash history (if it lacks, one should install bash-completion, to avoid retyping long commands by "apt-get install bash-completion"):

 

a rule , let us name it "upload:" might be useful to hide all the options which can be set once.

 

I noticed OP complained about bad -difficult to read- syntax highlighting. If he likes vi, cream ("sudo apt-get cream") ships with each and every part of  vim improved , and has many styles of syntax highlight colors (":colorscheme blue " will give a blue background and about everything can be read; ":colorscheme desert" exists, too, IIRC).

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

dbrion0606 wrote:
a rule , let us name it "upload:"

Or rather, keep in line with the naming in the Mfile template (since it is what this makefile has been derived from, and mane the rume "progrram".

 

AKnick wrote:
You can't use the -mcu=xxxxx option in avr-size with a .hex file, it won't produce meaningful data.  Bummer.

No, you can't -  since a lot of context is missing from the hex file. It's just a blob of bytes that should go into flash. There is no information on what parts of that are code, what parts are data to initialize variables. And there is no info at all in the hex about  non-initialized variables (unless you want to reverse-engineer the code, and even this it is very hard, maybe impossible).

 

The avr-size (a spinoff from the generic GNU Size) was intended to look in ELF files, because that is where all of that information is still intact.

 

Why a bummer? If the HEX file has been built then it is an inevitable fact that the ELF file also has been built.

 

AKnick wrote:
The current version of Rasperian does not put avr-size in /usr/lib/avr/bin I had to stick a copy in there (even though my atmel toolchain distro is up to date)
 

Are you sure Raspbians repositorys have a reassonably new and shiny avr-gcc version? We've seen many reports on Linux repos being hopelessly behind. One of the main developers of the tool chain is Atmel itself, but they are somewhat slow to push their stuff upstream (and then all the distros must pull it).

 

Wht do you get if you do

avr-gcc --version

on a command line?

 

(Wonder how long it would take to build the avr-gcc tool chain on an RPi. On a 2.6 GHz 2-core Intel i5 system with a SSD disk, it took about 25-30 minutes..)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

Installed version is 4.9.2 that looks like the same version that is on Atmel's/Microchip's site.  I did go ahead and add a program section to the make file, re-typing the avrdude stuff got old fast... I still need to clean the program piece up a bit.  So, it's really starting to look like the mfile template I started with (just without the ability to handle CPP and ASM).   

 

Regarding avr-size I just assumed that it would do the same report for .hex, live and learn.

Last Edited: Thu. Nov 9, 2017 - 08:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Are you sure Raspbians repositorys have a reassonably new and shiny avr-gcc version? "

 

I am sure they are not.

On nanopi, I could physically install a newer version (and of avr-libc)https://packages.debian.org/buster/gcc-avr

installing from outside the current version is frowned upon. Idea -I do not give script-  is the following (I did not dare to test it on PCduino -ubuntu- and even less on a Mint virtual machine -I shun from recursive derivatives; exponentiates at least complexity- ) :

* add the shiniest, latest (and maybe buggy ) repository to the list (and I changed the Chinese repos to the French ones)

If this is done, a massive system "up" grade with rach and every new (and not fully tested) package  is likely to follow, leading to a disaster...

 

* give a low priority on the unstable repo edited, an high priority on every other repo, avoids such disaster... you can trust your package manager...

 

* each new package can be installed by explicitely specifying the unstable depo "sudo apt-get install gcc-avr -t buster" IIRC...

I could not install it intellectually because, outside querying the version, I have no idea of how to check a compiler (and had to play with opencv and dlib on nanopis and Rpis). Conclusions from erratic tries would be Miss Leading.

 

Building avr-gcc on a RPi would be terrible : it has little RAM, and swap file is on a SD card.... for dlib compiling -which is faster than gcc and maybe needs less resources-, I should have removed the swap partition and have put it on an external disk.... but I  fear  this idea came too late https://www.pyimagesearch.com/2017/05/01/install-dlib-raspberry-pi/#comment-439779.....  and I bought another RPi lousy "disk" (time is not an issue, as things can be compiled by night).

 

Or rather, keep in line with the naming in the Mfile template (since it is what this makefile has been derived from, and mane the rume "progrram".

 

upload:program # would make a synonym (unchecked)

 

 

 

 

 

 

 

Last Edited: Thu. Nov 9, 2017 - 09:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AKnick wrote:
Regarding avr-size I just assumed that it would do the same report for .hex
 

Nope, as I said: The HEX is merely a raw image of what should go into the flash. There is no info left for avr-size to use to give you a meaningful report. Still don't get the "bummer" part, though...

 

AKnick wrote:
, it's really starting to look like the mfile template I started with
 

Which sort of pushes our earlier remarks: Consider actually using the Mfile template. A lot of people are familiar with it, and can help you when/if you get into trouble. Perhaps an RPi has enough muscles to install and run Tcl/Tk and then you could even run the Mfile utility -  and life will bee good...

 

dbrion0606 wrote:
"Are you sure Raspbians repositorys have a reassonably new and shiny avr-gcc version? "   I am sure they are not.

OK, I'll re-formulate to "Are you sure Raspbians repositorys have a avr-gcc version that is reasonably close to e.g Atmels build of the tool-chain?". And we have the answer to that, from the OP: He got 4.9.2. Atmels of the AVR toolchain for Linux  is 4.9.2 (or at least was, this summer).

 

The point is, if someone wants help with perceived problems with the compiler then it will be nice if (s)he is on a version close to what many users have. (There's been some feature changes and news over the last few years in (avr-)gcc. Relaxation optimization is relatively new, IIRC.)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

I thought Atmel were up to 5.3 or 5.4?

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

Cliff, I'm looking at the toolchain for Linux that I downloaded and installed in August or September.

 

Download page says Atmels version number for the toolchain is 3.5.4, which is what I have

 

johan@Mint-Latitude-E6330 ~ $ avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.5.4_1709) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and as you can see it is (avr-)gcc version 4.9.2.

 

The download page for the windows build of the toolchain reports the same Atmel version number.

 

Could it be that Atmel has released a newer build, but only in the installer for the latest version of Studio? If so, then that is sad/bad/mad.

 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

OP has the official version , i.e 4.9.2, in Debian numerology sense. (Rapsbian is jessie + RPi HW specific)

nanoPi has the official version 4.7..x (nanopi Debian arm is weezie)

Behavior is logical

One can manage to partially upgrade packages (and their dependencies...) for unstable version : I linked to buster and number was coherent with Cliffs number. I could do it for nanopi, and quick che showed no degradation for the usual behavior.

 

Beside numerology( avr-gcc --version gives it), is there a method to know whether the compiler is new, shiny and consistent with what ones expects, once one has translated Debian jargon, Atmels numerology and gcc numerology?

 

And this mere fact explains why I shun from recursive derivatives...

 

(Wonder how long it would take to build the avr-gcc tool chain on an RPi. On a 2.6 GHz 2-core Intel i5 system with a SSD disk, it took about 25-30 minutes..)

Well, my work PC is a 2.8G, 2 core Intel, and it executes pure RAM and CPU program taken from http://www.ipol.im/pub/art/2011/my-asift/demo_ASIFT_src.tar.gz as fast -50 seconds : enough to neglect init time, and not too boring-  as my RPi 3 (4 cores). In both cases , each processor works -and the system is very unresponsive). I suppose half of the compiling work is CPU computing, other half is disk access. Then, your cores spent ... 30 minutes in CPU ...

As RPi CPU are twice slower, a single core (-j1) will spend 1 hours. Using more than a core to compile is a bad idea, as each piece of code, when compiled, needs some RAM and ther is RAM used, too, in order to have processes comunicating. 

 

Disk remains unknown, as one should mount an external disk (with varying performances) to spare the internal RPI lousy disk.

Even in summer, near the polar circle, it can be compiled within a night.

 

nanopi m1 is twice slower with pure CPU multithread program ... and depends on the CPU temperature (in summer, it will be slower).

 

Last Edited: Thu. Nov 9, 2017 - 01:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the October 2017 release of Studio (7.0.1645) the GCC version is not stated. Atmel did state the GCC version for the previous 7.0 builds (builds 582 to 1188: gcc 4.9.2, 1416: gcc 5.4.0) where new versions of Atmel Toolchain where announces. For the 1645 build a new toolchain version is stated (3.6.1) but it is not stated which GCC version that corresponds to.

 

Is this just a mistake? Or did the GCC version not change? Or is this about some cherry-picking of GCC parts making for a meaningless GCC version number?

 

What it definitively is: Confusing.

 

Not the first time Atmel did "hazy" or "limping" releases, but I thought that was done and over with in the last decade. )-:

 

Why not always

  • Release Atmel Toolchain separately, both Wondoze and Linux, when there is a release of Studio that has a new tool chain?
  • State GCC version, binutils version etc in release notes? Man invented tables to organize systematic information... ;-)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

I thought the "Toolchain for Windows" and the "toolchain for Linux" they released was updated at the same time as the version "inside" AS7 and I'm pretty sure AS7 now has a 5.x so I would have expected  both Windows and Linux "Toolchain" to now deliver that 5.x too? But maybe they haven't got around to updating the separate "toolchain" versions then?

 

Hopefully Morten et al are reading this and can put us straight.

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

JohanEkdahl wrote:
For the 1645 build a new toolchain version is stated (3.6.1) but it is not stated which GCC version that corresponds to.

http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1/SOURCES.README

...

2. avr-gcc.tar.bz2

   GCC 5.4.0 with the modifications in AVR target

...

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

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

http://www.atmel.com/tools/atmel...

 

Is what I used to check the version against, which still states 4.9.2

 

If there is a more up to date location I can try, I could always try and run the compile experiment on the PI 3.  But I wouldn't know where else to look other than Atmel's website.

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

There is a newer (according to avr-gcc --version  ) in the next (for you : rapsbian) package (for me it is the next's next).

I gave all the keywords necessary for google to find how to install it -and decided not to give the links to a soulution which worked for me-.

BE aware that :

* installing from next (s'next) is frowned upon, as it can break other packages: I had to verify no essential packages seemed broken. This takes time. This time is not spent in learning/playing.

* One cannot prove it is shinier, unless one looks at generated code (you should have kept the *.LSs option). Your hardware wonot emit weird lights....

 

Other option is to compile from source. 

 

I would not start with gcc cross compilers, as it is somewhat complicated and I Learning J Ekdahl had it compiled was a pleasant new.

 

Drawbacks with compiling frrom source on RPi :

 

a) is writes a lot of files on a "disk" with limited writes

 

b) some options (-jx) of make allow parallelization, using a lot of RAM; if RAM is not enough, swap files/partitions are used ... and bring back, in the worst configuration, to point a)

Time estimation were given for a RPi (less than a summer winter night if one is far enough from the polar circle 67°N/S). They were based on the assumtion that swap does not occur (then estimations wake no sense at all, disk access being 10-100 times slower)

 

Better solution would be  ... to wait -it will come with next RPi version- and to keep track of all generated assembly files, to compare.... and answer the question : is it shinier?