SAMR21 PORT Register Access

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

Hi everyone, I'm a little bit stuck and hoping for some internet help.

 

I am using AVR studio and a SAMR21 Xplained Pro development board.

 

I have significant experience in assembly and C for PICs, AVRs and STM32 microcontrollers, so very frustrated that this has me stumped. I have never used the software frameworks for any of the microcontrollers Iv'e used, and wasn't planning on using the ASF framework for the SAMR21 either.

 

I can't seem to figure out how to configure a particular pin as an input with pull-up by using the registers defined in port.h

 

To configure a pin as output for example, I can just use :

 

    //Make PA19 output
    REG_PORT_DIRSET0 |= (1 << 19);    

 

But I'm not sure how to access the REG_PORT_PINCFG0 register.

 

Any guidance other than 'Use the ASF' very much appreciated.

 

 

If you're using ASF, neither of us know what your code is really doing :)
Have I just solved your problem ? My bitcoin address: 1EpGuPa2VtUVWjGmgWRmFicNKMFZSGhfLr

Last Edited: Thu. Oct 15, 2015 - 11:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not start with ASF and see how it does it?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Why not start with ASF and see how it does it?

 

Hey awneil, I did try that but got lost in the 40 levels of abstraction! 

If you're using ASF, neither of us know what your code is really doing :)
Have I just solved your problem ? My bitcoin address: 1EpGuPa2VtUVWjGmgWRmFicNKMFZSGhfLr

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

On at91.com, bptech wrote:
Seems to be a recurring theme - "I don't want to use ASF but <complex inner detail question about something easily solved by using ASF>.

See: http://www.at91.com/discussions/...

 

and so the theme continues!

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, after another round of clicking 'Go to implementation' like a "three-year-old repeating "but why Daddy?" over and over" it looks like the ASF uses the WRCONFIG register instead of the PINCFG register. So I can definitely also use the WRCONFIG regsiter, but interesting that even with the ASF it doesn't look like Atmel has provided any out-the-box way of accessing the PINCFG register.

 

If you're using ASF, neither of us know what your code is really doing :)
Have I just solved your problem ? My bitcoin address: 1EpGuPa2VtUVWjGmgWRmFicNKMFZSGhfLr

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

with the ASF it doesn't look like Atmel has provided any out-the-box way of accessing the PINCFG register

Because that's not the point of ASF!

 

The point is that it provides an out-of-the-box way to "configure a particular pin as an input with pull-up"

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

awneil, you know perfectly well that ASF is horrible for learning stuff.

 

OP: Take a simple project here https://github.com/ataradov/mcu-... and look in the hal_gpio.h file for pin manipulation functions.

 

The project is for D21, but R21 is based on D21, so it will work as is. You will need to change LED and BUTTON pins if you want to see this application work. Changing UART is a bit more complicated, but doable as well.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Last Edited: Fri. Jul 17, 2015 - 05:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil, you know perfectly well that ASF is horrible for learning stuff

Not entirely.

 

It attempts to let you get stuff done - "configure a particular pin as an input with pull-up" - rather than have to worry about the arcane internal details of registers & bits.

 

And, in things like the SAM D21, those details can be very arcane indeed!

 

As bptech (from at91.com) says, it lets you just get things done without having to worry about complex inner detail questions.

 

Yes, it could be better explained - but it does basically get the job done.

 

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Usefulness of ASF aside, the OP explicitly asked for advice without use of ASF.

 

Some people (me included) prefer to understand how the actual part works rather than some unknown library.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

alexru wrote:
the OP explicitly asked for advice without use of ASF.

Granted. 

 

But the observation still applies:

On at91.com, bptech wrote:

Seems to be a recurring theme - "I don't want to use ASF but <complex inner detail question about something easily solved by using ASF>.

 

And I have found that following an ASF example is a good way to see how to do it "manually".

Possibly easier by stepping in the debugger rather than by "static" analysis.

 

I have also found the LwMesh source to be a good place to look for examples of doing it "manually".

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can setting/resetting port bits really be so complex that you have to get buried in layers of ASF? I agree that ASF has its place for complex stuff like USB or CAN that would take a lot of effort to do "bare metal" but GPIO? Surely it's not beyond the wit of man to access the registers/bits for that? (and hence have a deeper understanding and better control).

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

Setting/resetting the port bits is not the issue - it's configuring the port in the first place!

 

And that's not only a matter of configuring the port itself - but also clocks, bus interface, pin mux, etc, etc, ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For all the ARMs (M0, M3, M4) I've played with (Atmel and others) I have generally started by using the supplied library code to get that ubiquitous LED flashing (or in some changing colour) but have then dug down into the library code to see what's actually being done (in tandem with a datasheet). As you say it's normally little more than configuring a clock to the peripheral so you can "talk" to it then beyond that it's never much more than AVR-like  DDRB=n, POTRB=n however you dress it up. It's not rocket science and personally I prefer to know what's going on under the hood.

 

On the other hand, for something like USB CDC-ACM I wouldn't bother - for something that complex I'd just trust the library code (a bit like using LUFA to continue the AVR8 analogy).

 

