What is ASF in Atmel Studio all about?

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

What do I use ASF for.  I have never used it, and I noticed it is an option in the VS7 installation.  I chose it, but it probably just makes the installation bigger.  What does it do for me.  I don't get much from Google.  Can one of you smart guys give me quick explanation of what it is good for?

 

Thanks

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

What does it do for me

Unless you are using ARM device or some more complex Xmega it fills all that empty space on you HDD so that the disks don't wobble when spinning, you know load sharing....devil

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

As js says, it's a (hugely over complicated) set of library software for the complex bits of Xmega, UC3 and SAM. Because almost nothing about tiny/mega is complex it has almost nothing to offer for those.

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

Hmmm, maybe I should have left it out of the AS7 installation to save some space.  My workshop computer is a 10" netbook with 2Gb of memory.  O well, too late now.  As I am a simple person, using simple devices, I will probably never have a need to use it, even if I could figure out what it is all about.  Maybe I should have said I am simple minded.  

 

OK, thanks.  I looked at some of the documentation, and it looked like it has library functions to do things I am used to doing manually, and happily so.  I guess I wont worry about it, and just plow ahead as I have been.  Thanks for the input.

js, I have a solid state disk, so I don't have to worry about it wobbling, but thanks for the clear description of what it does.  That is what I was looking for.  cheeky

 

Why doesnt the set of special characters have an omega for Ohm's?, like it shows on the button?

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

Why doesnt the set of special characters have an omega for Ohm's?

I don't understand that, it's all Greek to me....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

ASF provides vendor-supported (in theory) C functions that support nearly every hardware feature of the chips (xMega and ARM, anyway.  Normal AVRs are less supported.)

I find that the "need" to "support every feature", plus attempts to conform to various "coding standards" of dubious merit, results in slow and bloated code.  However, ASF can be useful if you want to start using a peripheral but don't really want to figure our its details (especially for the relatively complex peripherals found in xMega and ARM chips.)  And it's quite nice to have example source code for each peripheral function, even if it's buried in bloat. (although I wish it were easier to browse the ASF code.  AFAICT, the only way to look at it is to add the desired bit of code to a project...)

 

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

westfw wrote:
... Normal AVRs are less supported.)
ASF4 adds some tinyAVR (tiny88, recent reduced core (tiny102, tiny104), tiny 1-series of tiny817, tiny1617, etc) and more megaAVR.

westfw wrote:
... results in slow and bloated code.
For SAM D (ARM Cortex-M0+), ASF4 is reduced usage of flash and greater throughput than ASF3 for some functions.

AVR may be likewise.

westfw wrote:
... AFAICT, the only way to look at it is to add the desired bit of code to a project...)
Same with ASF4.

IIRC there's a thread in the SAM community here about how ASF4 is a part of Atmel START, ASF4 is not a component of Atmel Studio, therefore ASF4 is a configuration control problem for Microchip customers.

 


http://start.atmel.com/ 

Atmel START User Guide

Change Log

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-4E095027-601A-4343-844F-2034603B4C9C-en-US-1/index.html?GUID-DC086BFD-7DA2-43E8-8AE0-457F2351FF4C

Atmel START User Guide

ASFv4 vs ASFv3 Benchmark

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-4E095027-601A-4343-844F-2034603B4C9C-en-US-1/index.html?GUID-FE431B1A-031A-48CC-98AF-6984DC79800E

ASF4 API Reference Manual

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-2A8AADED-413E-4021-AF0C-D99E61B8160D-en-US-1/index.html?GUID-819376C9-5C19-4F1E-9320-ED29CF2A0627

 

Edit : ASF4 API

 

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

Last Edited: Mon. Jun 12, 2017 - 04:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see.  At present I am only using ATmega328P and ATmega1284P.   I looked at the ASF wizard for an ATmega1284P project and there are functions for things like port control and ADC usage and a few other things, most of which I have already functions for or know how to do.  I might find a use for it for calendar, but for the AVRs I am using there is not much there for me I dont already have.  At least I now know what it is and what it is about, so thanks all for that.  If I ever get around to playing with the ARM arduino I bought months ago, and immediately erased the bootloader downloading an AS project, I can see where ASF might be useful.

 

