Atmel Sam4L

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys,

I didn't know where to put this being that there is no ARM subforum. I purchased the Atmel Sam4L xplained pro and I'm looking for a good starting point... I have pretty involved experience with the AVR series micro's and so far I haven't gotten very far with the Arm series...

I'm looking for some sample code dealing with registers... setting bits and turning pins on and off etc... I've looked at some code using ASF and honestly i'm not a fan, I don't really want to be using Arduino like functions that limit my capability, I want to be right in the guts of the thing so I know exactly what's happening... but I can't even find a header file with the registers defined...

Any help is much appreciated

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The thing is that ASF is kind of the way you are expected to program ARMs. If you went with STM or Freescale or NXP you would find the same. While CMSIS style headers may well define all the peripherals and bits all these manufacturers expect you to use their peripheral driving library code. In fact you will find the same with UC3 and even Xmega from Atmel.

I suppose even Arduino for AVR tiny/mega is something similar where the programmer is not expected to get down and dirty with the bare metal but would just call library code to set a bit or start a timer or whatever.

However, as you've found, these libraries tend to be all things to all people and in their generality they employ layers of obfuscating code so the thing that actually sets an output bit IO bit that only really takes to machine register writes turns out being 4 nested functions with 50-100 lines of code (Arduino is the very worst example of this in digitalWrite())

If you want efficiency probably the best way to learn is to start with sketching out the picture in the broad brush strokes of ASF then dig down into the detail. Discard all that is not required and you end up with the 10 lines of C you actually need to flash that LED.

Somewhere on here I posted my first SAM4S Xplained LED flasher derived via such principles but I think it's best to actually work through ASF style code and analyse what it's up to in order to work it out for yourself or you will miss something vital or not understand why something is being done.

Did you know that in most of these "large" chips (ARM, UC3 and I think it may even be true of Xmega) that you not only program a port as output (aka DDR) and then set the output bit (PORT=) but, on the whole, you have to turn the entire GPIO block "on" by enabling a clock to the particular peripheral. If you just read an ARm datasheet and looked at it with an AVR view of the world you might have worked out the DDR and PORT equivalents but I bet you'd never have spotted the need for the clock.

So tearing apart ASF code might have its benefits.

Oh and as for finding .h with register definitions. Just create an ASF example project in AS6, build it then look at "Dependencies" in the Solution Explorer tree. You will find the .h (or rather a whole raft of .h) that define both the peripheral base addresses but also the register and bit structures that are cast onto these for access.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks very much, I'm going to get into this stuff a little bit later after work. I've dug into different functions and found that they have 4-5 layers calling other functions and dealing with objects etc... I've never done anything object oriented so it looks like I have my work cut out for me. You seem experienced, is it worth spending time learning this framework? Once I get the hang of it will it be as powerful as dealing with the processor on a register level? Because in my honest opinion working in the Arduino environment isn't nearly as powerful as just programming AVR with a GCC or AS6...

I've done some stuff with the TI M4 cortex on a register level and something as simple as turning on a pin involves modifying I think 5-6 registers in a very specific order...

Last thing, is there documentation outlining all the functions and arguments?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The documentation is at or near:

http://asf.atmel.com/docs/latest/api.html

Back in the day you never used to get libraries like ASF from a silicon vendor. You got a chip, a 1,000 page manual and a lot of digging about working out what those 5/6 registers you had to write were and in what order. When a peripheral has 30+ registers but you only have to actually write 5/6 of them for "general use" it's often tricky to work out what the important ones are and which can be ignored. I suppose to a very lesser extent even AVR8 is a bit like this. A UART only has about 6 registers but it's not immediately obvious that you almost never need to write UCSRC because everyone just uses 8-N-1 anyway. Scale this up by several levels and you have the UC3/ARM situation.

In this sense ASF "helps" because it's written by the guy who designed the UART or at least someone who was able to talk to him directly and say "what's important and what's eye candy?". So it probably tells you more than a dry-reading of the datasheet will.

But what always gets me about ASF (more so than libraries from other vendors) is how overly engineered and multi-layered it seems to be. Trying to work out how to set an output bit is like peeling the layers of an onion. YMMV.