AVR Freaks

I don't use ASF.

I was at one of the "Atmel Tech On Tour" sessions a few years ago where we used it to play with the SAM D series parts. I got a cute little development board for going. It seemed harder to figure out all the parameters and defines you have to put to use a peripheral than to actually set the registers and use it. Also, the ASF code was full of compiler warnings. Now, my C magery isn't good enough to know an acceptable warning from a bad warning, so I treat them like errors and correct them, so warnings in library code that I don't understand and would have to tediously trace out frighten me more than the vacuum cleaner.

Learned some cool tips about power saving in battery applications. Things like, "run things fast and sleep whenever you can," "use the peripherals to do as much work as you can so the cpu can stay asleep" and "never ever leave an input pin float."

+1

Or you are asking in the wrong community forum,  As Cliff and Torby noted ASF is for XMEGAS and up. 

I myself have used.....err tried to use it on several occasions.  Many times to get my head wrapped around using an ARM processor, but as Tom noted it's bloody intense to set up a simple read port, write to another port, or just set up a few registers.  Where I did use it and good thing was for a Qtouch project that never went anywhere.  There was no way I could have gotten it to work with the SAM device without ASF.

NOw there are powers far greater than me that can write code for the SAM's without ASF using CMSIS - or something.  One of these folks was nice enough to give me a small snippet of code to get me going and I thought it amazing that his code was a small couple K and the ASF equivalent took up 20k of flash....to make an up counter and display the binary result on a port.

JIm

I use it for peripherals I have not yet written my own drivers for.  I prefer to write my own because the code is much, much cleaner and easy to follow.  ASF code has layers and layers of macros, and header files that include header files that include header files...  While this may make the code less platform-dependent, it makes the code somewhere between difficult and impossible to follow.  When writing my own drivers, I frequently rely on ASF code to see how a peripheral works when the manual is unclear, provided the ASF code isn't so unclear I can't make heads or tails of it.