New to ASF and I'm not getting it....:-(

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

Ok, I'm not the sharpest tool in the shed with C but not completely lost either (I think)...but I'm not having any success with starting a simple output setup. I can build and modify ASF example projects, but am not getting "User defined board" architecture. Studio 6, ASF 3.13 Xmega16A4U

New Project -> User Board - Xmega A
Then use the ASF Wizard to add IOPORT

Modify user_board.h to add:
# define LED0_GPIO IOPORT_CREATE_PIN(PORTA,0)
So far so good.
Now the confusion starts...If I try to modify init.c by adding:
ioport_configure_pin(LED0_GPIO, IOPORT_DIR_OUTPUT);
to board_init I'm having no success getting it to find it at build. I've included ioport.h and user_board.h but keep getting a "implicit declaration of function 'ioport_configure_pin' " which I assume means it's not finding the function.

HELP and thanks in advance.

Phil

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

Thanks, but I had already watched that. As I stated above the problem isn't with example boards, it's with user defined boards.

Phil

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

I tried what you tried and see what you can see. It's obvious that what you need to access is in ioport.h so I got a little further using init.c as:

#include 
#include 
#include 

void board_init(void)
{
	/* This function is meant to contain board-specific initialization code
	 * for, e.g., the I/O pins. The initialization can rely on application-
	 * specific board configuration, found in conf_board.h.
	 */
	ioport_configure_pin(LED0_GPIO, IOPORT_DIR_OUTPUT); 
}

the key thing here being that third include but I cannot believe they expect users to have to use such nested pathnames so this cannot be the real solution.

(and there are still build problems with this anyway).

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

Ah ha I appear to have cracked it. What I did was change init.c to be:

#include 
#include 
#include 

void board_init(void)
{
	/* This function is meant to contain board-specific initialization code
	 * for, e.g., the I/O pins. The initialization can rely on application-
	 * specific board configuration, found in conf_board.h.
	 */
	ioport_configure_pin(LED0_GPIO, IOPORT_DIR_OUTPUT); 
}

