I'm new in the world of ARM microcontrollers. I usually worked with simple 8-bits products (AVR, PIC) and I used to set manually every bits of registers.

I understood SAM D20 micros are much more complex to configure (system clock, clock generators, clock multiplexers, ...) so Atmel tries to help the developer with the ASF framework, providing high-level APIs to configure and use the peripherals.

I started with SERCOM USART peripheral with callbacks, but the first impression isn't good. First of all, the library is very fat and I think it consumes Flash memory: just to configure some bits in peripheral registers, I have to retrieve the default configuration, change it in RAM and set it in the register.

Moreover I used to manage the UARTs in a different way. I have two FIFOs (uint8_t arrays), one for tx and one for rx. The receiveing ISR push data into FIFO rx. The transmitting ISR pop data from FIFO tx.
usart_read_job() and usar_write_job() don't match exactly with my scheme. I have to think more how to adapt those functions to my scheme.

Anyway one doubt arose in my mind: is ASF the right approach? Could it be better to study peripheral registers and use them manually without ASF? Is this a too much complex approach?

pozz,
I think the ASF is an ideal approach for those that want to have a significant degree of control over the micro without having to spend many hours looking at the datasheet. It's also guaranteed to work as its provided by Atmel and should offer a 'fast-to-market' and 'safe' option for commercial developers.

The catch is that you still have to read the 397 ASF API manual (which is very well written by the way) and you do lose some fine degree of control over the hardware.....not as much as what you lose by using say an Arduino like API....but you still don't have as much control as you would with a register-based approach. In addition the ASF will obviously cause a large degree of code bloat.....

I think the ASF is a great idea..but I do think that having register-based code snippets in the Datasheet or somewhere ...is also great for those of us who prefer to have a higher degree of control over the D20/21's peripherals.

ST did this .for about a decade they only had their Peripheral Library available for the STM32 micros....but now they have register-based code snippets in the appendix of the user manual...

I'd really like to see Atmel take this approach (offering both options) as well without having to wait a decade..

It's also guaranteed to work as its provided by Atmel and should offer a 'fast-to-market' and 'safe' option for commercial developers.

Are you sure? It seems ASF has a certain amount of bugs.

I've discovered one in a small amount of time. Try to use CMSIS math APIs directly in a ASF-based example project for D20. The compiler complains because it can't found "core_cm0.h" that is referenced in "arm_math.h".

Indeed, I don't know why, but "arm_math.h" copied in the project source subfolders isn't current, but an old one that doesn't manage correctly M0+ core.

I didn't read the license because I frankly don't care much for the ASF and will probably never use it. I prefer a register-based approach....I used the register-based approach with PICs, AVRs, STM32s and will continue to do so with the ATSAMD20/21

What I meant to say is that Atmel (the guys who fabricated the chip) wrote the framework and have a vested interest in supporting it and encouraging others to use it.

It'll probably have less bugs in it than some random code snippet of the web.....or at least thats what one would hope for.....