Thanks again.  You guys are so cool.

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

It is basically there to make sure ALL programs have 200 million lines of code, as referred to in another thread.

A simple thing like toggling a pin is wrapped in so many layers of indirection and misdirection and platform-independence  that it takes the best part of a minute to happen, and half your flash memory is gone.

And if you try to trace a function down to the point where it actually does something, you'll have to drop the equivalent of several loaves of bread in order to climb back up to the main process.

NXP/Freescale are just as bad.

It's a bit like Lego, used to be simple building bricks, now you can buy a Lego White House, complete with Lego Trump family, or anything else you care to imagine.

Quebracho seems to be the hardest wood.

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

Of course if you try to use something like USB in an Xmega or UC3 it's probably a God-send. Those are the kind of things you might take centuries to work out by just trying to bang the bits shown in the datasheet without any real idea of how they are inter-related or how the chip designer intended you to make use of them. In theory her knowledge is encapsulated in the ASF code to show the "right way" to do it.

 

But when it comes to toggling an LED the chip designer was clearly having a bit of an off day!

 

They do a very "arduino like" thing where they convert port letter plus pin number into some kind of unique number (so PORTC bit 5 might be 21 or something) then they pass that all the way down through the layers then finally unwind it back to C.5 at the last moment when they need to know is it PORTA, PORTB, or PORTC to make the access to. It's done like this so that if you then move the code to an ARM with 32 bit IO ports that 21 probably becomes PORTA bit 21 or whatever. But it makes for the maddest, most over-engineered looking code imaginable. And just to flash an LED!

 

Similarly they do strange things with things like UARTs so to try and give a "common" interface that could be built virtually identically for AVR, UC3 or SAM they abstract the whole thing so you basically can call the same functions for all. But then it over-complicates the code just for the 0.0001% of users who might ever have thought of taking their AVR code to SAM or whatever.

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

I set up a SAMC20 with USART, SPI, and I2C in "Atmel Start."   The resulting "project" source code was 3.5MB, and the actual functionality (ie tracing down through usart_init()) seemed even less direct than with ASF3.x.   Sigh.

 

(although, a similar setup with ASF3 is about 7MB...)

Last Edited: Mon. Jun 12, 2017 - 10:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Wes,

That is pretty amazing.  I have a fairly large Mega AVR project that uses home rolled functions for I2C, UART, and SPI, and the compiled program memory used is only 17kByte and data memory of 256 bytes.  I have a lot of strings for talking to the program with PuTTY to set up various functionality and to send the results to the screen, but I store the strings in program memory instead of data memory.  When I use data memory it uses up quite a lot of it.  

 

How much program memory does your project end up taking when you build it?

 

When I look at the size of the folder containing my project, which includes all files, including both debug and release builds, the total project the size is 1.5 Mbyte.  3.5Mbyte sounds kind of large.

 

mark

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

