Atmel Software Framework and other libraries

[jackbob]

After finally breaking away from the Arduino programming environment and libraries I recently switched to programming microcontrollers standalone using Atmel Studio and found it rather interesting and you gain a lot more of an understanding of how the microcontroller works when you are manipulating the registers yourself. Its adifferent environment than Arduino for sure and can get a little complex and confusing at times but its manageable. After working with just about every peripheral on the ATmega328p I thought I would take a step up and program a real microcontroller. I grabbed my Arduino Due and took a look at the datasheet for the SAM3x8e and let me just say I was intimidated at the least. It seems with a microcontroller of this caliber it would be impossible to do everything manually by manipulating registers like you can in the ATmega 328p and libraries seem to be necessary to be able to tackle some of the peripherals on this beast. I immediately think of ASF but have never used it before so i gave it a try on the ATmega328p and it has an even steeper learning curve than manipulating registers manually.

I did a little searching on the forums and foud this
https://www.eevblog.com/forum/microcontrollers/atmel-software-framework-(asf)/msg696814/#msg696814

It seems as if many people discourage the use of ASF, even on AVR freaks people recommend to steer clear of ASF if you can. The documentation for ASF is horrible and i find myself analyzing the source code of the ASF trying to figure out how to use it because the documentation is so poor, which is a surprise because after reading through almost every page of the ATmega328p datasheet I found it extremely clear.

So my question... When using microcontrollers as complex as the SAM3x8e or other similar families, are there libraries besides ASF and obviously arduino(which is primarily based around ATmega series) which can be used to program these microcontrollers? Does anyone here have any experience programming microcontrollers of this size "manually"? Are they easier to program manually than I make it seem or are they considerably difficult to program in this manner? It just seems extremely tedious and inefficient to be not using libraries when programming a microcontroller of this size. What is the industry practice for these? In the thread I posted above it appears as if ASF is not used much by industry, I can see why too. But if ASF is not used what is?

