#define of a pin does not always work?????

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

I am working with an AT32UC3A1512 processor on a custom board.  I have #defined a pin with a name.  Using that name to setup the pin works, but reading the pin using the name always returns 1.  BUT if I replace the #defined name with the actual pin number, it correctly reads the port!  Below is the pertinent code:

in an #included .h file

#define XAPIN     AVR32_PIN_PA03

 

in a test section of the program

        gpio_enable_gpio_pin(XAPIN);                          //enable gpio pin
        gpio_configure_pin(XAPIN,IN);                          //make pin input
                                       
    while (1)
    {
        a = gpio_get_pin_value(AVR32_PIN_PA03);      //returns the correct value in a
        a = gpio_get_pin_value(XAPIN);                      //always returns a 1
    }

 

Any ideas?
Kind regards,

David

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

The:

#define XAPIN     AVR32_PIN_PA03

is based on what is called a hardware abstraction layer known as HAL. So doing the like this you are defining the PIN two times. try to see whats behind "XAPIN". the atmel START generates a code that is based on HAL, Its my advice that if you are going to use it, is to understand whats behind it exactly, if you are using AS just double click and then you will go to the implementation of it.

 

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

clawson wrote:

Moe123 wrote:

try to see whats behind "XAPIN

 

You mean "AVR32_PIN_PA03". It's obvious from the above what "XAPIN" is !

I was just stating that he might not need to define the pin two times, The HAL of atmel START already defines pins...so there must be something wrong in the definitions that caused this error to happen.

Last Edited: Fri. Mar 29, 2019 - 09:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Apologies for correcting you but it is simply misleading to misdirect the OP.

 

Please stop doing this, this is not a game and I was simply not misleading the OP. its up to each member here to contribute with his ideas. I keep telling you since two months to keep your personal behaviour away and if you have a problem to discuss it in PM.

 

EDIT: stop editing my posts for the second time. if you want to contibute to this thread you are welcome.

EDIT2: Edit 2, i took screenshots about you deleting my technical replies to thread. Please apologize for the second time.

Last Edited: Fri. Mar 29, 2019 - 09:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Apologies for correcting you but it is simply misleading to misdirect the OP.

 

Its simply not a valid discussion now since you deleted and edited my own reply to the thread.

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

Moe123 - I fear I am do not understand your answer.  You mention "PIN" being defined twice - but there is no "PIN".  

 

There are defines in place for each pin on the processor (AVR32_PIN_PA03 for example).  All I am trying to do is to create a label that is more meaningful within the context of the program.  In other words, I want to use XAPIN instead of AVR32_PIN_PA03.

 

Using the #define as I have has been working for me for years - up until now.  Thus my question.

 

Thanks,
David

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

clawson wrote:
I am simply trying to edit the pointless noise and

Euhm, no. Most of this thread is about some feud betywen Clawson and Moe123.

 

I have no idea what the gpio_get_pin_value( ) function does.

GCC can be instructed to ony do the preprocessing and / or save the preprocessed output, and this can help with debugging macro's.

 

Sometimes it helps to put abundant parenthesis around macro definitions to prevent the simple text substitution from doing weird things:

#define XAPIN     (AVR32_PIN_PA03)

But that probably is not the case here.

 

If XAPIN is defined anywhere else you are likely to get "multiple definition" errors. Does the compiler spit out any warning or error messages?

XAPIN is a pretty short / generic name. You can also try to (temporarily) change XAPIN to a name that is so unlikely to exist anywhere else to exclude any possibility of GCC using the wrong definition by mistake. Something like "XAPIN_WHATS_GOING_ON_HERE" & use your IDE to search / replace it.

 

Or, can you do a grep on XAPIN on the header files / software libs?

(Studying the preprocessor output should also have made clear if GCC was mistaken in some way).

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

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

clawson wrote:

I am simply trying to edit the pointless noise and personal insults out of this thread to keep it on topic and then you keep adding to it - please stop it and let me edit this thread so it is ONLY about the OPs issue.

 

You were right to say that he should investigate the definition of the parameter being used, you were wrong to say it was XAPIN to look behind. I corrected this. I personally don't see what the problem is in correcting misdirecion but let's agree to leave it there. Unless you have a problem I will now edit this thread to remove some of these pointless posts.

 

Its pointless in your eyes, what are you god or something.! never edit my technical replies again, I have all the screenshots, I was simply trying to reply to the OP's question but you keep coming to me and attacking me in every thread that i contribute, and now you start to edit my replies so it looks stupid and it looks that i am the one who is writing it (Its not me guys whose writing, its simply clawson editing my posts and adding from his side). This is completly not acceptable behaviour from you and not acceptable from a moderator. be civil.

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

dfansler wrote:
Moe123 - I fear I am do not understand your answer.  You mention "PIN" being defined twice - but there is no "PIN".  

I apologize to you.

 

What I wrote before, but (its deleted now!) that you may have the pins defined somewhere because you are using HAL, this HAL application functions are defined somewhere, so if you are defining them again its fine, but maybe as Paul said it might be defined somewhere and this cause this behaviour. this is my opinion.

 