The issue with using "complex peripherals" is a bit like the situation when moving from tiny/mega to Xmega. Originally you had just DDR, PORT, PIN and now you are faced with PORT_DDR, PORT_IN, PORT_OUT, PORT_SET, PORT_CLR, PORT_TGL and so on and it an be tricky to sort the wheat from the chaff. What is "fundamental" and what is "bells and whistles". This is the one area where ASF (etc) come in useful as you can see what are the real important bits to know about out of all that is available.

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

Me too. I've been using Kinetis of late and used the supplied hal functions. Sure,they worked, but were they slow! So i just stepped through the code with the debugger. With a little detective work and reading of the manual, it all starts to become clear.

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

I have just started with some raw D21 code with straight CMSIS access.    In fact the pin configuration is no more than one line to configure up to 16 pins (with the same mode and alternate function).    Yes,  you can do them one at a time but you often have a group of pins that are used in the same way.

 

Once configured,   the set of SET, CLR, TGL, ... registers make life simpler and faster to manage individual or groups of pins.

 

However,   I have serious difficulties following the ASF code.  When I get a bit more confidence,   I will see how the ASF compares with raw register settings.    In theory,   using ASF should mean that you write blackbox code that will port to any Atmel MCU.    In practice,   it does my head in.

 

David.

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

In practice,   it does my head in.

I wonder if it would be possible to find ANYONE for whom that is not true?!?

 

(presumably someone inside Atmel thinks it's a good idea?)

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

david.prentice wrote:
In theory,   using ASF should mean that you write blackbox code that will port to any Atmel MCU.  

I don't think that's even true in theory?

 

So much is dependent on specific features of the chip that it's just not possible.

 

But at least ASF should give you a common approach/structure ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wonder if Atmel would consider sending the ASF engineers to Arduino school? ;-)

 

(is the integration of Arduino in AS7 already an admission of defeat I wonder?)

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

Several months ago,   Atmel announced that it was joining MBED.   I have not noticed anything actually happening but this is not uncommon with Atmel vapourware.    It would take a few days for an experienced Atmel employee to provide the necessary core functions for MBED and some appropriate XPRO board(s).

 

Of course,   it would put the SAMD, SAM3, SAM4 chips in direct comparison with NXP, Freescale, ST, Nuvoto, ...

But it would certainly provide the simple jump start for the hobbyist or professional prototype platform.

 

Mind you,   the Arduino ZERO / M0_PRO would provide an instant migration from the UNO.    It is a pity that the Italians find it necessary to fight battles.

 

I do not know whether MBED started off as a private commercial enterprise.    It seems to be well supported by ARM Holdings nowadays and is an excellent way to get started with ARM chips.

You have a parallel with Arduino.    Both MBED and Arduino provide an approachable quick learning system.     You can still run custom software on the hardware boards.   i.e. it can provide proof of concept and still run the final prototype at full speed on the same hardware platform.

 

David.

 

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

hey i know this might seem vague and off topic but how the hell do you learn all this stuff? IM an engineering student and  well none of this is in my syllabus , well im a a first year student and i have not taken any programming classes yet  but ive read a book or two... I have been playing with AVR 8bits for a little while just some bare metal projects nothing fancy , only thing that ever threw me off and i never bothered to understand was the 2million files needed in a project to blink led , i never ventured  past my main c file and things such as i2c uart etc.. i configured via the datasheet. 

 

Now trying to get a basic understanding of 32bit Ive got a couple of SAM D20's and im still waiting for some stuff in the mail to etch a breakout board , however i looked into the ASF and while there is a lot of abstraction its all in plain English and quite readable. And since it is from the manufacture i trust it to work . but i too like learning whats behind the curtains but if eventually this will lead to my own perhaps sloppy libraries i might as well use theirs . However i will still try to learn whats going on .. 

 

I looked at a link provided above  https://github.com/ataradov/mcu-starter-projects/tree/master/samd21 thiking it would be easy to understand it it was and i still see a million files needed for a project , are these custom written or where do you get them or do you use what atmel studio gives you ? 

 

I was looking through the files and i was trying to understand how you manipulate the ports but because of my inexperience i do not understand what is going on , specially since ive never seen the ## symbol used in a way that is not a define or include 

if you  could break this down for me that would be of great help... 

 

i understand your pointing to what looks like an array of Group[ ] ?? i see group and square bracets i think array i may be wrong...

 

then the ## i have no idea what they mean 

 

the bit shifting i understand

the last line that starts with (void) ive never encountered that either , its like your making a void varaible ? or returning something? i really dont understand it either. 

 