(my previous "silly" include removed and replaced by a much more cosmetic "). I have a sneaking suspicion that when you added "IOPORT" from the ASF wizard it was probably supposed to add that include for you.

However it still would not build but what worked was now to edit the Project properties and under Toolchain-AVR/GNU C Compiler-Directories I added a new entry for:

../src/asf/common/services/ioport

and finally it all built OK. Now again I'm pretty sure that wizard thing is supposed to add the paths to the bits it's using when you add things like IOPORT to a project so this all looks like a deficiency in the ASF project wizard maybe related to using "User boards"

How beginners would ever be expected to work out how to do this otherwise is anyone's guess!

(BTW I suppose you realise that for something as simple as IO you might as well just hit the PORT_DIR and PORT_OUT registers directly? This ASF dog's breakfast just seems to over-complicate something that's actually far simpler though I guess it has merit when you get to more complex peripherals).

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

Nuts. The issue is that there was originally a billion I/O port drivers:

- UC3 had "GPIO"
- XMEGA had "IOPORT"
- SAM had "PIO"
- Common had "GPIO"

As a result, we created yet another common service, also called IOPORT, which was re-engineered to be fast and actually, you know, common. That means the current landscape is:

- UC3 "GPIO"
- XMEGA "IOPORT" (DEPRECATED)
- SAM "PIO"
- Common "GPIO" (DEPRECATED)
- Common "IOPORT"

Where possible, use the new common IOPORT. It should work for all architectures with a consistent interface. The downside is that if you need the old XMEGA IOPORT functions, you also need to add in the old XMEGA deprecated IOPORT driver (not just the service!) to get access to them. Not all training materials have been updated to reflect this.

So in summary - you're not crazy, we messed up a while back and are now trying to fix things. Either add the deprecated XMEGA IOPORT driver to your project to use the functions in the training, or convert them to the new common IOPORT APIs for all projects moving forward.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I did wonder why there were two different ioport.h files! (for a moment I thought there was a recursive self-reference).

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

Thanks all,
I uploaded the newest ASF and it did the includes properly. And looks like it's building properly.

10k+ I want to use ASF for USB purposes, but I thought I'd start simply.....

Phil

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

Wanted to report things are going much better.

IMHO, there really needs to be a "User Board" Wizard that starts with chip selection then drills down into that chips features. Drop downs and check boxes that allows you to configure IO, Clock, and chip peripherals, then it creates the user_board.h, init.c, etc files.

The real problem with so many tools these days (and I think I would include ASF in that) is it's geared to software people not hardware designers. In many industries, you can't afford to be an expert on one family or device and as the devices have become more complex the learning curve is more and more problematic.

Phil

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

So IS there a way to define my own "Board", so that I can just pick "XMduino" from the new project menu, or equivalent?

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

rcinmo wrote:
Wanted to report things are going much better.

IMHO, there really needs to be a "User Board" Wizard that starts with chip selection then drills down into that chips features. Drop downs and check boxes that allows you to configure IO, Clock, and chip peripherals, then it creates the user_board.h, init.c, etc files.

YES!

I'm a professor teaching this stuff. (Yes on ASF) I could REALLY use a tool that does that. Just don't have the time to do it myself right now.

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

Hi everyone!

 

Is there any news regarding the situation with the common I/O port driver? I'm really confused right now... Our team is working on two projects: one is for SAM4S and another one is for SAM4L.

 

  • For SAM4L there are two possibility: GPIO (for interrupt configuration) and IOPORT (basic pin setup).
  • For SAM4S there as well two options: PIO (for interrupt configuration) and IOPORT (basic pin setup).

 

Additionally, it seems that GPIO is not deprecated, since I have found an application note (http://www.atmel.com/Images/Atmel-42280-SAM4L-General-Purpose-Input-Output-GPIO-Driver_ApplicationNote_AT07903.pdf) that describes how to use it.

 

- Dmitry

 

P.S. We are now using ASF v3.24.2.

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

Most of the ASF documentation has this to say about "GPIO":

Driver for general purpose I/O pins. Provides functions for initializing IO pins as input or output, and for reading, or setting/clearing/toggling pins. Common API. Deprecated; use common IOPORT service instead.

Not sure why the text for GPIO under SAM4 seems to be missing this. Anyway the point is always use IOPORT rather than GPIO.

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

Clawson, thank you very much for your quick response! Then will use IOPORT where it is possible.

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

dimi_mel wrote:

Hi everyone!

 

Is there any news regarding the situation with the common I/O port driver? I'm really confused right now... Our team is working on two projects: one is for SAM4S and another one is for SAM4L.

 

  • For SAM4L there are two possibility: GPIO (for interrupt configuration) and IOPORT (basic pin setup).
  • For SAM4S there as well two options: PIO (for interrupt configuration) and IOPORT (basic pin setup).

 

Additionally, it seems that GPIO is not deprecated, since I have found an application note (http://www.atmel.com/Images/Atmel-42280-SAM4L-General-Purpose-Input-Output-GPIO-Driver_ApplicationNote_AT07903.pdf) that describes how to use it.

 

- Dmitry

 

P.S. We are now using ASF v3.24.2.

 

You should be able to do everything you want to do with just the PIO stuff. IOPORT and the deprecated (OR IS IT??) GPIO are attempts to abstract the lower-level PIO with code that makes ARMs and AVRs have the same higher-level firmware interface.

 

 

 

×

 

 

 

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

I know this is an old thread, but my question may be related.

 

I want to start ASF with a USER BOARD, defining a MEGA32A.

When I do this, and move immediately to the ASF wizard in the unedited project I get only a handful of ASF options. I'm trying to use TWI with ASF but nothing shows up relating to TWI drivers.

Am I correct in thinking I need to edit the configuration file in order for ASF to know more about what drivers it can offer? I would have assumed as above, that defining the MEGA32 should infer what the capabilities are.

My Available Module list shown..

 

*UPDATE* Using a STK600 Board for MEGA32 still shows the limited ASF modules.

Attachment(s): 

Last Edited: Mon. Jan 2, 2017 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Not much is available for mega in ASF, check here http://asf.atmel.com/docs/latest...

/Lars

 

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

Thanks.. not much at all. <sigh>