Please consider this as an apology, but the there is someone here who abuses his power as a moderator and its not my intention to mislead you, he keeps editing my posts....!.

 

Regards,

Moe

Last Edited: Fri. Mar 29, 2019 - 10:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok - now that the bickering is hopefully done . . . . . 

 

I do not ask questions lightly of a forum - usually because getting an answer is like pulling eye teeth!  I have been programming since the 60's (Fortran in college) and microprocessors since the 70's.  I never claim to be an expert.

 

I understand that #define sets up a macro - I have checked and in my project, there is only one define of XAPIN and that is equating that to AVR32_PIN_PA03.

 

What makes no sense to me is that the define of XAPIN works for configuring the pin on the uprocessor, but will not work for reading the value of the pin.

 

As noted before, I am using an ATUC3A1512 processor.  The function gpio_get_pin_value(XAPIN) reads the value on the pin defined as XAPIN.  This function is part of the uc3.h file provided by Atmel.

 

So the question remains - why will a label (yeah I know, wrong term - so I'll say a string of characters representing something) work in one function and not another, when both functions are looking for the same thing as input?
Thanks,

David

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

If you use avr-gcc perhaps using the "-E" flag to provide output from the preprocessor will help shed some light on the issue.

That is, if you use "avr-gcc ...flags... -c foo.c -o foo.o" then try "avr-gcc ...flags... -E foo.c -o foo.e" and look at (the end of) the file foo.e.

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

Moe123's (indirect! ;-) suggestion is that you look into what "AVR32_PIN_PA03" is actually defined as.

 

I was going to try that but just realised my AS7 doesn't have the AVR32 stuff installed.

 

Maybe I can get something out of start.atmel.com...

 

EDIT: is it me or does start.atmel.com not seem to cover AT32UC3 ??

Last Edited: Fri. Mar 29, 2019 - 02:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am far from a viable source of an answer to many things, the AVR32 being at the top of the list, but I have a thread in the SAM forums that somewhat deals with the subject in this thread.

 

Here is my thread:

https://community.atmel.com/foru...

 

Might be of some help, might not. 

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I don't don't know the answer, but first thing I would look at is the ASM output, it should give a hint to where the problem is.

 

 

Add:

And the stupid question is how do you know that the 2. line always return 1 ? (could there be a ISR / volatile problem?!)

Last Edited: Fri. Mar 29, 2019 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually the best bet is probably to use -save-temps then study the .i file to see how the macros expanded.

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

Hmmm, asking here as a totally uninformed individual who has thoughts of migrating to one of the new Mega0/1 devices, which would seem to share some of the characteristics that might be involved, here.

 

In the "old" Mega/Tiny world with simple (e.g. not ocmplex) port structures, it is easy to write and use

 

#define LEDPIN PB3

or

#define SWITCHPIN PD6

Do these kinds of "aliases" not work with advanced port structures?

 

Thanks

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Well this is annoying - I just ran the reinstaller on my AS7 and this time ticked the AVR32 box to add that to it yet after a restart (even a reboot) there's no sign of AVR32 being listed in ASF. Presumably it needs to be reinstalled somehow? I was keen to find out how  AVR32_PIN_PA03 is actually defined.

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

Sparrow2 - I once had a post that stated "There are no stupid questions"  I set a breakpoint on the first read, single stepped forward and examined the value of "a".  I then single stepped forward and read the contents of "a" again.  The input using AVR32_PIN_PA03 would always follow the state of that pin, whereas when I used XAPIN for the input, the value was always 1.

Thanks,

David

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

Well . . . .  I seemed to have fixed the problem.  I think it was multifaceted, but in the end there was more than one XAPIN - the one that was defined as AVR32_PIN_PA32 and another as &AVR32_EIC where I use XAPIN as in input to trigger an interrupt.  So the AVR32_PIN_PA03 was not at fault, but rather  my redefining XAPIN.

 

My thanks to all who read and responded to the thread.

Kind regards,

David

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

Well, I was accused of trying to mislead you by the Moderator Clawson.!

I am happy that you fixed your problem and that indeed it was redefining of an alreary defined pin as me and Paul suggested.
based on this thread i would like to add something and its for the person that was throwing accusation all over this thread before deleting them, you may have a knowledge of 40+ years plus, but unfortunately this knowledge didnt help you to know how to deal with people and members of this forum in a good manner. For me I hope in the future that my posts doesnt get re-edited without my permission, an appology would be appreciated right now from this person.
thanks David for telling us the answer and re clarifying what I and Paul suggested.

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

dfansler wrote:

Well . . . .  I seemed to have fixed the problem.  I think it was multifaceted, but in the end there was more than one XAPIN - the one that was defined as AVR32_PIN_PA32 and another as &AVR32_EIC where I use XAPIN as in input to trigger an interrupt.  So the AVR32_PIN_PA03 was not at fault, but rather  my redefining XAPIN.

 

My thanks to all who read and responded to the thread.

Kind regards,

David


You are welcome.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#define AVR32_PIN_PA03   3

 

Letting the smoke out since 1978