## Logic Questions

23 posts / 0 new
Author
Message

Hello again,

I guess I could bother Smiley directly but I figure he will jump in if he has time...I think I drove Mark Alberts nuts (:-)) after my BASCOM purchase so I am more cautious now and the net makes getting help too easy sometimes. OK enough banter..

In the following statement:

(TCCORA & WGM01) I had a knee-jerk reaction that one was a byte value 'TCCORA' and the other is a bit value that is part of the TCCORA byte. So then, using Smiley's original value for TCCORA of 01001100 and the fact that bit WGM01 of that byte is "set" we could say the following:

TCCORA = 01001100
WGM01 = 00001000

and if we '&' AND them together we get 00001000 which means that any non-zero result makes the statement true?? Regardless (and this is what was throughing me) of the decimal result?

It is difficult for me to look at WGM01 as a bit value when I see that value...because of it's location in TCCORA as a byte (0x08) ? As long as my thinking is correct on this I can accept it. Am I missing anything?

Also:

In the statement:

for(int i = 1; i < 128; i = i* 2)

How come we do not evaluate the 'i = i * 2' part on our first pass?

The statement is in the parenthesis. Why move on after the i < 128 part?

PS: I hope I am under the right Forum topic!!

Thanks
John

Just some guy

In what context did you see:

`(TCCORA & WGM01)`

surely it would have been:

`(TCCORA & (1<<WGM01))`

????

Quote:

In the statement:
for(int i = 1; i < 128; i = i* 2)
How come we do not evaluate the 'i = i * 2' part on our first pass?

The i=i*2 is evaluated in the first pass of the loop, but at the end of it (after everything else in the 'body' of the for-statement).

So for this:

```for(int i = 1; i < 128; i = i* 2) {
do_something();
}```

This is what happends:
1. set i to 1
2. if i < 128 then continue on with 3. Otherwise, go directly to 6.
3. do_something()
4. i = i * 2
5. go back to 2.
6. Exit point of the loop

Do a Google for "C tutorial" and you will get loads of hits that will try to explain the diferent constructs of the C language. Eg this: http://www.physics.drexel.edu/co...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Hello,

Yes that was the first part of Smiley's tutorial and then...He begins a simple string of code to 'monitor' the TCCORA register. The whole statement looks like this:

if((!TCCORA & WGM01) && !(TCCORA & WGM00) )

And there is more below..this is just a snippet!

John

Just some guy

Thanks Johan but, what keeps the 'i' from becoming a 2 from the i=i * 2??

John

Just some guy

And get a copy of K&R (the ANSI edition). It's not exactly a "tutorial guide" but it's an invaluable reference on C ("the bible" in fact).

As copyright allows for copying up to 10% of a published work for "research" I don't think it invalidates the copyright to say that it has the following on for() loops:

Quote:
In the for statement, the first expression is evaluated once, and thus specifies initialization for
the loop. There is no restriction on its type. The second expression must have arithmetic or
pointer type; it is evaluated before each iteration, and if it becomes equal to 0, the for is
terminated. The third expression is evaluated after each iteration, and thus specifies a reinitialization
for the loop. There is no restriction on its type. Side-effects from each expression
are completed immediately after its evaluation. If the substatement does not contain continue

It also points out that:

`for (expression1; expression2; expression3) statement`

is exactly equivalent to:

```expression1;
while (expression2) {
statement
expression3;
}```

Which is hopefully enough of a taster to persuade you to buy it!

Thanks Cliff!!

I just keep moving on.. I hope I am correct about the "ANDING" of the TCCROA & WGM01...if I stop for too long I might forget everything!!

Whew!
John

Just some guy

ON the K&R part: Smiley recommends the purchase at the beginning of his book!!

I will get it ordered!!

Thanks,

John

Just some guy

Quote:
I just keep moving on.. I hope I am correct about the "ANDING" of the TCCROA & WGM01...if I stop for too long I might forget everything!!

If WGM00 and WGM01 are bit positions then you certainly need to express it as (1<<WGM00).

Yes thank you...I am working my way through Smiley's book and what I have written is an example directly out of Smiley's book. I know about setting the bit but, am puzzled when we do a bitwise 'and' between the WGM01 bit and the TCCORA byte??

John

PS: CLiff, I purchased the book (THE C PROGRAMMING LANGUAGE) on the way home from my morning coffee:-)

I am not progressing at the speed I was hoping...

Just some guy

John,

If you hang out on on alt.folklore.computers you'll find that Dennis Ritchie hangs out there too :)

Neil

Thanks Neil,

But, the more I learn about "C" the more I think...That guy is crazy!! Just kidding :lol:

