ASF - Do folks actually use it?

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

It's been quite a few years since I've done AVR programming and upon return to it, I see there has been quite a bit of enhancements made. So I loaded up AS7 which was a endeavour in itself but I'll leave it at that. The newest thing I noticed is the ASF.

 

I picked up an ATmega328PB Xplained MINI and the ASF doesn't seem to have much support for this board as far as I can tell. I've spent quite a few hours looking over whatever documentation I can find on the ASF and it appears promising but it also seems very confusing at times especially when trying to determine what modules will work with what microcontroller. For my board, it looks like there is only I/O support for it but in any case, I'm wondering what you folks think about the ASF.

 

1. Is it worth the time and effort to learn and use or is it simpler to just create your own code base?

2. One benefit I suppose is that it should help when retargeting code to a different microcontroller. Do you folks find yourselves switching target microcontrollers and reusing code often and the ASF helps in this manner?

3. Do you find that some of the documentation links are broken at http://asf.atmel.com/docs/latest (In particular, the "Reference Manual" is returning a 0 byte PDF document.) Is this even the correct link anymore?

 

I'm really just looking to hear how folks are using it and what they like and dislike about it.

 

Thanks in advance.

 

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

ASF is principally for the "complex" CPUs which basically means everything from Xmega upwards. For tiny/mega it has very little to offer and, frankly, the code tries to hard to be platform agnostic so that what should be a few lines of C turns in 10 levels of nested functions.

 

1) own or one of the many existing tiny/mega specific libs out there - not least of which is the huge library of Arduino support software.

 

2) in reality how often does this really happen? It's a bit of a ball and chain to tie yourself to just on the very distant off-chance that in the future you may move to some other CPU architecture that also happens to have ASF coverage (though clearly the Atmel master plan is to tie you into using ASF so the "next step up" looks most attractive if you stick to Atmel silicon)

 

3) On the whole the documentation maintenance for it is not too bad - but the actual content may leave something to be desired in places.

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

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

The largest known prime number: 282589933-1

Without adult supervision.

Last Edited: Mon. Aug 8, 2016 - 02:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought there would have been many more replies to this but perhaps this means that many are not using it.

 

Clawson - I agree, it seems like it would be too much bloat for small devices.

Torby - I, like you perfer to have no warnings although in most cases I understand what they are and why I'm being warned. But unless there is a reason to leave them in there, why do so? I find many people are just are either too lazy or really don't care since in many cases, the OK. But it makes everyone else that might work on the code someday have to revisit the warnings to determine why they are there.

 

I think I'll just resort to what I was doing in the past which is creating my own definition files and libraries. If for nothing else, I'll know exactly whats going on.

 

Thanks!

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

Torby wrote:

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

 

analogman wrote:
I thought there would have been many more replies to this but perhaps this means that many are not using it.

 

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 would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

jgmdesign wrote:
... for the SAM's without ASF using CMSIS - or something.
There's an instance of that for the ARM Cortex-M7 SAM :

SAM V71 / V70 / E70 / S70 Software Package

http://www.atmel.com/tools/samv71-samv70-same70-sams70-software-package.aspx

There's Imagecraft JumpStart API for a competitor's ARM Cortex-M0 and M3 if willing to change compiler and IDE :

ImageCraft Embedded Systems Tools

Imagecraft

JumpStart API

https://imagecraft.com/technologies/jumpstart-api

 

"Dare to be naïve." - Buckminster Fuller

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

I'm using it. I'm not in professional development though and just use it because it makes simple tasks with lots of peripheral access quite easy to set up and more importantly, well readable. I throw out all the unnecessary header files, the 1000 lines of comments and defines for other platforms and just use the peripheral modules. This makes the main .c Files pretty short and self explanatory. I could write all the functions myself, but with ASF it saves the time of reading up on all the flags and registers that need configuration.

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

analogman wrote:
I thought there would have been many more replies to this but perhaps this means that many are not using it.

I think people only use it when they have to not because they want to. Things like USB on Xmega and UC3 - it would be tricky to do that on your own. So for things like that you are kind of bound to using ASF. But for timers and ADCs and UARTs and stuff I guess most folks prefer the feeling of control that writing their own (efficient) driver gives them.

 

In the realms of tiny/mega, those who want "library code" are almost bound to be using Arduino library code these days which is a rich collection of code and while the odd bit is less than efficient a lot of the external peripheral support libraries are professional grade code.

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

I don't use it.  I started to use it for USB on a SAM3X8C but it was really horrible to use for USB HID devices.  So I binned it and ported LUFA to the SAM3XC instead.

The only time that I look at ASF code these days is to fill in the missing gaps in the device datasheets.

 

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

analogman wrote:
I thought there would have been many more replies to this but perhaps this means that many are not using it.

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

 

Jim - You are absolutely correct. What I meant was that many folks may not be using it much, at least for the smaller devices. The ASF is probably nice in some cases to get up and running quickly and also as example code.

 

But these posts are confirming my thoughts and I thank you all. Like I said, it has been a long time for me and it is really disappointing to realize how much I forgot over the years! Your posts are helping me decide what direction I can go in.

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

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.

 

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

I've used it in production code.

 

For 8 bit the only time I bother is for the USB stack. For 32 bit it's essential.

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

I'm using it on an ARM part right now.  I don't have the time to write all the driver software that I would need for this project so the ASF has been great.  It seems that whatever vendor you choose, there is always some kind of driver and middlware support for their ARM offerings.  On something like the ATmega328 I don't really see the point though.  

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

For my two cents I use it. 

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

It's good for quick start, the documentation isn't horrible, and most of the time you can use the datasheet or examples to get going with it without too much fuss. The only thing that is annoying is when they don't use ASF for the examples and mix custom functions in - not very helpful. Sometimes ASF is pretty bloated as well compared to just doing simple things. 

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

The bloat can definitely muddy the waters.  There has been a couple times that I've had to dig into the drivers which required going four or five header files deep to find what I needed.  It definitely helps if you have a bit of higher level software engineering experience, especially when the documentation is a sparse, as it seems to be for some of the drivers.

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

I'd have to agree with most users here.

It's good for the more complex peripherals like external memories and USB but it's a bit bloated and esoteric in that you have to trawl through header files to figure out some things.

There's the odd infuriating bug still in there too (related dependencies throwing errors at compile time if they're not loaded in the right order).

 

That being said it's better than some other vendor offerings; at least it doesn't have you rolling bones on the floor and bath in chicken blood to figure out how to initialise a given peripheral.

Last Edited: Fri. Aug 19, 2016 - 03:05 PM