AVR Freaks

Do not cross post and do not post to tutorials except to suggest improvements to the original article.

The last 202,030 people who have read this thread clearly understood the reason. If you don't I can only suggest you re-read until you understand. Also see the point I just made regarding bit number vs. bit mask in your cross-post.

You came to the wrong tutorial, try this one:

https://www.avrfreaks.net/index.p...

Having said that it's pretty clear you haven't even read the whole of this thread:

https://www.avrfreaks.net/index.p...

First, this requires a ";" at the end of it. Second, once you define it, you never use it (just putting .bit0 after some random variable will not work). Third, stop using macros until you actually know how to code. Using macros at this point can only introduce more errors than you already have.

And how do you know that this does not stomp on something that is already at that address?

What are var_A and var_B for when you never use them?

Where do you ever define RAM_test?

The only thing that I see that it does is obfuscate the code.

Or just drop the ==1, anything non-zero is true. hence:

But why not use danni's macros:

https://www.avrfreaks.net/index.p...

then you can:

which seems more readable to me than having to invoke some Read() macro.

But that is EXACTLY what's explained in this very tutorial? I'm not going to repeat the text of the tutorial here so I suggest you go back to page 1 and re-read it until you understand what it is saying.

Maybe it helps to add that:

1) OR and only switch additional bits from 0 to 1
2) AND can only switch additional bits from 1 to 0
3) << means move the thing on the left the number of places given on the right. If the thing on the left is just 1 then it's saying "form a number with 1 in bit position ". This therefore converts a bit number to a bit mask.

Hi, Great tutorial and how I got to get to grips with bit manipulation, still v new to it all though.
Now I am writing a program with several I/Os and I used the SBIT posted and mentioned a few times in this Tutorial.
I used it in places for control of pins eg

also I defined ON=1 and OFF=0
so something like

seems to work.
Then I needed some flags for telling me various states of things so I added a register

and thought I could use this eg

so

.
I saw at the bottom of the entry in the TUT that

Now when I compile with Studio 6 I get warnings where I refer to the regester eg If I compile again they go away.

Please can anyone tell me if I am doing something daft and help me understand what the warning means Thanks
Mark

Thanks again for your help,

I think I get it, makes for interesting reading, a little bit over the head of me as a novice. They say a little knowledge is dangerous!
I'm still not sure if I should worry about it.
There seems to be conflicting opinnion in the blog.

1. Welcome to AVRfreaks!

2. Your remark shows that you need to trim your search skills. 2 or 3 weeks to find that tutorial is your problem.

3. You have been searching "for 2 or 3 weeks", but yet you joined AVRfreaks today.. :roll:

The shift operators, as has been remaked by clawson above, are not specific to avr-gcc. They are standard C. Get a good C book. Read. (Or would you expect avr-gcc documentation to hold information about the if- and while-statements, on assignments, on the assignment operator etc too? Of-course bot. The avr-gcc documentation coers what is specific to avr-gcc. For standard C it is any document describing standard C. For GCC specifics it is the GCC documentation. For avr-gcc, most of it is also in the GCC documentation. The GCC documentation is available on The Web. Google it.)

Also, avr-gcc/avrlibc is the work of devoted voluntaries. They do not get paid. You either more or less accept the state of those tools and the documentation that come with them, or you pay money to buy a commercial compiler/IDE and support for it. There is no such thing as a free lunch.

If you not only are new to AVRs and avr-gcc but also to the C programming language then you will have a learning experience ahead of you. There will be no one-stop solution to satisfy all your information needs. You will need at least these:

1. A good C book, or tutorial on the net.

2. The avr-gcc/avrlibc help. If you are using Atmel Studio and the avr-gcc that comes with that then the help is on your hard disk and integrated in Atmel Studio.

3. The data sheet for your AVR model.

4. Tutorials etc on programming AVRs. AVRfreaks have a whole forum devoted to tutorials. Get yourself acquainted with the contents of that forum, and it will serve you well.

5. Help on The Web by unpaid voluntaries. We are here. Your job is to ask your questions in a manner that gets us interested in your problem. Present clear and complete information. Read and give feedback on advice that is given. (A whining post like yours above is not the best way to start out...) By and large the AVRfreaks community will treat you as you treat it.

Once again, welcome to AVRfreaks!

Right here in the tutorial section.

No difference whatsoever. Once the pre-processor is done with parsing the macros and resolving the constants, they all end up as:

The << operator is a part of the C language itself.

The rest of the variations comes not form the C language as such but from what different people have written in header files that you include.

So, to set bit 6 in PORTB you write

E.g. some people think that the use of the << operator is not pretty, or understandable (or whatever) so they hide it behind a macro that they define like so:

And can then write

Now, the use of the explicit '6' here might not seem so troublesome, but for other registers where bits have special meanings it will make for obscure code if the bit number is given as a number. So there are definitions of bit numbers for all the bits of all special purpose registers (the ones where you control UARTS, timers etc..).

If a Timer/Counter Control Register has a bit at position 4 for Timer Overflow Interrupt Enable then you might write

but it would be much clearer to code e.g.

This has then been worked back to the digital I/O ports where the names of those bit numbers simply become e.g. PB0, PB1, PB2...

So now someone can code

or

Again, all variation here is due to what is coded in header files. They are not defined in the C language as such.

Interesting Tutorial. I am going to have to include a lot of this into what I am doing. Makes C so much easier to work with.

EDIT:

In these defines:

Is the 'p' and 'm' a standard 'c' tag, or could I use 'x' and 'y' in their place for example?

Just to be a pedant but this is not C. This is the pre-processor. A lot of people have a lot of trouble trying to see the distinction between the two. When you type:

in your code the C compiler never "see" bit_set() nor p nor m. All it sees is:

The pre-processor has already "eaten" all the bit_set(p,m) stuff before the .i file is even seen by the C compiler.

It can be enlightening to add --save-temps to your compiler options then for a foo.c file you will find that a foo.i file is generated. If you used:

the C compiler sees:

(it's because you don't usually want to type such convoluted nonsense that you use pre-processor macros in the first place - most of the above actually comes from "PORTB" which is also a macro).

I read this several times and although I thought it made sense I of course must be missing something.
In the code below I want to upon start up display two lines of text. Which worked. I then want to look at portb.0 and if it is pressed display what is inside the {}

I tried using the example above but it does not appear to get teh unit to change the screen. I know I am doing something wrong because when I hit pause during debugging, the disassembly window pops up. I am using AS6 and an STK600 with a MEGA2560

What I end up with is the screen scrolling through both sets of texts at a very high rate. And if I hit pause, I get the disassembly window letting me know I screwed up. I am gonna work on this for a few more hours before bed.

EDIT:
I GOT IT TO WORK!!
I found my boo boo's with a lot of reading and google :? but it works now.

I know the indentation sucks. I figured that out after I lost track of my {}'s. But I needed to hold after the screen did it's write. In other words, the screen kept refreshing, so I insert the WHILE statements and there it goes.
I have to admit I have some more reading to do as I found a post elsewhere using the Bit_is_set/Bit_is_clear shortcut as opposed to the & != stuff that made it all happen. I will need to look into how those two statements work better.

Ok off to bed. 3:30am is fast approaching