Device Family Packs are annoying...

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

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.)

 

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

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. ;-)

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

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

Why does that make it impractical?

 

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

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.

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

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:

  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

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.

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

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:

  1. Tend to have restrictions on who can re-distribute them.
  2. have extensive dependency hell associated with them.
  3. 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.

 

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

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...

 

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

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?

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

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

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

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

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

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

 

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

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.)

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

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

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

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

:: Morten

 

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

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

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: .....