We have been developing products around ATSAM processors for severals years, over which time we and our partners have purchased tens of thousands of ATSAM processors for these designs. Previously we used ASF3. Although the code quality left something to be desired, on the whole we are happy with it and we could work around the issues we came across.
We now have a new design using an ATSAME5x processor. When we chose this processor, we didn't realise that ASF3 doesn't support it. It appears that we are forced to use Atmel START. This has caused us several problems (see #3 and #4 for the ones that are causing us the greatest trouble):
#1 Our firmware is open source, which means that Windows-only tools such as Atmel Studio are not acceptable to a large part of the community. We develop our firmware using Eclipse and the ARM Developer build of gcc. If Microchip values the open source community, they should make provision for users who do not wish to use Atmel Studio or other proprietary and platform-specific tools.
So my plan was to create a basic project in ASF/Atmel START incorporating all the drivers we are likely to need, then move the files to Eclipse and continue development there. This showed up a couple of other issues:
#2 The #include file mechanism used by ASF is appalling. For every single Atmel START component that I want to use, the code generator adds the include path to the directory containing that component. This is appallingly bad programming practice for two reasons. First, it makes maintaining the include paths difficult. Second, it increases the chance that there will be a name clash between an Atmel START include file and one of the developer's own include files, which will likely result in the wrong include file being picked sometimes.
Fortunately this can be resolved quite easily. In the Eclipse copy of the project I've moved all of the Atmel START stuff into a folder called AtmelStart and included that folder in the path. Then in a few of the atmel start files I had to change e.g. #include <hpl_tc_base.h> to #include <hpl/tc/hpl_tc_base.h>. In a few other places I changed from <> to "" in the #include directive so as to include the source file directory in the include path.
#3. The clock configurator in Atmel Studio is broken. I want to configure the clock system to generate a 120MHz CPU clock derived from XOSC0 which uses a 12MHz crystal. Configuring XOSC0 is on problem. There seems to be zero documentation in Atmel Studio on how I should generate a 120MHz CPU clock from a crystal oscillator (there is a User Guide button on the Atmel START page but clicking on it does nothing). From the chip datasheet it looks like I can do it by feeding XOSC0 into DPLL0, then feeding DPLL0 into generic clock generator 0. So I need to configure DPLL0 to multiply the input frequency by 10. However, when I click on Settings for DPLL0, it will allow me to delete the digits in the multiplier and fractional multiplier fields, but it won't allow me to enter any new digits. I updated ASF to latest available version yesterday, the version reads 7.0.1931.
#4. So to get round #4 I tried deleting just one digit from the multiplier field to get a multiplication of 14. The clock configurator says this will give me a clock frequency of 180.75MHz, but I should be able to edit the multiplier in the generated code So I click on Generate Project and get this every time:
Could not download contents from the server.
Exception thrown: the remote server returned an error: (500) Internal Server Error
The same happens if I delete 2 digits to get an integer multiplier of 1. I have not found any way of configuring DPLL0 that doesn't give the server error message.
#5. The compiler.h file still has macro definitions of 'min' and 'max' in it. These are an abomination in C development, and they break C++ compilation if you use certain standard header files. Use 'Min' and 'Max' macros if you really must. In ASF3 we were able to remove these macro definitions and change the few references to them in other ASF files to use Min and Max instead. In START we don't know what code the tool may generate that calls min and max.
In summary, I am getting p****d off with Microchip forcing me to use a broken tool with no alternative provided, and I am looking at STM32 processors for future designs. Our familiarity with the ATSAM peripherals and ASF have kept us using ATSAM processors so far, but that advantage is largely gone for processors not supported by ASF3, because START is not an adequate replacement.
One area which does appear to have improved over ASF3 is that frequently-used very short functions such as _gpio_set_level are now declared 'inline', which should avoid the need to use our own fast I/O functions in some cases. Although ASF4 possibly goes too far the other way by declaring some rather complex functions 'inline'.
