Device Family Packs are annoying...

Go To Last Post

17 posts / 0 new

Author

Message

westfw

Level: Raving Lunatic

Joined: Wed. Jun 19, 2002

Posts: 5350 View posts

Location: SF Bay area

Posted by westfw: Fri. Jul 20, 2018 - 11:30 AM

I really don't want to have to type:

avr-gcc -mmcu=atmega328pb -B /home/packs/Atmel.ATmega_DFP.1.0.86/gcc/dev/atmega328pb/ -I /home/packs/Atmel.ATmega_DFP.1.0.86/include/ foo.c

each time I try to compile a file, nor do I want to clutter my makefile with paths that may or may not be consistent from system to system (and certainly won't be consistent between different OSes.)

(yes, I'm generally using CLI commands or generic Makefiles to build things, rather than Atmel Studio.)

Is there some sort of tool or command to automatically merge the lastest pack into the standard toolchain locations?

So far, I've only been bitten by io.h not recognizing a defined CPU, or by the relevant ioXXXX.h not being present, rather than the compiler not recognizing -mmcu=xxx

(yeah, yeah: version-control the toolchain as well as your own source code. I suppose that makes sense, sometimes. But it's certainly not practical for OSSW published on github/etc. And there are some things that I'm willing to trust to the vendor (having iom328pb.h be 'correct') until proven otherwise.)

Tags:

Tools, Atmel Studio (AVR-related)

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 104799 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Fri. Jul 20, 2018 - 12:21 PM

The irony is that the whole point of DFP was to be able to later add "new micro" support to the compiler without having to rebuild and issue a complete compiler. So I guess this is the classic two edged sword. Damned if you do, damned if you don't. ;-)

awneil

Level: 10k+ Postman

Joined: Fri. Jul 1, 2005

Posts: 25563 View posts

Location: Basingstoke, Hampshire, UK

Posted by awneil: Fri. Jul 20, 2018 - 12:44 PM

westfw wrote:

But it's certainly not practical for OSSW published on github/etc.

Why does that make it impractical?

Top Tips:

How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
"Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
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
Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 104799 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Fri. Jul 20, 2018 - 01:07 PM

Well I don't know about you but I wouldn't personally want to have to pull a 1GB compiler toolchain just because I was building 20K of bootloader or something.

awneil

Level: 10k+ Postman

Joined: Fri. Jul 1, 2005

Posts: 25563 View posts

Location: Basingstoke, Hampshire, UK

Posted by awneil: Fri. Jul 20, 2018 - 01:36 PM (Reply to #4)

OP seemed to accept the concept of revision-controlling the toolchain:

westfw wrote:

yeah, yeah: version-control the toolchain as well as your own source code. I suppose that makes sense

I was wondering why the fact of it being hosted on GitHub made that impractical ?

Surely, you'd have it checked-out to use - so where it's hosted should be irrelevant.

and you wouldn't pull it for each build.

Top Tips:

How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
"Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
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
Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 104799 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Mon. Jul 30, 2018 - 10:05 AM

Just to say that I just hit this and I see how irritating it is.

Someone mentioned a tiny817 problem here so I wanted to build the code they posted. None of my local avr-gcc's were new enough to have tiny817 support so I went to the "horse's mouth" and downloaded the latest "toolchain for Windows". I then tried to invoke "avr-gcc -mmcu=attiny817 ..." and got an error saying io.h had never heard of it. Then I remembered this thread and the VERY useful info in #1. So with the right DFP unpacked I was able to build with:

avr-gcc -mmcu=attiny817 -B /atmel_avr/Atmel.ATtiny_DFP.1.3.172/gcc/dev/attiny817/ -I/atmel_avr/Atmel.ATtiny_DFP.1.3.172/include/ -Os avr.c -g -o avr.elf

but if you are in the habit of just running quick compile commands on the command line how irritating is it to have to include all this -B and -I nonsense!

I thought that if I just downloaded "toolchain for Windows" from Microtel it would naturally just support "all the latest devices" directly with no intervention - sadly not true any more :-(

I suppose in a Makefile you would do something like:

DFP=/atmel_avr/Atmel.ATtiny_DFP.1.3.172
DEVICE=attiny817

...

avr-gcc -mmcu=$(DEVICE) -B $(DFP)/gcc/dev/$(DEVICE)/ -I$(DFP)/include/ -Os avr.c -g -o avr.elf

but the fact is that the very reason I just type commands on the command line is usually I want to vary to use specific options (-save-temps, -fverbose-asm, etc) and I don't want to have to edit the options in a Makefile every time.

westfw

Level: Raving Lunatic

Joined: Wed. Jun 19, 2002

Posts: 5350 View posts

Location: SF Bay area

Posted by westfw: Tue. Jul 31, 2018 - 01:17 AM

I see how irritating it is.

Ah Hah! Vindicated!

if you are in the habit of just running quick compile commands on the command line how irritating is it to have to include all this -B and -I nonsense!

Yes, exactly.

I was wondering why the fact of it being hosted on GitHub made that impractical ?

Ideally, any needed special tools would be hosted in the same place as the project, and compiler pieces:

Tend to have restrictions on who can re-distribute them.
have extensive dependency hell associated with them.
really shouldn't be "special" in the first place. In general, I try to craft OSSW projects so that they are not dependent on compiler versions/etc.

westfw

Level: Raving Lunatic

Joined: Wed. Jun 19, 2002

Posts: 5350 View posts

Location: SF Bay area

Posted by westfw: Tue. Aug 7, 2018 - 04:59 AM

OK. Here's how to "install" DFPs in a CLI-Toolchain based release. This worked for atmega324pb and atmega328pb on my Mac, which otherwise had the latest Mac Toolchain available from Microchip...

First, I should comment that apparently "-B" isn't some weird command that Atmel added to search packs, but rather a standard gcc option to add directories to the search path for "gcc stuff" (not including #include files.) It would have been nice if there was some default root and you could specify "-B packs" and just stick the packs somewhere in the normal toolchain directory hierarchy, but I couldn't find any such thing, not any indication that it exists :-(

The latest set of Device Family Packs, like "Atmel.ATmega_DFP.1.2.209.atpack" are .zip file. Rename them to whatever.zip. and unzip, which will give you a directory Atmel.ATmega...209 with a structure that looks like this (some of the sub-directories have been deleted to show things more clearly. Packs seem to include updates for the existing files as well.)

Atmel Pack directory structure

The xxx-name directories are ones that I've renamed. They seem to contain files used by Atmel Studio that are irrelevant to the CLI toolchain.

the .../gcc/dev/<chipname>/device-specs contains specs for the compiler that can go in the existing .../lib/gcc/<version>/device-specs directory. For example, I'll install the ATmega324pb support on my MacOS toolchain install:

sudo cp /Downloads/Atmel.ATmega_DFP.1.2.209//gcc/dev/atmega324pb/device-specs/specs-atmega324pb /usr/local/CrossPack-AVR//lib/gcc/avr/5.4.0/device-specs/

(yeah, I still have my toolchain installed in /usr/local/CrossPack-AVR, even though it's been the Atmel toolchain for a while.)

The ../gcc/dev/<chipname>/avr<n>/* files are the startup and library files, and they can go in .../avr/lib/avr<n>/ :

sudo cp /Downloads/Atmel.ATmega_DFP.1.2.209//gcc/dev/atmega324pb/avr5/* /usr/local/CrossPack-AVR/avr/lib/avr5/

Finally, files in .../include/avr are just the .h files that are normally in .../avr/include/avr/, and you can copy them:

sudo cp /Downloads/Atmel.ATmega_DFP.1.2.209/include/avr/iom324pb.h /usr/local/CrossPack-AVR/avr/include/avr/

And ... I think that's enough. I suppose that this can be done in bulk, but so far I've just done one chip at a time...

oleoleo2

Level: Hangaround

Joined: Tue. Mar 11, 2008

Posts: 176 View posts

Posted by oleoleo2: Thu. Aug 22, 2019 - 03:50 PM (Reply to #8)

westfw wrote:

sudo cp /Downloads/Atmel.ATmega_DFP.1.2.209//gcc/dev/atmega324pb/device-specs/specs-atmega324pb /usr/local/CrossPack-AVR//lib/gcc/avr/5.4.0/device-specs/      
(yeah, I still have my toolchain installed in /usr/local/CrossPack-AVR, even though it's been the Atmel toolchain for a while.)

The ../gcc/dev/<chipname>/avr<n>/* files are the startup and library files, and they can go in .../avr/lib/avr<n>/ :
sudo cp /Downloads/Atmel.ATmega_DFP.1.2.209//gcc/dev/atmega324pb/avr5/* /usr/local/CrossPack-AVR/avr/lib/avr5/
Finally, files in .../include/avr are just the .h files that are normally in .../avr/include/avr/, and you can copy them:
sudo cp /Downloads/Atmel.ATmega_DFP.1.2.209/include/avr/iom324pb.h /usr/local/CrossPack-AVR/avr/include/avr/
And ... I think that's enough. I suppose that this can be done in bulk, but so far I've just done one chip at a time...

Thanks! I have avr-gcc 4.8.1 running at OSX10.6.8. it didn't have a device-specs folder (I made one in the root of the 4.8.1 folder, and followed your instructions, though with the 328pb. It says 'unrecognized argument in option '-mmcu=atmega328pb' (as expected as, I don't know how it should be able to find the folder I created). Do you have any idea, where to place the 'specs-atmega328pb', if it is not in the 'device specs' or where that folder might be hiding?

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 104799 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#10

Posted by clawson: Thu. Aug 22, 2019 - 03:58 PM

You can place the packs where you like because you then tell the compiler where it is with the -B option

ron_sutherland

Level: Posting Freak

Joined: Mon. Nov 12, 2018

Posts: 1070 View posts

Location: Tempe, AZ, USA

#11

Posted by ron_sutherland: Thu. Aug 22, 2019 - 04:45 PM

The option to link to the atpack was not available when I was using avr-gcc 4.8.1. Since moving to the 5.4.0 version, it works fine. I cut most of the files from the pack, so it does not clutter my repository, but I keep the structure, so I know where to look for updates. The link is to one of my projects, for an example:

https://github.com/epccs/RPUpi/tree/master/lib

and a Makefile

https://github.com/epccs/RPUpi/blob/master/BlinkLED/Makefile

my projects: https://github.com/epccs

oleoleo2

Level: Hangaround

Joined: Tue. Mar 11, 2008

Posts: 176 View posts

#12

Posted by oleoleo2: Fri. Aug 23, 2019 - 06:56 AM (Reply to #11)

ron_sutherland wrote:

The option to link to the atpack was not available when I was using avr-gcc 4.8.1. Since moving to the 5.4.0 version, it works fine. I cut most of the files from the pack, so it does not clutter my repository, but I keep the structure, so I know where to look for updates. The link is to one of my projects, for an example:

https://github.com/epccs/RPUpi/tree/master/lib

and a Makefile

https://github.com/epccs/RPUpi/blob/master/BlinkLED/Makefile

Thanks a lot ron_sutherland!

I guess, as long as I can get it to be in the make file, it will be ok :)

Last Edited: Fri. Aug 23, 2019 - 06:57 AM

MattRW

Level: Resident

Joined: Thu. Feb 14, 2019

Posts: 780 View posts

Location: Los Angeles area

#13

Posted by MattRW: Sat. Aug 24, 2019 - 01:41 PM

Are you aware of the avr-lib3 fork? It provides tiny817 support, etc. It also has a script to process atdf files to generate iom*.h files that work with assembly code.

I build gcc8.3.0 and have the devpack installed on the side, so I use -B. I have script that tweaks the device-spec files so that I don't have to add -I or -L flags. In addition I use the gen-ioheader-atdf.py script from the avr-libc fork to generate avr/iom*.h files from the atdf files.

ron_sutherland

Level: Posting Freak

Joined: Mon. Nov 12, 2018

Posts: 1070 View posts

Location: Tempe, AZ, USA

#14

Posted by ron_sutherland: Sat. Aug 24, 2019 - 02:48 PM

I've seen the fork; I guess that is what needs to happen to get things going again, it does seem that savannah and its SVN repo are done, Git is so much better by comparison. I will try to find some time to spin it up. There is also an issue with the Binutils lagging (e.g., avr-size has no clue what a 328pb is.)

my projects: https://github.com/epccs

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 104799 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#15

Posted by clawson: Sun. Aug 25, 2019 - 08:46 AM

If you mean the AVR-size -C patch then I don't thi k that's been updated in almost 10 years has it?

meolsen

Level: Site Admin

Joined: Wed. Jul 27, 2011

Posts: 4040 View posts

Location: Microchip, Arizona

#16

Posted by meolsen: Sun. Aug 25, 2019 - 02:05 PM

avr-objcopy -Pmem-usage ( or objdump ..)

:: Morten

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

oleoleo2

Level: Hangaround

Joined: Tue. Mar 11, 2008

Posts: 176 View posts

#17

Posted by oleoleo2: Mon. Aug 26, 2019 - 08:51 AM (Reply to #12)

oleoleo2 wrote:

ron_sutherland wrote:

The option to link to the atpack was not available when I was using avr-gcc 4.8.1. Since moving to the 5.4.0 version, it works fine. I cut most of the files from the pack, so it does not clutter my repository, but I keep the structure, so I know where to look for updates. The link is to one of my projects, for an example:

https://github.com/epccs/RPUpi/tree/master/lib

and a Makefile

https://github.com/epccs/RPUpi/blob/master/BlinkLED/Makefile

Thanks a lot ron_sutherland!

I guess, as long as I can get it to be in the make file, it will be ok :)

Hm.. still can't get it to work. Maybe it's 4.8.1 not supporting the -B option(?). Or maybe I'm doing it wrong?

avr-gcc -Wall -Os -DF_CPU=16000000UL -mmcu=atmega328pb -B /usr/local/CrossPack-AVR-20131216/avr/include/avr/ -c main.c -o main.o
avr-gcc: error: unrecognized argument in option '-mmcu=atmega328pb'
avr-gcc: note: valid arguments to '-mmcu=' are: .....

Jump To

Search form

Device Family Packs are annoying...

Tags: