PORTxn not recognized in Atmel Studio?

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

 

According to the attiny datasheet, I should be able to bit shift using "PORTB1", no?

 

 

 

 

But as you can see from the screen shot, I get the red squiggle under PORTB1 in my code.  The attiny85 is currently the current device in Studio.

 

 

What gives?

 

<edited for formatting>

Last Edited: Thu. Jul 21, 2016 - 04:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which AVR model in particular are you using?

 

Which toolchain and version?

 

What does the particular chip-include file have for #defines?  (Shouldn't it be listed in one of your project panes, and you just need to click to it?)

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Jul 21, 2016 - 04:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try PB1 instead of PORTB1

Edit: If you right click on PORTB in the code and select "Goto Implementation", there is a list of the bits in that port

David (aka frog_jr)

Last Edited: Thu. Jul 21, 2016 - 04:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frog_jr wrote:

Try PB1 instead of PORTB1

Edit: If you right click on PORTB in the code and select "Goto Implementation", there is a list of the bits in that port

 

Cool!  So THAT's where it comes in handy!  Okay, so it is defined as PB1. 

 

So, now what does this mean?  The datasheet is inaccurate as a result of...?  avr-gcc?  If I wrote my program in assembler would it still be PB1?

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

chipz wrote:
The datasheet is inaccurate as a result of
... probably cut and paste

David (aka frog_jr)

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

So, now what does this mean?  The datasheet is inaccurate as a result of...?  avr-gcc?  If I wrote my program in assembler would it still be PB1?

Don't confuse the datasheet with the device XML file, nor with the device header file which is (generally) generated from that XML file.

 

In this case the datasheet is not the one that is 'inaccurate', rather the device header file.

 

While it would make sense for Atmel to provide a device XML file in line with the nomenclature presented in the device datasheet, you will find many examples where this is not the case.  Furthermore, each compiler vendor may choose to use their own nomenclature.  GCC is not affiliated with Atmel.  Neither are the makers of IAR, CV, ICC, etc.

 

You'll even find changes from version to version with a given vendor.

 

At the end of the day, these names are defined in header files.  If you want to know what names are defined, and what they are defined as, you'll need to look at the header files.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Jul 21, 2016 - 04:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try to ignore the red squiggles (or just turn Naggy off) as you seem to be getting misleading information from it. Just because Naggy (the squiggles) says something is wrong does not necessarily mean it is.

 

If you look at avr/io.h you find that for building attiny85 it includes avr/iotn85.h and if you look at that file you find there's almost nothing in the active part of it:

#ifndef _AVR_IOTN85_H_
#define _AVR_IOTN85_H_ 1

#include <avr/iotnx5.h>

/* Constants */
#define SPM_PAGESIZE 64
#define RAMSTART     (0x60)
#define RAMEND       0x25F
#define XRAMEND      RAMEND
#define E2END        0x1FF
#define E2PAGESIZE   4
#define FLASHEND     0x1FFF

/* Fuses */
#define FUSE_MEMORY_SIZE 3

/* Low Fuse Byte */
#define FUSE_CKSEL0      (unsigned char)~_BV(0)
#define FUSE_CKSEL1      (unsigned char)~_BV(1)
#define FUSE_CKSEL2      (unsigned char)~_BV(2)
#define FUSE_CKSEL3      (unsigned char)~_BV(3)
#define FUSE_SUT0        (unsigned char)~_BV(4)
#define FUSE_SUT1        (unsigned char)~_BV(5)
#define FUSE_CKOUT       (unsigned char)~_BV(6)
#define FUSE_CKDIV8      (unsigned char)~_BV(7)
#define LFUSE_DEFAULT (FUSE_CKSEL0 & FUSE_CKSEL2 & FUSE_CKSEL3 & FUSE_SUT0 & FUSE_CKDIV8)

/* High Fuse Byte */
#define FUSE_BODLEVEL0   (unsigned char)~_BV(0)
#define FUSE_BODLEVEL1   (unsigned char)~_BV(1)
#define FUSE_BODLEVEL2   (unsigned char)~_BV(2)
#define FUSE_EESAVE      (unsigned char)~_BV(3)
#define FUSE_WDTON       (unsigned char)~_BV(4)
#define FUSE_SPIEN       (unsigned char)~_BV(5)
#define FUSE_DWEN        (unsigned char)~_BV(6)
#define FUSE_RSTDISBL    (unsigned char)~_BV(7)
#define HFUSE_DEFAULT (FUSE_SPIEN)

