Device Family Packs are annoying...

Go To Last Post
8 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...