Ignorance is NOT bliss. 

 

 static inline void HAL_GPIO_##name##_set(void)				\
  {										\
    
    
    
    PORT->Group[HAL_GPIO_PORT##port].OUTSET.reg = (1 << pin);			\
    (void)HAL_GPIO_##name##_set;						\
  }

 

Last Edited: Wed. Jul 29, 2015 - 03:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See how it's got the '\' characters at the end of every line, this usually indicates a multi-line macro (code inside a define), my guess would be that the ##name## gets replaced by whatever is in the function call when the code gets compiled. 

If you're using ASF, neither of us know what your code is really doing :)
Have I just solved your problem ? My bitcoin address: 1EpGuPa2VtUVWjGmgWRmFicNKMFZSGhfLr

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

see im reading the datasheet and lets assume i have the clock and all the goodies configured  , to my understanding on how to use these datasheets it says :

"To use pin y as an output, configure it as output by writing the (y%32) bit in the DIR register to one."

 

DIR |= (1<<PIN%32)   that is how i am understanding that explanation 

 

However the code from the person above indicates it is not that simple. Likewise asf indicates its not that simple? 

I wish these datasheets had C code like the AVRs do

 

Last Edited: Wed. Jul 29, 2015 - 04:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, you're almost correct, I'm not in front of my work laptop, but I think setting the port as output is something like:

 

REG_PORT.DIR0 |= (1 << pin);

 

This will work, but it does a read-modify-write (you read the  value of the register, then modify it, then write it back) . . .  a few assembly instructions.

 

You can also use the DIRSET register, this sets the output without doing a read-modify-write, for example:

 

REG_PORT.DIRSET0 = (1 << pin);

 

In both these examples, I've used a '0' at the end of the register, this really just means PORTA, DIR1 = direction register for PORTB and DIR2 = direction register for PORTC etc.

If you're using ASF, neither of us know what your code is really doing :)
Have I just solved your problem ? My bitcoin address: 1EpGuPa2VtUVWjGmgWRmFicNKMFZSGhfLr

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

but how the hell do you learn all this stuff?

Well one way is to start off with something a lot simpler than a SAMR21, something like a mega328 perhaps? That is simple beyond belief - a port only has DDR, PORT and PIN and there's no complexity like having to enable a clock to GPIO before you can use it (as you find in ARM). You then work up from there. Next step might be an XMEGA. It still has the equivalent of just DDR, PORT and PIN and the IO can still be programmed with those alone but it adds "bells and whistles" like PORTSET, PORTCLR, PORTTGL and so on which can sometimes make life easier but they are just added luxuries really. After that trade up to SAM and most of what you see will be familiar with only a few additional steps to then be learned (like having to enable peripheral clocks).

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

clawson wrote:

but how the hell do you learn all this stuff?

Well one way is to start off with something a lot simpler than a SAMR21, something like a mega328 perhaps?

Yes I have played with the 328 quite a bit, mostly using and learning the on board communications . I feel the simplicity of the chip leads one to a false conclusion everything is a walk in the park. I don't find the samD trivial , once I learn how to do simple tasks I can build up from there but finding exact examples is quite hard. Atmel for example is all about pushing their ASF there is not a single example without it. The datasheet , well that's one beast I'm still trying to tackle it tells you things like set DIR to 1 on the desired but but I didn't see anywhere about using the prefix Reg_Port. Perhaps I have much more reading to do. Thanks for the speedy replies guys.

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

The syntax gets a little long-winded.   But you still get some human readable results. e.g.

    SERCOM3->SPI.BAUD.reg = div + 1;
    SERCOM3->SPI.CTRLA.bit.ENABLE = 1 ;

Or

		          PORT->Group[0].DIRSET.reg = AMASK;    //output

If you call PORT->Group[0] PORTA,  you get a more natural looking:

                          PORTA.DIRCLR.reg = AMASK;             //input

Either way,   the bitfield members or full register members still have a pretty unpleasant syntax.   But AVR code can look pretty horrible too.  e.g. lots of |= and &=~ stuff.

All ARM chips that I have ever used have a method of setting and clearing GPIO bits efficiently.    In practice you try to hide the low-level stuff and concentrate on human friendly variables and intuitive logic.

 

Incidentally,   "other" makes of ARM might use an easier syntax.

 

David.

Last Edited: Wed. Jul 29, 2015 - 02:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simple enough . thanks .

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

eddieA6987 wrote:
it it was and i still see a million files needed for a project , are these custom written or where do you get them or do you use what atmel studio gives you ?
Anything under "include" directory comes from Atmel and ARM. The actual hand written application code is just a startup and the main file.

 

eddieA6987 wrote:
ve never seen the ## symbol used in a way that is not a define or include
That is a standard C preprocessor feature. It lets you substitute a parameter without inserting additional spaces, so it looks like a single item.

 

eddieA6987 wrote:
i understand your pointing to what looks like an array of Group[ ] ?? i see group and square bracets i think array i may be wrong...
That's just how device peripheral is defined by Atmel.

 

eddieA6987 wrote:
the last line that starts with (void) ive never encountered that either , its like your making a void varaible ? or returning something? i really dont understand it either.
This is a standard trick to make compiler think that this function is "used", so it won't complain about unused functions.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

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

tricks of the trade!!! good stuff i appreciate the break down. 

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

And the (void) stuff is nothing special, it is just a standard type cast, but you are disregarding the result. Still counts as "use" :)
 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.