Why would the code size be different when compiled?
(Bare Minimum Sketch)
Uno=450 bytes
Attiny85=290 bytes
It would seem since these are both 8bit AVR cores, the size should not vary. I expect there are more registers to initialize in the Uno...is that correct?
-fab
Both AVR cores but not identical cores. The one for the '85 is probably written to be leaner on purpose since there is less flash in the chip.
The Tiny chips don't have a multiply instruction which can result in larger (and slower) code in some cases.
Don't forget the arrays to convert pins to ports/etc - Those are a couple of arrays in progmem with one entry per pin.
Tiny does not have serial hardware as I recall, so that would be synthesised in software, ergo, more code.
Use of multiply would be much less likely.
Don't forget that a lot of code is not present in the "bare minimum" sketch. No pin tables or serial code, for example.
The big difference is the interrupt vector table, which has fewer AND smaller vectors on tiny. 108 bytes on m328, 28 bytes on tiny85...
Thank You All!
Yes west..that would do it.
Paul, maybe I don't understand. The tiny85 is the smaller footprint in the example. So, with no Serial called or setup, no soft serial code I would think. After all, I am using bare minimum as the example. Does arduino setup serial by default? I would think that would be more than 290 bytes alone. Anyway, I noticed the big different and thought I'd ask about it.
Dr Azzy, yes, I suppose. I need to research how to see the elf I guess. I know it is possible, but IIRC, quite buried in the structure.
Here is raw data (from avr-nm)
__do_clear_bss is the lowest code symbol in memory; almost everything below that is vectors.
Tiny85 (digispark)
address size
00000042 00000002 T loop
00000040 00000002 T setup
00000044 00000008 T main
0000002a 00000010 T __do_clear_bss
0000004c 0000001e t initToneTimerInternal
000000f8 00000032 T init
0000006a 0000008e T __vector_4
Mega328 (Uno)
address size
00000094 00000002 W initVariant
00000092 00000002 T loop
00000090 00000002 T setup
00000074 00000010 T __do_clear_bss
00000096 0000001e T main
00000148 00000076 T init
000000b4 00000094 T __vector_16
It is best is to look at a listing file of the linked code so you can see everything and not just guess.
You can modify your platform.txt file to change the rule for the objcopy phase to call a wrapper script instead of objcopy that first generates the listing file from the .elf file before finally creating the .hex file by calling objcopy.
I have a wrapper script that creates both a listing file as well as a symbol table as the .hex file is created.
If you are using linux, I can give you instructions on what to change as well as the shell script wrapper.
(Things like this are quite painful to do on Windows)
--- bill
i would very much like to generate lst along with hex etc in xp tmp directory. is there any more info floating around how to do this? google dont seem too helpful.
john1993:
i would very much like to generate lst along with hex etc in xp tmp directory. is there any more info floating around how to do this? google dont seem too helpful.
by "xp temp directory" does that mean are you still using Windows?
On Windows, it is pretty hard, because Windows was not designed for s/w developement and doesn't have many tools that are useful for this kind of stuff so it is a total pain to get something like a wrapper script or batch file working.
The main issue, if you use a batch file, vs a shell script, will be getting the paths to the other gcc tools into the batch file. If you want to use a shell script, you will still have the path issue but then still have to have a batch wrapper to set up the environment to use the shell executable and then will need a few other unix type tools to parse out the paths.
Bottom line is windows sucks for commandline tools and for this kind of stuff we are dealing with the command line.
This kind of stuff is trivial on the *nix operating systems.
--- bill
Provided you know the paths, what's the incantation to generate the lst?
You don't have to know the paths in advance since the IDE execs objcopy using the full path to the executable and the other bin tools you need are in the same directory.
And it also passes in the full path to the .hex file
So all you have to do is modify the recipe in the platform.txt file to call a wrapper script instead and pass in all the same arguments including the original executable as arguments to the wrapper script.
All you have to do in the wrapper script is parse off the path from the objcopy command and use that as a prefix to the objdump and nm commands used to create listing and symbol table files.
It can also extract off the basename and directory of the original .hex file and use that for the basename and directory of the .lss and .nm listing and symbol table files.
All pretty simple stuff on *nix machines.
See the wrapper script for more details (attached).
If you want to more information about command line options used with avr-objdump and avr-nm commands used inside the wrapper script see their man pages.
--- bill
avr-objcopy-wrapper.sh.zip (893 Bytes)
its easy to get lst from cmd line using "avr-objdump -j .sec1 -d -m avr5 t.hex" but a real pain to hunt down the hex file. arduinio puts it where the sun dont shine and different dir every time. i was hoping to automate this but not an expert in the secret handshake world of ardunio. oh well... winavr.
john1993:
its easy to get lst from cmd line using "avr-objdump -j .sec1 -d -m avr5 t.hex"
objdump works on the elf file not the hex file.
I typically use:
$compilerpath/avr-objdump -S -h $elfname > $buildpath/$bname.lss
to get the listing file with original source code.
A specific example done manually when sitting in the build directory would be:
avr-objdump -S -h foo.elf > foo.lss
to put the listing in the file "foo.lss"
But it is much easier if you simply patch your platform.txt file to do it automatically.
(it is a 1 time thing)
Then all you do is jump down into the build directory (which you can see from the output of the wrapper script) and you look at the .lss or .nm files any time you need to.
bperrybap:
objdump works on the elf file not the hex file.
actually as can be seen if you try the line i posted it works on any binary. i have been using it with hex not elf for many years because the former is always available but elf is not. the only advantage to elf is incorporating source lines in the listing.
bperrybap:
But it is much easier if you simply patch your platform.txt file to do it automatically.
(it is a 1 time thing)
Then all you do is jump down into the build directory (which you can see from the output of the wrapper script) and you look at the .lss or .nm files any time you need to.
if by "much easier" and "simply" you mean far beyond the ability of most ardunio users then i agree. lol
Modifying platform.txt was exactly why I asked about that - because that's when you have access to the build path and all. You could even tell it to put the files somewhere that was easy to access.
john1993:
actually as can be seen if you try the line i posted it works on any binary. i have been using it with hex not elf for many years because the former is always available but elf is not. the only advantage to elf is incorporating source lines in the listing.
I stand corrected. I didn't realize objdump supports reading intel hex records.
I've not ever tried it on anything but elf images since that is what the tool originally was designed to use.
But there are several advantages of using the elf image - which is available in the Arduino build area. The biggest advantage being that it contains symbols as well as architecture information.
At least in my opinion, having the symbols makes it much eaiser to track down what is using up all the space and then having the ability to have the actual source inserted is an even bigger bonus as it makes it easy to locate the code and data to see the code generated by the compiler.
if by "much easier" and "simply" you mean far beyond the ability of most ardunio users then i agree. lol
The patch is pretty simple to do when using an OS designed for s/w development. The wrapper sketch I supplied has instructions in it for how to do it.
Unfortunately, many people are using Windows, and while it is possible to do this type of wrapper on Windows, and I've done it before, writing wrapper scripts on Windows isn't as easy as it is on *nix operating systems since Windows is so commandline hostile.
The bigger question is why isn't the Arduino IDE doing this by default?
I'm guessing that the answer to that is probably that the vast majority of Arduino users are not technically savvy enough to know what to do with the information - much less know how to find it; so I'd guess that it isn't that much of priority to the Arduino team.
Well, at least for those using a *nix OS, I've provided an easy solution.
--- bill
Bill...that's great! I haven't tried it yet as I just got out of the mines, but I will soon. It would be great to see the source stacked next to the hex or assembly! Many of my previous questions not posted would be answered I'm sure!
Thanks for the script!
-fab
bperrybap:
Windows is so commandline hostile.
i have to agree with that. unfortunately it is os for the "99%".
speaking of cl, couple years back i think it was you who helped me with one of the secret handshakes to capture text output of some misbehaving program (dude?). iirc it involved adding a special character to the > line. ive carelessly misplaced the info and wonder if you can provide a hint. again google has failed me.
Dear Mr. Bill,
Ok, I did the platform.txt mod in the directory stated. Saved the .sh in the other directory stated. At first, when you said, "
I did notice platforms.txt also appears in arduino-1.6.6/hardware/, but I didn't fall for it...almost ;).
But it occurred to me that I might be looking in the wrong place for the produced file.
To remove any doubt, Xubuntu is where I'm doing all this, and ArduinoIDE 1.6.6.
Where is the file output to? The build directory? Since I had no visible output other than final stats (Oh, verbose) is there a hint where to look? /tmp/...
Edit: Found the /tmp/.... in root, still no readable file. I can see .hex and several others. I realized verbose wasn't turned on in preferences, still no joy!
Thanks,
-fab