/* Extended Fuse Byte */
#define FUSE_SELFPRGEN   (unsigned char)~_BV(0)
#define EFUSE_DEFAULT (0xFF)

/* Lock Bits */
#define __LOCK_BITS_EXIST

/* Signature */
#define SIGNATURE_0 0x1E
#define SIGNATURE_1 0x93
#define SIGNATURE_2 0x0B

#define SLEEP_MODE_IDLE (0x00<<3)
#define SLEEP_MODE_ADC (0x01<<3)
#define SLEEP_MODE_PWR_DOWN (0x02<<3)

#endif /* _AVR_IOTN85_H_ */

but the key thing in that is the inclusion of avr/iotnx5.h which is a file shared between tiny25, tiny45 and tiny85 (the one Lee shows above). Now if you look for PORTB1 in that (say) you will not find it. So you may think "oh, that's a shame, they forgot to include the PORTxn definitions in the specific case of the tinyx5 chips". HOWEVER look back to avr/io.h that included iotn85.h (and that in turn iotnx5.h) and you find:

#include <avr/portpins.h>

(which comes AFTER the include of all the various ioxxx.h files) so now take a look at that file...

/* PORT B */

#if defined(PB0) && !defined(PORTB0)
#  define PORTB0 PB0
#elif defined(PORTB0) && !defined(PB0)
#  define PB0 PORTB0
#endif
#if defined(PB1) && !defined(PORTB1)
#  define PORTB1 PB1
#elif defined(PORTB1) && !defined(PB1)
#  define PB1 PORTB1
#endif
#if defined(PB2) && !defined(PORTB2)
#  define PORTB2 PB2
#elif defined(PORTB2) && !defined(PB2)
#  define PB2 PORTB2
#endif
#if defined(PB3) && !defined(PORTB3)
#  define PORTB3 PB3
#elif defined(PORTB3) && !defined(PB3)
#  define PB3 PORTB3
#endif
#if defined(PB4) && !defined(PORTB4)
#  define PORTB4 PB4
#elif defined(PORTB4) && !defined(PB4)
#  define PB4 PORTB4
#endif
etc.

