Accessing specific memory locations

Quote:

---

Originally Posted by Bladactania

So why is it necessary to get the original value?

And what if I was using the 4th bit instead of the 0th bit?

---

Because presumably the other bits do something else than the LED. (As listed on page 29 of the manual you posted.)

But I was under the impression that using 0x01 in both cases (setting to 1 and setting to 0) only effects the 0th bit. Therefore, whetever the values of the other 7 bits are doesn't matter (if I only care about the LED)

Actually, it seems like 0x77, aside from bit 0 is read-only, so it may not be important to keep retain the bit values.

I'm just "programmed" to be careful about bits in hardware registers. If you want to change ONE bit, then you do not REALLY want to change any of the others by mistake - it can have all sorts of dire consequences.

--
Mats

But how does getting the original value prevent me from altering the other bits? How WOULD I change the other bits if I wanted to? And is there a way to print out the binary value of the byte so I can actually see what the values are?

Quote:

---

Originally Posted by Bladactania

But how does getting the original value prevent me from altering the other bits?

---

Is this a serious question? I'm not sure how to answer it. How do you create a value that is "all bits the same except the last" if you don't know what the value of the bits are?

Quote:

---

Originally Posted by Bladactania

How WOULD I change the other bits if I wanted to? And is there a way to print out the binary value of the byte so I can actually see what the values are?

---

I don't know why you think changing bit 4 would be different in any meaningful way than changing bit 0. Bit 4 is 10000b instead of 1b, but that's all.

You can print out hex with %x, which is just like binary, except better.

Normally, we use hex (or, rarely, octal) to signify binary, simply because binary tends to get "big" very quickly, and translating to&from hex isn't very hard.

By reading the value and only changing bit 0, you make sure that no other values are being changed when you write it back [1] the modified value.


[1] This assumes that no other code is also acccessing the same register - if that is the case, you would need to use some form of locking to prevent multiple access.

--
Mats

I'm obviously missing some key underlying principle here.

Quote:

---

Originally Posted by Bladactania

I'm obviously missing some key underlying principle here.

---

Not sure, but if you have variables x and y, if you modify x, you wouldn't want (or expect) y to change as well, right? The same applies to bits. If you want to toggle the LED on and off, you do NOT want to modify any of the other bits in that register [although in this particular case, it is harmless to do so, it is a good idea to get a habit of only modifying the bits that really matter].

--
Mats

Quote:

---

Originally Posted by Bladactania

I'm obviously missing some key underlying principle here.

---

I'm not sure whether you're referring to the keeping of the bits or the hex or what.

If you do something like

Code:

---

outport(LED, 0x01);

---

then you are going to write a 1 in bit 0 and a 0 in all the other bits. Now, we didn't want to change the other bits ('cause maybe they weren't 0 -- they're based on jumper settings, as I recall). I don't know enough about the hardware to know whether the write will just fail if you try to change those, or if it will only change the bits that are writable, or what. But, in general, when each bit means something different you need to be careful that you only change the bit(s) you want to change. So if the current state of 0x77 was, say, 0x5A, and we want to turn the LED on, then we want to write 0x5B back to LED. That's what the bitwise operators do for us: 0x5A | 0x01 = 0x5B. If the current state of 0x77 was that 0x5B and we want to turn the LED off, then we unset bit 1 with the negated bitmask: 0x5B & (~0x01) = 0x5A, and we write that back.

Ok, that helps! Let me try something here... Let's say that I have a byte that is "01000100" or 0x44. I want to turn "on" bit #4 (make it "01010100" or 0x54). So I would want to write back 0x44 | 0x10 right?

And then to turn that bit "off" again I want to write back 0x54 & (~0x10).

Quote:

---

Originally Posted by Bladactania

Ok, that helps! Let me try something here... Let's say that I have a byte that is "01000100" or 0x44. I want to turn "on" bit #4 (make it "01010100" or 0x54). So I would want to write back 0x44 | 0x10 right?

And then to turn that bit "off" again I want to write back 0x54 & (~0x10).

---

Correct.

--
Mats

Excellent! One more "test" :)

"01000100" (0x44) -> "01100110" (0x66) : 0x44 | 0x22
"01100110" (0x66) -> "01000100" (0x44) : 0x64 & (~0x22)

or I could do 0x44 ^ 0x22 twice...

Yes, you are getting it.

--
Mats

Fantastic! Thank you all for your help!

I'm back!! Ok, I think I've got my head around how to work with one bit at a time... Now, how do I work with the whole byte at the same time...

Here is the Manual I'm refering to If you need to see it - Page 6

So I need to set all the bits simultaneously, so I can't alter each bit one by one. Of the 8 bit byte, there are 3 bits (Bit 3, 5, and 6) that are reserved that I cannot set and don't want to read from. 3 bits (0-2) are used to specify the channel (1-8). 1 bit (bit 4) is used to specify a setting (I will always use logic 1 here) and Bit 7 which reads 1 when the data can be read (from antoher byte).

Now I'm guessing I can declare a "temp" variable and set each bit to how I want it to be and then outportb it. However I'm not sure how to prevent myself from altering the 3 reserved bits. When I read this byte, to test for readiness (bit 7) I only have to deal with the one bit and can handle that with no problem...