Actually, as I work through Smiley's book the ANDING I was referring to above is a test to see how the timer is set up...Not that I understand yet...

John

Just some guy

Hi John,

Have a look at the errata on Smiley's site.

Quote:

Original--> if(!(TCCORA & WGM01)&& !(TCCORA & WGM00))
Fixed-----> if(!(TCCORA & (1<<WGM01))&& !(TCCORA & (1<<WGM00)))
-----------------------------------------------------

Wow thanks...

That helps a bunch! Now it sinks in: Then the code he has tests the WGM01, WGM00 bits to determine which of the four timer configurations are programmed. Still, I am not sure that I could have created that logical test myself. Although I doubt I speak for all beginners, I can tell you that when you guys talk about registers...my eyes start to glaze over! So, it is very exciting to start to learn about them!

CirMicro, thanks a great deal! I was scratching my head on that one..I will check Smileys site more often!

John

Just some guy

johnrk wrote:
Still, I am not sure that I could have created that logical test myself.

Bet you could you know! Just read this:

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

(that's ESSENTIAL information for all embedded C programmers who ever plan to make bit accesses)

Thanks again.

Notice this portion:

Quote:

To see if a bit is set or clear just requires the AND operator, but with no assignment. To see if bit 7 is set in the variable foo:

Code:
if(foo & 0x80)
{
}

The condition will be zero if the bit is clear, and the condition will be non-zero if the bit is set. NOTE! The condition will be NON-ZERO when the bit is set. But the condition will not NECESSARILY BE ONE. It is left to the reader to calculate the value of the condition to understand why this is the case.

So then that says that Smiley's original code was written correctly. Even though he was using WGM01 as the mask?? I did check the errata and it would be confusing to use the bit name as the mask and give it a value but, according to the tutorial it seems it could be done that way. Could it?

HHHMMM

JOHN

Just some guy

No, as already pointed out, the book contained an error which was corrected by the errata on the web site. Sounds like it's time to go through your copy with a marker pen and make the corrections from the errata.

OK then, I will print the errata and get back into the book!

Thanks for the help!

John

Just some guy

Not sure if this helps or complicates but just so you know, the header file that will be used when you build mega169 programs for use on the Butterfly contains:

```/* TCCR0A */
#define FOC0A	7
#define WGM00	6
#define COM0A1	5
#define COM0A0	4
#define WGM01	3
#define CS02	2
#define CS01	1
#define CS00	0```

So WGM01 is equal to 3. Therefore:

`TCCR0A & WGM01`

is exactly equivalent to:

`TCCR0A & 3`

(in other words are both bits 0 and 1 equal to 1?). While:

`TCCR0A & (1<<WGM01)`

is equivalent to:

`TCCR0A & (1<<3)`

which is equivalent to:

`TCCR0A & 0x08`

In other words "is bit 3 equal to 1?"

Cliff

Yes that helps. I was able to find the TCCROA #define by doing a file search for 'iom169.h' but, I have no clue yet what type of file that is! At first, when it was referenced I thought I was supposed to be running it in the AVR Studio 4 simulator but, '.h' is not '.hex' as I found out :oops:

Also, per the tutorial:

Quote:
Which ends up shifting the constant 0 bytes to the left, leaving it at 0x01.

Shouldn't this read, "..the constant 0 bits.."??

Or am I just not getting it?

Thanks
John

Just some guy

Yup that bits/bytes looks like a typo.

As for what TCCR0A in a 169 really is. When the music stops and the dust settles

`TCCR0A = 0x37;`

becomes:

`(*(volatile uint8_t *)((0x24) + 0x20)) = 0x37;`

which is just a SHADE more complicated than:

`#define WGM01   3`

but you don't really need to worry about that. Just take it as read that when you say "TCCR0A" you are really reading/writing the IO register at location 0x24 (if IN/OUT is being used) or 0x44 (if LDS/STS is being used)

Cliff

PS Oh and:

`if (TCCR0A & (1<<WGM01)) {`

becomes:

` if ((*(volatile uint8_t *)((0x24) + 0x20)) & (1<<3)) {`

Cliff,

I will keep your last post in mind and see if it meshes as I move forward! However,

Quote:

So WGM01 is equal to 3. Therefore:
Code:
TCCR0A & WGM01

is exactly equivalent to:
Code:
TCCR0A & 3

(in other words are both bits 0 and 1 equal to 1?). While:
Code:
TCCR0A & (1<<WGM01)

is equivalent to:
Code:
TCCR0A & (1<<3)

which is equivalent to:
Code:
TCCR0A & 0x08

In other words "is bit 3 equal to 1?"

Cliff

That really helped!!

Thanks, John

Just some guy