AFAIK, this was for an otherwise 'empty" project that would compile to 0 size; Atmel projects apparently include all the .h and .a files that the project might need (2.7MB just for libarm_cortexM0l_math.a, for example)  Both the Start and ASF projects bring in a bunch of CMSIS-like definitions even for peripherals that aren't in use (that's OK.)

(This isn't actually BAD, from a commercial development PoV; you want all your libraries/etc under version control somehow, and disk space is really cheap these days.   But it sure LOOKS depressing.)

 

The Atmel Start code seems to come in three layers: hal, hpl, and hri.  hri_sercom_c20.h is ~250k, much of which looks like machine-generated functions to access every bit of every register in every possible way.  You know, because you can never tell when someone will want to toggle some of the bits of the fractional BaudRate :

static inline void hri_sercomusart_toggle_BAUD_FRAC_reg(const void *const hw, hri_sercomusart_baud_reg_t mask)
{
	SERCOM_CRITICAL_SECTION_ENTER();
	((Sercom *)hw)->USART.BAUD.reg ^= mask;
	SERCOM_CRITICAL_SECTION_LEAVE();
}

(much of it "static inline", so it's not going to take any real application space.  But it diminishes the usefulness of "look at the source code."  Sigh.)

 

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

Hello guys,

 

A little word of defense for the ASFx.

 

Here are the reasons I see beneficial for the architecture/abstraction like ASF offers:

1. Application code will()should idealy deal with only HAL_ layer of the abstraction, which makes it easier to migrate the application logic to a new platform. Critical for all commercial products. Shame that ASFx is vendor-specific, though.

2. Writing code (application level) using ASFx, kind-of forces the common code notation, making the code more pleasant to read. Mega-important for teams where code review is a part of the process (should be everywhere, where the budget permits)

3. Easier to write and re-use unit tests for the code that uses "common libraries", not necessarily ASFx.

4. Unified documentation - almost Microsoft-like experience to quickly find the details of defines, function params and return values. I can not even dream to expect something like that from self-written libs. Not in hobby environment - for sure.

5. Let.s agree - it is way too expensive to dig into each bit of each peripheral register. It is fun, no questions asked - to know you hardware inside-out, but not viable in commercial software development. We have just reached that point in technology evolution. ASF is an attempt to fix the time-to-market problem.

6. Who cares how much source code will be there (generated?) if the resulting binary is comparable to the one built from manually written code.

 

To conclude - I am not a fan of such framework myself, but from the other hand - can't afford even to read the reference manual completely (like I did for, 2313, 8515 back in the days). And it equally applies to Tinny/AVR/U3Cs - just because that time accumulates into a "part-of-life where I read the pdf". I would rather invest that time in reading the USB or ARM's AMBA spec. It will be at least more widely applicable.

 

Just my 5 cents, no intentional contradiction was meant.

 

Regards

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

0Pal wrote:
which makes it easier to migrate the application logic to a new platform. Critical for all commercial products
I've worked in consumer electronics for almost 40 odd years and I have never seen this as a requirement. What I do see is HAL layers making hugely inefficient and bloated code. That maybe doesn't matter on GHz processors with MBs or even GBs of memory. But it does matter on 1/2/4/8/16K micros which is the priniciple focus of this message board.
0Pal wrote:
kind-of forces the common code notation,
You don't need to use a library to do that - just apply a coding standard and have all the staff on the project follow it.
0Pal wrote:
Easier to write and re-use unit tests
Why are unit tests any easier to write for library code compared to your own authored code?? If this is the caseyou are not writing your own code correctly. In fact modern thinking is that unit tests should be implemented first then you write your own code to match the APIs they expect.
0Pal wrote:
Unified documentation -
A well engineered project is almost certainly going to be applying Doxygen whether a 3rd party library is involved or not - so how is ASF in any way instrumental in making this happen?
0Pal wrote:
it is way too expensive to dig into each bit of each peripheral register.
Expensive on what scale? Certainly not personal knowledge. Later , when the thing does not work right, you understand ALL the code because you wrote it all and you understand the peripherals at the bit/byte level. If you have some 3rd party library you can't know whether the faults are in your own code or the library and, if the latter, how do you fix it when it is not code you are familiar with?
0Pal wrote:
Who cares how much source code will be there
Say I am making 5 million microwave ovens. I have the option of using a mega88 or a mega168 micro. The code is 8200 bytes. With my own code and a bit of optimisation I can maybe shave that back to 8192 bytes. So now I can buy the 8K micro at $0.90 instead of the 16K micro at $1.05. So I just saved $0.15 * 5,000,000 = $750,000. If you cannot see the reason I might want to be in control of code size to say $0.75m then I'm guessing you aren't involved in volume engineering. Sure if you make 500 units per annum using AVR then it's $0.15 * 500 = $75 - just the cost of a decent meal - in which case, no you don't care about shaving 100+ bytes, but many here do. (personally I have only been involved in products using AVRs up to about 2,000,000 unit/annum (for any particular model) but we've still saved a few $100,000 along the way by picking the right components).

Last Edited: Fri. Oct 12, 2018 - 01:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@clawson, Thanks for taking the time to consider my notes and commenting on them. It seems that you do talk from experience, which is always a thing to respect. Unfortunately I am not as long in the game as you (some 15 years, I think - not more), so my take on the subject can be somewhat naive.

 

However, I will dare to comment on your comments. Again - do forgive my naivety.

 

clawson wrote:

0Pal wrote:

which makes it easier to migrate the application logic to a new platform. Critical for all commercial products

 

I've worked in consumer electronics for almost 40 odd years and I have never seen this as a requirement. What I do see is HAL layers making hugely inefficient and bloated code. That maybe doesn't matter on GHz processors with MBs or even GBs of memory. But it does matter on 1/2/4/8/16K micros which is the priniciple focus of this message board.

I have seen such a requirement (to keep the application code as generic as platform-independent as possible) three times in my short practice. One of the three it was a mighty PPC-based hardware, where the resources were not an issue, so this might not necessarily count. Anyways - in all three cases the objective was to have a line of products (from "light" to "pro" edition) with the same code and features just "compiled out" at build time. The "Pro" options were the convenience features (color terminal for an agriculture appliance instead of 7 segment-based one, for instance). Obviously the hardware was different (same MCU series with less IO and peripherals for the "lighter" versions of the product).

I think in 40 years of your professional experience you did see this approach in consumer electronics project for sure. The advantage of generic code base is rather obvious.

clawson wrote:

0Pal wrote:

kind-of forces the common code notation,

 

You don't need to use a library to do that - just apply a coding standard and have all the staff on the project follow it.

I can not agree with you more here. Unfortunately, it is easier said than done - if nobody controls it, the coding guidelines will "drift". I am not saying that the library's header files and naming convention will improve such cases, but for people who are used to some guidelines that would be an encouragement. Take as an example how MFC, STL or linux stdlib unintentionally implies similar coding style. Also standard libs that come with compilers have strong impact on how the code will be written.

 

Besides, you have to have the right to insist, to enforce certain restrictions in the team, human factor and such. Whereas some external framework is being considered as an "external force/limitation"

clawson wrote:

0Pal wrote:

Easier to write and re-use unit tests

 

Why are unit tests any easier to write for library code compared to your own authored code?? If this is the caseyou are not writing your own code correctly. In fact modern thinking is that unit tests should be implemented first then you write your own code to match the APIs they expect.

My thinking was that for the unit tests based on the code that uses ASF-like frameworks you will mock the library functions and reuse them within the team as an extension of the framework itself. Whereas, mocks of your own home made libs will be harder to establish as something others should follow. It will always be a subject to speculations. ASF is externally maintained, so changes to interfaces and definitions are external circumstances and not a subject for discussion. To mock certain driver, for example you need the interface from the framework. Clear for everyone, no discussions, does not work some other way.

 

May I ask for a reference to a source where it is recommended to write unit tests first? I am definitely lagging behind the modern dev. practices (thanks in advance).

clawson wrote:

0Pal wrote:

Unified documentation -

 

A well engineered project is almost certainly going to be applying Doxygen whether a 3rd party library is involved or not - so how is ASF in any way instrumental in making this happen?

But you need to do that yourself for the libraries you develop locally, whereas ASF already has it and to the greater extent. Even if you manage to figure out the budget for the documentation - it is still a question of ones's persistence to document every bit of the functionality.

I must admit, I don't fill very lucky here - on number of projects the question of documentation and even re-usability was up to me, and I actually compromised these on some occasions in favor of unit tests (saying to myself: "yeah, it is clear from the test how to used this functionality"). Guilty, I agree.

clawson wrote:

0Pal wrote:

it is way too expensive to dig into each bit of each peripheral register.

 

Expensive on what scale? Certainly not personal knowledge. Later , when the thing does not work right, you understand ALL the code because you wrote it all and you understand the peripherals at the bit/byte level. If you have some 3rd party library you can't know whether the faults are in your own code or the library and, if the latter, how do you fix it when it is not code you are familiar with?

As I said, the time of in-depth understanding is gone (as once programming in op-codes and punch card is gone forever). The reason is ever growing complexity of tasks we are facing. Quickest possible turnaround is everything now. The 50% chance that I stuck with the bug I don't understand is the risk most of my customers are willing to take. Picking a good framework makes that probability lower (with bigger community using the same framework, it is).

My customers mostly don't care if I understand how the device works, as long as it does what it is supposed to do.

I need to say, I trust more third party community driven/tested code than my own. I from my side do my best to report back the misbehavior of some library code and patches, not only for me to get it fixed, but for others that potentially stumble across the same issue. Others contribute their stuff too. Low intelligence and scattered knowledge of basics, you will argue - you a re right, but that is how it works, from my observation (generation-specific paradigm shift?).

clawson wrote:

0Pal wrote:

Who cares how much source code will be there

 

Say I am making 5 million microwave ovens. I have the option of using a mega88 or a mega168 micro. The code is 8200 bytes. With my own code and a bit of optimisation I can maybe shave that back to 8192 bytes. So now I can buy the 8K micro at $0.90 instead of the 16K micro at $1.05. So I just saved $0.15 * 5,000,000 = $750,000. If you cannot see the reason I might want to be in control of code size to say $0.75m then I'm guessing you aren't involved in volume engineering. Sure if you make 500 units per annum using AVR then it's $0.15 * 500 = $75 - just the cost of a decent meal - in which case, no you don't care about shaving 100+ bytes, but many here do. (personally I have only been involved in products using AVRs up to about 2,000,000 unit/annum (for any particular model) but we've still saved a few $100,000 along the way by picking the right components).

Very illustrative calculations indeed. Unfortunately, I personally never worked on the products of such volume. I do however believe they exist.

 

As for the cost calculations - I think you skipped the development time, especially higher salaries for software developers capable of squeezing more from less. Such experts are often very cool to work with but expensive for the projects. So, my naive thinking again - I would prefer to invest in hardware that is capable of Python code interpretation (if the task permits, of course), have more external independent hardware like ADCs or external FLASH connected over SPI/I2C, have couple of students to get that working in Python, rather than very skilled C coder with deep understanding of analog electronics that will manage to figure out everything on cheapest  MCU possible. The code will be hard to maintain (without that knowledge, no meter how clear it was written) and the guy will cost more and will be difficult to replace.

 

Sorry once again for probably immature opinions, but that is how I understand the niche ASFx was meant to occupy.

 

Regards and I look forward to your thoughts.

 

 

 

 

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

But if you are making 2,000,000 units/annum then even the most expensive engineer at, say, $160,000/annum costs just $0.08 per unit when you amortise his salary over the production run. So it's worth paying for some quality engineering! That $0.08/unit may have bought you the $0.15 saving!

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

0Pal wrote:

May I ask for a reference to a source where it is recommended to write unit tests first?

 

Search for Test-Driven Development (TDD).  Also Extreme Programming and Agile.

 

0Pal wrote:

My customers mostly don't care if I understand how the device works....

Low intelligence and scattered knowledge of basics .... (generation-specific paradigm shift?).

 

 

Witness the rise of the "Full Stack Developer."

 

0Pal wrote:

I would prefer to invest in hardware that is capable of Python code interpretation ...

 

Circuit Python / Micro Python came up as a topic a few weeks ago.  Python interpreter on

a 32-bit micro available at Adafruit.

 

--Mike