avr-size with -mcu

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

Do people use the -mcu option in avr-size? The IDE used to, but now it does not - it figures out available flash and RAM from the device database.

Just curious if people are actually using this flag - the patch is never gonna get upstreamed to binutils FSF, and it also means more work when a new device is released :)

Regards

Senthil

 

blog | website

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

Are you suggesting removing the option altogether from the source code? What about users of avr-size that runs it from a makefile?

What about users on platforms where Atmel Studio, due to the unfathomable wisdom of Atmel descision makers, wont run? Code::Blocks/Eclipse/NetBeans/whatever on GNU/Linux of MacOS?

Are you saying that the source repo for avr-size should target only one platform and mainly support Atmel building it's toolchain?

Why can't you fork/branch and remove it there, since you are the "special case"? (But then of-course you would need to merge from the trunk before every release you want to make.)

Or am I missing a point here? Has been known to happen..

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

Well, avr-size is built from the binutils-gdb source repo, and the code that makes avr-size aware of device specific information (-mcu and -C option handling) is not present there, and never has been. Past attempts to put it there did not succeed (see https://sourceware.org/ml/binuti... and https://sourceware.org/ml/binuti...) because in the maintainer's opinion, the size utility is a target neutral tool.

So, it is Atmel that maintains the patch in its "fork". The reason I asked is because avr-binutils is progressively moving away from knowing about device specific info - the compiler driver, for example, only passes the arch of the device (plus other ISA related info) to the assembler, where it previously used to pass the device name.

If no one really uses the flag, perhaps it's best to do away with it. If people do use it, we'd have to find a way to support that in a way that lets us upstream the source and makes my (toolchain devs) lives easier. I didn't really say I'm going to remove the option right away :)

Regards

Senthil

 

blog | website

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

As Johan says you seem to have a very "Windows-centric" view of things. I use -C on avr-size all the time when I use (ironically) Atmel's Toolchain for Linux. So, yes, I think the effort should be put in to maintain this feature or this is going to look (once again) like Atmel trying to take over and dictate the general development of the OPEN avr-gcc.

If you don't want to expend the effort in maintaining the particular -C patch for new devices then make your source tree for binutils open and let someone else do it for you (I would happily do it if Eric's no longer interested).

Unfortunately (because of the widest device support) the Atmel build of avr-gcc/binutils is effectively the de-facto standard now for the toolchain so you should allow it to be open for modification by 3rd parties to help improve it.

(it does seem a real shame that the binutils maintainers won't allow this patch to go upstream but I can kind of see why - other architectures would then be saying "how come does AVR get this fancy feature when we don't?". I guess it also requires more maintenance as there need to be regular re-issues as new devices are added. But as I said in another thread just this week perhaps it should have been done like avrdude.conf with all the part specific stuff read from a text file that anyone could edit).

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

I don't understand the hostility, honestly :) I was merely asking if people use it - I know Atmel Studio doesn't, so I thought I'd say that.

Ironically, the motivation behind my question was to get rid of Atmel specific patches/stuff and get all work done on the upstream repos - that way, like you said, anyone can contribute. Almost all binutils patches that Atmel used to maintain are now in the FSF binutils repo, and Atmel is contributing new patches regularly as well.

Yes, modifying avr-size (or maybe creating another utility, which the binutils maintainer(s) are OK with) to read device specific stuff off an external file was what I thought of too.

(typing this on Firefox running Arch Linux, FWIW :))

Regards

Senthil

 

blog | website

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

Quote:

I don't understand the hostility, honestly

You do realise that Atmel have effectively "taken over" avr-gcc don't you and they seem only interested in helping windows developers and couldn't care less about Linux or Mac users? Why else did they base Studio 6 on (Windows only) Visual Studio? The previous corss platform development had been the Eclipse based AVR32 Studio and the expectation was that Studio 5 would be Eclipse (or at least cross platform) based when it appeared. Then it turns up as a Windows only program. So, yes, some users are hostile to Atmel's motives.

In the emails you linked to there was suggestion to move the -C stuff to objdump or readelf that are target specific anyway - that seems like a good idea if it would mean acceptance upstream.

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

saaadhu wrote:
The IDE used to, but now it does not - it figures out available flash and RAM from the device database.

Thus hiding it from anyone who wants it:

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

:x

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

I don't understand the hostility, honestly

You do realise that Atmel have effectively "taken over" avr-gcc don't you and they seem only interested in helping windows developers and couldn't care less about Linux or Mac users? Why else did they base Studio 6 on (Windows only) Visual Studio? The previous cross platform development had been the Eclipse based AVR32 Studio and the expectation was that Studio 5 would be Eclipse (or at least cross platform) based when it appeared. Then it turns up as a Windows only program. So, yes, some users are hostile to Atmel's motives.

+1

When reminded, it still amases me that Atmel chose to go single-platfrm when the possibilities to support multi-platform development environments have never been better.

So, if there is even a hint that Atmel might cut off functionality that is needed on other platforms than Windows, how can you be surprised it triggers what might be perceived as hostility?

Some questions can not be asked without expecting strong reactions. E.g.: Can I cut your head off?

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

The toolchain has (and continues to be) available for Windows and Linux, so I don't understand how that applies to avr-gcc.

Anyway, I think I got what I wanted - the option is being used. Thanks guys.

Regards

Senthil

 

blog | website

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

Having thought about this a bit more, I figured it should be possible to embed device related info (flash/ram/eeprom sizes) in a separate (noload,noalloc) section in the ELF file, and have objdump or readelf read from it, instead of hardcoding in binutils.

Tried this out by modifying avr-libc's gcrt1.S to generate a .note section that uses macros available in the device header files to embed flash, ram and eeprom sizes. I also modified objdump to take a -Pmem_usage option to read and print memory usage information, instead of patching avr-size.

Besides the fact that the XXX_SIZE macros are not available for all devices, it seems to work, and there's no hardcoding anywhere :)

Of course, the whole thing will work only if the user links against avr-libc's crt. Do you guys think that's reasonable?

Regards

Senthil

 

blog | website

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

Sounds like a very interesting idea.

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

Makes sense to me. Better yet if the signature section is present figure it out from that.