What this is saying is that if PB1 is defined (as it is by iotnx5.h) but PORTB1 has not been defined then go ahead and define it as a synonym (there's also a rule to do that the other way round too). portpins.h (like common.h) are "mop up" files that take the need for a lot of common defines out of all the individual ioxxx.h files and just mop-up what they are missing in one place. They are used more for later ioxxx.h files - a lot of the earlier ones from years back just went ahead and defined everything anyway.

 

Bottom line is that your

PORTB = (1 << PORTB1);

is perfectly valid code for a tiny85 and if you'd ignored the red squiggles and gone on to compile it you would not get a compilation error on that line saying "undefined symbol PORTB1 ".

 

So this is Naggy at fault again. It clearly cannot read/process the conditional compilation structure at:

#if defined(PB1) && !defined(PORTB1)
#  define PORTB1 PB1
#elif defined(PORTB1) && !defined(PB1)
#  define PB1 PORTB1
#endif

Until you know more about this stuff I'd just disable Naggy as it is misleading you. Let the pre-processor, compiler and linker tell you what is wrong in your code by trying to build it and looking at the Build Output - not realtime syntax highlighters in the Studio editor.

Last Edited: Thu. Jul 21, 2016 - 05:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[never mind...]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Jul 21, 2016 - 05:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chipz wrote:
So, now what does this mean?  The datasheet is inaccurate ... 

Not at all.

 

They are just names.

 

While it would, of course, be nice if the datasheet and the #defines used identical names, there is no claim or guarantee that this must always be the case.

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

Lee he "hid it in plain sight":

 

The attiny85 is currently the current device in Studio.

 

I wonder if it's possible to come up with a color combination that is more difficult to read than this?!? (*)

 

I thought you knew anyway as you showed iotnx5.h? As I say this file does not define PORTB1 but portpins.h does - so this is all a storm in a tea cup - if OP had actually tried to build the code he'd have found it works - sadly young folks seem to be far more trusting of the eye candy in these build systems and simply fail to trust the core part of everything which is whether the compiler likes it or not:

$ cat avr.c
#include <avr/io.h>

int main(void) {
    while(1) {
        PORTB = (1 << PORTB1);
    }
}
$ avr-gcc -mmcu=attiny85 -Os avr.c -o avr.elf
$ 
[notice lack of any kind of warning or error]

(*) curious irony - http://www.continental-corporati... - my company's corporate scheme is very similar but we have the good grace to put the orange on black not black on orange. Actually, now I look at that, perhaps orange on black is actually worse? (of course "Orange is the new Black" anyway!)

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

@claswson, thanks again for that thorough explanation.  Sometimes I feel like it was only a month or so ago I wrote my last "GOTO" statement.  Now, I'm seeing behind the curtain.

 

Sorry about the color combination.  It looked okay in my browser.

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

clawson wrote:
if OP had actually tried to build the code he'd have found it works - sadly young folks seem to be far more trusting of the eye candy in these build systems and simply fail to trust the core part of everything which is whether the compiler likes it or not:

Age discrimination before you know the age of the OP? cheeky

 

If you remember I had run into this same issue, but I compiles the code and saw no compile errors but the output screen had 131.  Morten pointed out that on the left hand side of the window there was a little 'N' indicating it was a Naggy issue.

 

Here:

https://www.avrfreaks.net/forum/s...

 

Now in defense of the OP Cliff, I too trusted my eyes and what was being reported back to me.  Beat me up for maybe not knowing better, but I think you are being a little harsh on someone that is not at your level(like anyone of us mere mortals are for that matter).

 

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

 

"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 user

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

Thanks Jim... certainly age (and gender), let's call it assumption rather than discrimination but also, I'd like to point out that "Naggy" shows me far far FAR more that really IS wrong that the occasional, "Oh, look at the exception."  Now that I know Naggy can be wrong (I never experienced that with any other IDE before now), I'll try to be more aware and who knows?  Maybe I will go ahead and hit the build button before searching for answers.

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

chipz wrote:
Maybe I will go ahead and hit the build button before searching for answers.

I learned that the hard way.

 

chipz wrote:
Thanks Jim... certainly age (and gender), let's call it assumption rather than discrimination

I was busting Cliff's stones.  He's one of the most knowledgeable and most patient here, so my comment was almost purely teasing him.  Please do not read into that as something its not. smiley

 

Long Story short when in doubt hit F7.  Will not cost you anything and you get your answer(s) right away.

 

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

 

"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 user

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

jgmdesign wrote:

I was busting Cliff's stones.  He's one of the most knowledgeable and most patient here, so my comment was almost purely teasing him.  Please do not read into that as something its not. smiley

 

Oh I know! My intent was the same as yours.  Cliff has been a BIG help to me on more than one occasion. angel

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

chipz wrote:
Now that I know Naggy can be wrong (I never experienced that with any other IDE before now)

All functions in all IDEs have bugs of one kind of another - all software does. So don't ever be trusting of ANY software you ever encounter (though if it's the fly-by-wire that is currently landing you B737 or A330 then I guess you have to HOPE it's OK!). Naggy is just an extension to Studio. It's written by a very knowledgeable and talented guy (he works on the Atmel variant of avr-gcc as a day job) but it will have limitations because of the way it works. It passes the C you are currently typing into a different C compiler to the one you will eventually build the code with then it captures the warnings/errors and uses those to advise about problems that it has noticed in what you are typing. The difference in compilers means that it could (and does!) get different results some times from what avr-gcc is going to eventually say/do. So hold that thought in mind when you are looking at your red squiggles. It's a brilliant tool and a great help 99% of the time but once in a while it's going to flag false positives. If in any doubt actually build the code. If both compilers agree there is a fault then it turned out to be useful. If it compiles clean then LLVM interpreted something differently to GCC. As I've said elsewhere there is some kind of "black list" mechanism where you can tag false positive warnings to say "don't tell me about .. in future as you are wrong" but I can't remember off-hand how that works right now.

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

clawson wrote:
All functions in all IDEs have bugs of one kind of another

Indeed.

 

Eclipse can also get its "assistance" in a twist - flagging things as "undefined" when they clearly are defined!

 

angry

 

It's worse with Eclipse, as these can appear as error messages after a build - so you can have a successful build with errors!!

 

surprise

 

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...