AVR Freaks

You would get all info from building a project in Atmel Studio first and save the output from a build. The include paths, compiler options, startup code and linker script location will be visible in the build output.

/Lars

The cycle_counter path is from the standalone ASF 3.33.0 that can be downloaded from:
http://www.atmel.com/tools/avrso...

The two files are basically like this (no idea whose github project is that):
https://github.com/marekr/asf/bl...
https://github.com/marekr/asf/bl...

Using ASF without AS sounds like torture, since AS normally copies individual asf files into your project, rather than referencing them via a long string of include paths.

I haven't used "Start" (ASF4) enough to see how/whether it's different in that respect from the previous versions.  ASF3 used to bring in 1k+ of code to initialize clocks...

Hmm.  That would be the "cycle counter" and "basic delay" code that I earlier complained was lacking in any connection to reality?

https://community.atmel.com/foru...

(actually, this looks somewhat better than the code I quoted.  Perhaps it's been fixed?)

At least a 5-cycle loop, so "cycles" isn't CPU clocks...

void portable_delay_cycles(unsigned long n)
{

    __asm (
        "loop: DMB    \n"
        "SUB r0, r0, #1 \n"
        "CMP r0, #0  \n"
        "BNE loop         "
    );
}

MAYBE the weird constants here correct for that?

#define cpu_us_2_cy(us, f_cpu)  \
    (((uint64_t)(us) * (f_cpu) + (uint64_t)(7e6-1ul)) / (uint64_t)7e6)

This is an interesting thread. I usually start with ASF example project and, step by step, extract useful code from ASF, greatly simplify it and move in my folders (usually ports/sam/...).

Most of the time I'm able to exclude completely ASF files. The only ASF files I need (moved in my folder) are the following:

- syscalls.c file (I don't know exactly why)

- cmsis folder (there are some useful ARM-standard macros here, for example those related to SysTick)

- utils/cmsis/samdxx folder (all the symbols and register definitions for the chosen MCU)

- linker script

With those file, moved in my folder, I could have a project that doesn't need ASF files at all.

Regarding initialization, you need to configure clocks and peripherals.

If your application can run with internal oscillator, it's enough (this is the default at startup). Otherwise you need to configure and enable the oscillator (XOSC, XOSC32, ...) and at least a Generic Clock Generator 0 that feeds the ARM core.

For example, if you have the classical configuration with a crystal connected to XOSC:

SYSCTRL->XOSC.reg = SYSCTRL_XOSC_XTALEN | SYSCTRL_XOSC_STARTUP(0xF) | SYSCTRL_XOSC_GAIN(3);
SYSCTRL->XOSC.reg |= SYSCTRL_XOSC_ENABLE;
    while(!SYSCTRL->PCLKSR.bit.XOSCRDY)
        ;
GCLK->GENCTRL.reg = GCLK_GENCTRL_ID_GCLK0 | GCLK_GENCTRL_SRC_XOSC | GCLK_GENCTRL_GENEN;

Maybe you need to change wait state for Flash access (the number of wait states depend on the frequency): 

 NVMCTRL->CTRLB.bit.RWS = 1;     // 1 wait-state for Flash access

Regarding peripheral. I wrote some simple inline functions for managing GPIO (all the pins are GPIO at startup, so you don't need to mess with I/O multiplexing for GPIO use):

#include "samd20.h"

static inline int
pin_get_group(uint8_t pin)
{
   return pin / 32;
}

static inline int
pin_get_num(uint8_t pin)
{
   return pin % 32;
}

static inline void
pin_set_output(uint8_t pin)
{
   uint8_t group = pin_get_group(pin);
   uint8_t pinnum = pin_get_num(pin);
   PORT->Group[group].PINCFG[pinnum].reg = 0;
   PORT->Group[group].DIRSET.reg = (1 << pinnum);
}
static inline void
pin_set_output_level(uint8_t pin, uint8_t level)
{
   uint8_t group = pin_get_group(pin);
   uint8_t pinnum = pin_get_num(pin);
   if (level) PORT_IOBUS->Group[group].OUTSET.reg = (1 << pinnum);
   else       PORT_IOBUS->Group[group].OUTCLR.reg = (1 << pinnum);
}

static inline void
pin_set_input(uint8_t pin)
{
   uint8_t group = pin_get_group(pin);
   uint8_t pinnum = pin_get_num(pin);
   PORT->Group[group].PINCFG[pinnum].reg = PORT_PINCFG_INEN;
   PORT->Group[group].DIRCLR.reg = (1 << pinnum);
}
static inline void
pin_set_input_pullup(uint8_t pin)
{
   uint8_t group = pin_get_group(pin);
   uint8_t pinnum = pin_get_num(pin);
   PORT->Group[group].PINCFG[pinnum].reg = PORT_PINCFG_INEN | PORT_PINCFG_PULLEN;
   PORT->Group[group].OUTSET.reg = (1 << pinnum);      /* Imposta pull-up */
   PORT->Group[group].DIRCLR.reg = (1 << pinnum);
}
static inline void
pin_set_input_pulldown(uint8_t pin)
{
   uint8_t group = pin_get_group(pin);
   uint8_t pinnum = pin_get_num(pin);
   PORT->Group[group].PINCFG[pinnum].reg = PORT_PINCFG_INEN | PORT_PINCFG_PULLEN;
   PORT->Group[group].OUTCLR.reg = (1 << pinnum);      /* Imposta pull-down */
   PORT->Group[group].DIRCLR.reg = (1 << pinnum);
}
static inline uint8_t
pin_get_input_level(uint8_t pin)
{
   uint8_t group = pin_get_group(pin);
   uint8_t pinnum = pin_get_num(pin);
   return 0 != (PORT_IOBUS->Group[group].IN.reg & (1 << pinnum));
}

Remember to activate continuous input sampling on input pins, otherwise you can't read their state with IOBUS access (I usually enable continuous input sampling for all the pins at startup):

PORT->Group[0].CTRL.reg = 0xFFFFFFFF;
PORT->Group[1].CTRL.reg = 0xFFFFFFFF;

If you need to change the I/O multiplexing of a pin, I usually use the following:

/* First 16 pins (Px00-Px15) */
PORT->Group[0].WRCONFIG.reg = 
    PORT_WRCONFIG_WRPINCFG | 
    PORT_WRCONFIG_WRPMUX | 
    PORT_WRCONFIG_PMUXEN |
    PORT_WRCONFIG_PMUX(PORT_PMUX_PMUXE_D_Val) | (1 << <pin number>);

/* Last 16 pins (Px16-Px31) */
PORT->Group[<port>].WRCONFIG.reg = 
    PORT_WRCONFIG_HWSEL | 
    PORT_WRCONFIG_WRPINCFG | 
    PORT_WRCONFIG_WRPMUX | 
    PORT_WRCONFIG_PMUXEN |
    PORT_WRCONFIG_PMUX(PORT_PMUX_PMUXE_D_Val) | (1 << (<pin number> - 16));

<port> is the number of the port (PAxx is port 0, PBxx is port 1)

<pin number> is the number of the in the port (Px03 is 3, Px15 is 15)

Of course you need to change PORT_PMUX_PMUXE_D_Val with your multiplexing configuration.

There other methods to configure I/O multiplexing, for example to change the configuration at a group of pins at the same time. However I always use the previous code without any problems.

Now there are many many peripherals. I try to write simple drivers for my needs. For example for SERCOM/USART, DAC, ADC and so on. The callback drivers present in ASF are very very bad, in my opinion.

Even if I am usually able to avoid ASF at all, I still use Atmel Studio 7. I never tried, but I don't think it's difficult to compile and link the project with command line tools (or external IDE, such as CodeBlocks or Emacs or Eclipse). The Makefile used by Atmel Studio is present in the output directory, so you can copy and use it.

What stops me to abandon Atmel Studio is debugging. With the small monster MCUs you need a good debug support. It's very useful to see register contents, memory (Flash and RAM) contents, put breakpoints, run a single step and so on. How could you have the same things with an external tool that isn't made by the silicon manufacturers?