Hi there!
My actual project requires certain parts to be executed as fast as possible. Is there a way to see what the tool chain produces right before it is uploaded? I know I can get the "intel hex code" - which is pretty unreadable. Can I have this as an assembler listing so that I can see what changes lead to faster machine code?
TIA
Gregor
/home/duro/arduino-1.8.8/hardware/tools/avr/bin/avr-objdump -h -S Blink.elf > Blink.lst
Juraj:
/home/duro/arduino-1.8.8/hardware/tools/avr/bin/avr-objdump -h -S Blink.elf > Blink.lst
You forgot to tell him how to find the .elf file.
Enable verbose compile. That will give you a path including "arduino_build_676741" (where that number is something different), and that's where the .elf will be.
The output will also give you the path to the compiler bin files.
The command line options I use are:
avr-objdump --disassemble --source --line-numbers --demangle --section=.text Blink.elf > Blink.lst
It's a shame the official AVR core doesn't give an assembly listing when you do export compiled binary - A while back (thanks to much help from Per), I got my ATTinyCore to generate an assembly listing in the sketch folder when you do export compiled binary, which makes life so much easier; the paths to the temporary build folder, and to the compiler when using anything installed via board manager, are not meant for human consumption.
Here's an example of what it looks like on my computer (under windows):
"C:\Users\Pete\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\7.3.0-atmel3.6.1-arduino5/bin/avr-size" -A "C:\Users\Pete\AppData\Local\Temp\arduino_build_676741/blink_sketchsize.ino.elf" > "C:\Users\Pete\AppData\Local\Temp\arduino_build_676741/blink_sketchsize.ino.lst"
DrAzzy:
... which makes life so much easier;
Since I'm about to make life harder by staying with my code that's good news 
Regards,
Gregor
DrAzzy:
You forgot to tell him how to find the .elf file.
gregorss is not a newbie
Juraj:
gregorss is not a newbie
That depends. Sometimes I'm amazingly stupid - even unintended.
Gregor
PS: ... hm ... I don't feel that stupid today ... I think ...
python --version gives me
Python 2.7.11
Running under Slackware 14.2, Kernel 4.4.14
Regards,
Gregor
Try...
python3
You forgot to tell him how to find the .elf file.
gregorss is not a newbie
Please remember that the answers to questions are not just for the benefit of the person asking, they are for the benefit of anyone else reading who might be interested and not have the same level of knowledge. Extra information is never wasted, even if the OP does not need it, someone else might.
PerryBebbington:
Please remember that the answers to questions are not just for the benefit of the person asking, they are for the benefit of anyone else reading who might be interested and not have the same level of knowledge. Extra information is never wasted, even if the OP does not need it, someone else might.
but it depends. I have it at /home/duro/eclipse-workspace/Blink/Release
gregorss,
Since it appears that you are using an OS that comes with proper development tools, you should be able to use the shell script I wrote.
It is a wrapper script around avr-objcopy.
It generates an assembler listing and symbol table every time avr-objcopy is called from the IDE, which is ever time AVR code is buit.
It outputs where the files were created so you can see the location of the files from the IDE.
All you have to do is go down into {installdir}/hardware/tools/avr/bin and rename avr-objcopy to avr-objcopy_bin and then install this script as avr-objcopy and give it execution permission.
Enjoy,
--- bill
avr-objcopy.zip (1.42 KB)
bperrybap:
gregorss,
Since it appears that you are using an OS that comes with proper development tools, you should be able to use the shell script I wrote.
It is a wrapper script around avr-objcopy.
It generates an assembler listing and symbol table every time avr-objcopy is called from the IDE, which is ever time AVR code is buit.
It outputs where the files were created so you can see the location of the files from the IDE.
All you have to do is go down into {installdir}/hardware/tools/avr/bin and rename avr-objcopy to avr-objcopy_bin and then install this script as avr-objcopy and give it execution permission.Enjoy,
--- bill
elegant way would be add a command to platform.local.txt. not to rename a tool
elegant way would be add a command to platform.local.txt. not to rename a tool
(hah! Yes, you can!) )(meh. The recipes don't seem to support output redirection, and objdump doesn't seem to support output to anything other than stdio. So I think we'll need an intermediate script of some kind, which won't be portable...)
recipe.hooks.linking.postlink.1.pattern=echo Creating assembly listing
recipe.hooks.linking.postlink.2.pattern="{compiler.path}arm-none-eabi-objdump" "-SC" "{build.path}/{build.project_name}.elf" "> {build.path}/{build.project_name}.asmlisting"
Juraj,
I've been dealing with how to get the IDE to create these additional AVR files in a simple & consistent way for over 30 revisions of the IDE through just over a decade of time.
During the past 10+ years I have experimented with various ways of getting this done, but given the way the IDE has chosen to implement things, by far the easiest way to make this happen and to make the necessary mods to a freshly installed IDE package is by hijacking an existing avr tool with a wrapper sketch
If only they hadn't decided so many years ago to re-invent the world inside the IDE and used more external scripting tools and used make to do the actual builds.
Then, it would likely be easy to modify the make template and/or scripts so life could be so much simpler.
I currently have a bit over 30 versions of the IDE installed on my development machine for various testing purposes.
Pretty much every version of the IDE going back to 0019. (things were VERY different prior to that)
At this point, IMO, the best solution would be to tweak the IDE package so that these AVR files are created all the time.
Yeah it would add a slight amount of time to a build and yeah most people would never use them, but those additional AVR files would be there for those that want to have them.
Also, IMO, there are other things that could be done differently and/or better in the IDE that could more than make up for the added minimal time to always create these files.
--- bill