Recently I had to work with Atmel START. The basic idea looks promising, a nice GUI to configure the peripherals of your chip so you can start with the actual project faster.
But there are way to many downsides.
It requires a Internet connection
I don’t really understand the whole Idea behind the architecture. It looks like the GUI generates a json which is then send to the Atmel backend that is somewhere on AWS. An archive with source code is generated, downloaded extraced and integrated into the Atmel Studio Project.
There is no offline Workflow. If you want to reconfigure something, you need a internet connection.
Bullshit error Messages
Look for yourself. This is what I got the 2nd time I tried to update a Project. Funny enough, just doing it again made the error go away. Quality software, yay!
There is also the case that the Backend does an Error 500. I have seen this several times, it seems to be triggered by entering weird values into the GUI fields. Like 10Ghz Clock frequency or so.
It is slow as hell
Changing one checkbox takes about two minutes. The loading time of the GUI is already a minute, then the GUI scrolls really slow and is unresponsive. After doing the change, it takes ~20sec until I am back in Atmel Studio and can hit compile.
By now, I have learned to change the C headers directly. But that means also extra work when I want to add another module via START since I need to manually merge the differences between my local files and the generated ones.
The GUI has usability issues
Labes are cut off and are not visible. Why would the Framework set the same Userlabel as the Pin name. If its the same, its redundant.
The Screenspace is not well used. Resizing windows is a PITA because its so slow.
GUI fields description
Here are two prime examples. Why does anyone include a description like this. I can tell this by reading the field name. How about “Checking this box will change the way the divider is calculated. Unchecked means divide by N-1, checked divide by 2^n-1”.
GUI fields functions
The clock divider for DPLL XOSC input does not work inside Atmel START. So all the other modules assume a wrong clock frequency. However, the chip does behave as predicted.
There is also no hint that this divider only applies to XOSC, but not for the GCLK input.
To make tings worse, there is a field called “Reference Clock Source” and one called “Reference Clock Selection”. Really? It doesn’t even make sense after looking into the data sheet.
GUI fields function, again
If there is a checkbox, that disables a function, also disable all the related fields so its obvious to the user that they have no function.
This feature is implemented for most modules, but is missing for the USB Configuration. So the user has no visual hint why the USB descriptors are not working.
Clock Configuration
This is actually pretty nice, to have a schematic on clock distribution. Good start. Next, please add the respective frequency of each clock on its configuration page. The values are already calculated, I can see them in the clock selection dropdown of the usb module. Why not just display the frequency on the GCLK or OSCCONTROL page as well?
There are bugs
Well, all Software projects have bugs. But in this case it really sucks. Imagine spending an hour to get clocking right because the GUI is broken. Then finally hit compile and the code hangs during USB initialization. Looks like the DFLL vs. DPLL decision making does not work. Had to patch this by hand, now its good. But again, I need to redo this patch every time after project reconfiguration. Great.
There is no central place for the code, and thus on issue tracker
So, I have spotted a few bugs. That happens all the time, no big deal. Usual workflow is to create a patch and do a pull request. But not with Atmel Start. There is just nothing one can do. Every other user has to find and fix that issue again and again.
Missing functionality
A few things that hit me on the first day
– NOR-Flash driver only talks QSPI, not ‘regular’ SPI
– There is no CAN driver, only a example for a CAN cip attached via SPI. No use for a CPU with a buildin CAN
– The IP Stack has only LWIP 1.4, even though LWIP 2.x is stable. So no IPv6 support
I can’t go back to ‘regular’ ASF
It looks like newer chips are only supported via START. So I can’t go back to the ‘just have some code and makefiles’ approach of ASF. There is just no support in ASF for newer chips. Now I am stuck with this START shit.
Unfortunately this is a work project, so I can’t choose to have a different CPU. And supporting it in libopencm3 is nothing my employer is willing to spend any resources on.
So I am out of options and stuck with this shit. Even though there are some nice new features, like the generic-io-API for serial connections, … this does no make me happy.
Dear Atmel/Microchip: Please just put the libs on github and attach some Makefiles for ease of use. I promise to send patches 🙂