Sorry for all the questions but it seems as if the hobbyist community for microcontrollers only works with simpler ATmega or similar microcontrollers and once you get into the more complex microcontrollers, the support and commuinty just shrinks and drops off (reminds me of working with FPGA's) Anyways I'm sure there are a few engineers here who work with these devices for a living and would be able to shed some light on the topic. Thanks!

[dannyf]

There is value in using a vendor library. They tend to be compatible over a wider range of platforms and once the library is updated to support newer chips, your code written on the library autatically covers the new chips, without you lifting a finger.

Libraries present two main issues from a developers perspective:

First, once you use it, you are locked into it. Your code will be difficult to move to a chip from a different vendor, for example

The initial investment can be significant to get up the learning curve.

People may argue about performance hit but that has not been my experience.

My solution is simple: write your code using a layer of your own library. Your middle ware allows your code to be fully independent of any vendor libraries and gives you the flexibility to replace pieces of the library with your own code pieces for speed or bug fixes.

Until recently, I wrote most of my mc code on turbo C, or an old version of keil c51. Those pieces of code run flawlessly on arm chips and msp430, once I link in the right middle ware plus libraries.

[ataradov]

So my question... When using microcontrollers as complex as the SAM3x8e or other similar families, are there libraries besides ASF and obviously arduino(which is primarily based around ATmega series) which can be used to program these microcontrollers? Does anyone here have any experience programming microcontrollers of this size "manually"? Are they easier to program manually than I make it seem or are they considerably difficult to program in this manner? It just seems extremely tedious and inefficient to be not using libraries when programming a microcontroller of this size. What is the industry practice for these?

It only looks like they are complex. They are more powerful, yes, and that requires more configuration options. Otherwise they are not that much harder to code directly than ATmega.

The only thing that can be hard is USB, but even that is solvable.

The amount of low-level code does not change much with device size. With bigger devices you are likely to use bugger libraries (FatFS, LwIP, FreeRTOS, etc), which are mostly cross-platform.

[dannyf]

"if the hobbyist community for microcontrollers only works with simpler ATmega or similar microcontrollers"

Some mcus like pic are popular in the US or the west because back then that was all there was.

If you go visit places like china, many more people program stm32 chips - because that is whats widely available there and what's what whey work on professionally.

[jackbob]

My solution is simple: write your code using a layer of your own library. Your middle ware allows your code to be fully independent of any vendor libraries and gives you the flexibility to replace pieces of the library with your own code pieces for speed or bug fixes.

When you say "using a layer of your own library" are you referring to a library I may have created myself using lower level C for example? And what do you mean when you refer to "middle ware"? I have never heard of this.

[Sal Ammoniac]

My solution is to write all of my own peripheral libraries from scratch. No vendor code at all. I've done this for STM32F4, LPC176x, LPC43xx, PIC32MX, and several others.

Sure, it's a lot of work, but I'm intimately familiar with the code, it does exactly what I need it to do and no more, and if something doesn't work, I know exactly where to look.

[jackbob]

They are more powerful, yes, and that requires more configuration options. Otherwise they are not that much harder to code directly than ATmega.

The only thing that can be hard is USB, but even that is solvable.

The amount of low-level code does not change much with device size. With bigger devices you are likely to use bugger libraries (FatFS, LwIP, FreeRTOS, etc), which are mostly cross-platform.

I suppose you are right, also this chip is 32 bit which is a little bigger than the 8 bit I am used to so registers are much larger, but essentially the same thing. The most confusing part about this particular chip is the ARM processor mixed in. This confuses measures more and it is no longer similar on a lot of levels when compared to say a standalone 32 bit mc.

[ataradov]

ARM processor mixed in

How is ARM core more confusing than AVR? General MCU architecture is essentially the same - you have a core connected to peripherals via buses.

With ARM you have more control over bus behavior and generally more things exposed, but it is a good thing. And of you don't have specific need to mess with it, then just don't. Typically defaults are good enough for normal MCU operation.

[rx8pilot]

I took a brief look at ASF but decided not to pursue them as they seemed complicated. If I can't understand it, I was afraid of getting into to trouble. I dug up all sorts of bits and pieces from the web and glued them together with my own code. In the end, I learned a lot and code much better now. For the libraries I use, I really know how they work and how they fail.

Not necessarily advocating that route since it was slow and painful. When I was initially learning uC coding, I needed to make functional code and step up my coding skills at the same time. So far, I have not known anyone to make use of the ASF and I feel that I have asked a lot of people.

Going from Arduino to C is a great and fun step for many. All you limitations are removed and you can really push the hardware to the max.

[jackbob]

My solution is to write all of my own peripheral libraries from scratch. No vendor code at all. I've done this for STM32F4, LPC176x, LPC43xx, PIC32MX, and several others.

Sure, it's a lot of work, but I'm intimately familiar with the code, it does exactly what I need it to do and no more, and if something doesn't work, I know exactly where to look.

This is quite a bit of work but seems worth it for sure. I have written small uart libraries for the ATmega328 and its much more comfortable and easy using libraries which I written myself. Also I know exactly what is happening and have a better idea of how many clock cycles and resources my own libraries take up rather than using someone else's.

[ataradov]

This is quite a bit of work but seems worth it for sure.

You do it once and then mostly reuse. If you look at a number of peripherals a typical MCU has, it is not that much. And all devices from the same family or from the same manufacturer have the same (or very similar) peripherals, so your code is still reusable.

Just don't fall in the the same pit as authors of ASF (and other such libraries) did. Write only the code you need. If you don't need buffered UART, don't complicate things with buffering. Otherwise you will end up with the same monstrosity of a system.

[dannyf]

It is simple.

Say that one vendor library uses baduglybear() to set a pin, and another vendor library uses theblueisred() to set a pin on a totally different chip.

You implement one routine, mysetpin(), utilizing baduglybear() or theblueisred(), depending on which chip the code runs on.

And you write all of your user code by calling mysetpin(), couples with the right vendor library.

In the future, if you deem the vendor library inadequate, you can simply implement mysetpin() whatever way you want. That change will be completely transparent to all used code you have previously written - all needed is to implement the new layer and hit recompile.

[jackbob]

How is ARM core more confusing than AVR? General MCU architecture is essentially the same - you have a core connected to peripherals via buses.

With ARM you have more control over bus behavior and generally more things exposed, but it is a good thing. And of you don't have specific need to mess with it, then just don't. Typically defaults are good enough for normal MCU operation.

Defaults always keep thing simple, I learned that and tweak things only as needed. ARM itself isn't confusing, but rather having two processors together is different than what I am used to I would not even know how to upload code to the ARM or how to address which processes it handles. Doing a little research it appears as if the traditional ISP disappears with the ARM and you have to BOSSAC or something. It doesnt seem as simple as just hooking it up to your avr dragon and hitting upload as I have done in the past.

[dannyf]

Manyons ago when I started, my boss told me that they only reason you write code is so you don't have to write that code in the future.

Reusing code is far less about portability. It is about robustness, code reliability, time to mkt, high roe, .....

So whenever you write a piece of code, you should always ask yourself how you can write this piece of code so that it can be used somewhere else, in a different project.

Or it is time wasted.

[ataradov]

ARM itself isn't confusing, but rather having two processors together

What two processors?

ARM processors are typically programmed through SWD or JTAG interface and vendor tools provide a way to program them by simply "hitting a button". There is no difference there at all.

In fact, ARM programming interfaces are more open and better documented, so there is more room for in depended tools.

[jackbob]

Manyons ago when I started, my boss told me that they only reason you write code is so you don't have to write that code in the future.

Reusing code is far less about portability. It is about robustness, code reliability, time to mkt, high roe, .....

So whenever you write a piece of code, you should always ask yourself how you can write this piece of code so that it can be used somewhere else, in a different project.

Or it is time wasted.

Thats a good method to go by. I find myself writing similar bits a pieces of code all the time and even copy and paste old pieces of code to make a new program. The only problem I could see with this is what is someone else has to maintain my code later? Sure I may know all my own definitions and functions off the back of my head, but someone else may have to work with these later and figure all that out for themselves.

[dannyf]

"This is quite a bit of work but seems worth it for sure. "

Whether it is worthy will depend on your circumstance. It would be stupid for example to study the data sheet for two months to use a timer, with your boss breathing down your neck, when the same can be done in a matter of minutes through a vendor library.

The approach I outlined preserves the flexibility of writing your own, yet allows you to get up the learning curve quickly and reasonably reliably.

[ataradov]

The only problem I could see with this is what is someone else has to maintain my code later?

That's applicable to any code in general. If someone really has to maintain something, they will figure out how.

Maintaining even the worst low level code is better than ASF.

[ataradov]

It would be stupid for example to study the data sheet for two months to use a timer, with your boss breathing down your neck, when the same can be done in a matter of minutes through a vendor library.

There are no timers complex enough so that you need to study them for months. Most of the peripherals can be figured out in a day or two, in the worst case. Especially if you have specific configuration and application in mind.  USB is notorious counter-example, of course.

That way you are just deferring re-write for some later time and potentially setting yourself up for a huge waste of time trying to debug vendor stuff.

[jackbob]

It would be stupid for example to study the data sheet for two months to use a timer, with your boss breathing down your neck, when the same can be done in a matter of minutes through a vendor library.

It seems as if it may take me longer to figure out how to use ASF than read the datasheet and figure out any peripheral.

[dannyf]

It seems as if it may take me longer to figure out how to use ASF than read the datasheet and figure out any peripheral.

You may just have to bite the bullet there: if you look around, the trend is to use libraries, vendor-supplied, or 3rd party-supplied.

The reason is simply: powerful cores need power peripherals. A typical timer on PIC16F devices may have 4 - 6 registers; A typical timer on LM3S has 16 registers; A typical timer on LM4F120 has 30 registers; The STM32F4 Timer has ~20 timers + a gazillion signals + DMA / interrupt related registers.

So the time needed to comprehend them and to get them done right increase exponentially, as does the chance of getting something wrong on a given chip, or of porting the code from one chip to another.

The use of libraries is a great way to get you started on reasonably good ground.

To a chip vendor, that's a great way to get people to give your chip a try.

Unfortunately for a hobbyist, the pay-off from using a library isn't as significant.

[ataradov]

You may just have to bite the bullet there: if you look around, the trend is to use libraries, vendor-supplied, or 3rd party-supplied.

I don't see that as a trend. Contractors like 3rd party libraries because they let you quickly gobble together a bunch of code. They rarely have to support it afterwards, so it is OK if code is a mess. Companies that do development in house or under tight supervision, often explicitly prohibit the use of 3rd party libraries.

The reason is simply: powerful cores need power peripherals. A typical timer on PIC16F devices may have 4 - 6 registers; A typical timer on LM3S has 16 registers; A typical timer on LM4F120 has 30 registers; The STM32F4 Timer has ~20 timers + a gazillion signals + DMA / interrupt related registers.

But you don't need all of them at the same time. Furthermore, what takes time is figuring out if peripheral can do what you need and in what modes. This still requires reading the datasheet, otherwise how will you tell the library what to do?

EDIT: One of the things that is often acceptable is to pay for well supported libraries. Like the ones supplied with Keil. The code is still not great, but at least there is a phone number you can call in case of problems. Of course this comes with a price tag starting from $5000.

[jackbob]

Unfortunately for a hobbyist, the pay-off from using a library isn't as significant.

Well isn't that the truth. I can't think of many projects I might do that would benefit from libraries like ASF or any other advanced libraries, especially with all the time it takes to learn it. I do however plan to have a career in this field and figure it would be good to get some practice and personal experience with the tools and practices used in industry. If I don't learn it now, I'm sure I will be introduced to it in school. There's nothing better than taking a class and already having a good understanding and background knowledge from personal experience.

[ataradov]

Also, think about it this way. If you do all the programming yourself, you are learning new fundamental things. The more you do it, the easier it gets. And MCU programmers model has not changed significantly in the last 30 years.
Things get faster, more streamlined and get more features, but principle remains the same. Once you know one or two micros, you will have no problems adjusting to any other.

With libraries on the other hand, both Atmel and ST have significantly changed APIs in the last 5 years. And Atmel is doing it again right now with Atmel Start  (start.atmel.com). Start is not ready for prime time yet, but once it is, today's ASF will probably be phased out. So all your knowledge becomes irrelevant.

Same goes for ST with migration to STM Cube. New devices will not be supported in the old library. Good luck migrating your projects.

[westfw]

Vendor libraries: all the bloat and slowness of Ardunio libraries, without the simplicity or community support!

When attacking a complicated set of peripherals, it becomes much more critical to understand what you want to DO with them.  It can take a long time to "fully understand" a complicated timer module, if all you are doing is reading the datasheet and trying to understand EVERYTHING.  On the other hand, if you go in with a goal like "I need to do PWM on as many pins as possible", that will likely be much easier to figure out.  (that's one of the things wrong with vendor libraries.  They tend to implement everything in the datasheet equally, instead of making the common things easier.)

The Arduino Due libraries are built on top of ASF, I believe (see https://github.com/arduino/Arduino/issues/4030 for instance.)  The Arduino Zero libraries aren't.  "Maple", an Arduino-like board based on ST32F1xx chips, originally tried to use the ST libraries, but was forced to give up.

ASF at least has a lot of example programs, and it is helpful to look/step through those to see what they end up doing...