Printable View
+23 is just an ODD number. You can have any ODD number here - even ONE. If you use an even number, you will not have 256 random seedings, but 128. I'll leave you to figure why.
If W0 is made up of B0 and B1, then by changing either of those don't you change W0 accordingly? And if you change W0 then don't you similarly affect B0 and B1? Please see the table on page 22 of the PBC manual along with the first paragraph of Section 4.6...
I'll have to think on the even/odd number thing.
I get you on the w0, b0 and b1. They are attached to each other so anything done to one affects one or both of the remaining two.
If I had this:
w0=3250
write 0,b0
write 1,b1
That would write the entire WORD to eeprom correct?
And, if I did this:
read 0,b0
read 1,b1
number = w0
The variable called "number" would be intact as 3250? (never mind that I probably don't need to read it since it is still intact as w0 to begin with)
Bart
Okay, I've taken the code sample that was based on PBC and wrote out how I see the bits being used at a line by line level. I came up with this:
* Program starts for the evening for the first time ever:
<b>Read 0,B0</b>
(B0 now contains %00000000 as it has not had anything wrote to it yet)
<b>W0=W0+23</b>
(W0 now contains %0000000000010111 as W0 is a 16 bit WORD and 23 was added to, basically, zero)
<b>Write 0,B0</b>
(B0 now contains %00000000 as B0 just saves the first 8 bits of the 16 bit WORD to eeprom)
<b>Loop:
RANDOM W0</b>
(W0 is a new RANDOM 16 bit WORD seeded with %0000000000010111 as W0 has not been reset yet with a power down and I have to assume the 16 bit value is stored somewhere other than eeprom for general operations)
<b>B2=W0 & $000F
Gosub BlinkyLight
Goto Loop</b>
(Not addressed in this example since I'm only interested in the eeprom seed value.)
As I see this, each time the chip starts up it is only reading and writing a ZERO back to the eeprom for the next seed. Perhaps if B1 was used instead of B0 or even both?
So, what am I missing here with the bits and writing out what is happening at a BIT level?
Bart
PS. hold the phone. I think I answered this myself. The bit count starts on the right and moves left, not on the left and moving right. Am I right? If I do have my example backward here then B0 is still correct and it would save something different each time.
I'm still working on the odd and even issue though.
Now I want to tackle the bitwise AND & syntax.
I think I am clear now on how we've come up with our 16 bit WORD seeds and what not.
For this example it is W0=%0000000011101101
When something like this is done:
<b>randomlight=W0 & $000F</b>
it is also like saying:
<b>randomlight=W0 & %1111</b> correct?
It is comparing the first four bits of the word so it looks like this:
<b>%0000000011101101</b> - original word
<b>%0000000000001111</b> - AND compare on bitlevel (narrow it down to 16 or less)
<b>%0000000000001101</b> - result of the compare
No matter how you compare with the second set of bits the results is the first four bits of the first set. The "&000F" is just a handy way of stripping away the bits that aren't needed?
My result comes back as a decimal 13 in this case.
But if I do it wanting to pick from 15 lights instead:
<b>%0000000011101101</b> - original word
<b>%0000000000001110</b> - AND compare on bitlevel (narrow it down to 15 or less)
<b>%0000000000001100</b> - result of the compare
Decimal 12
If I wanted to I could compare any number of bits by adjusting the second row of numbers so I could use & %00FF to come up with:
<b>%0000000011101101</b> - original word
<b>%0000000011111111</b> - AND compare on bitlevel (narrow it down to 255 or less)
<b>%0000000011101101</b> - result of the compare
Decimal 237
<b>%0001011011101001</b> - original word
<b>%0000000011111110</b> - AND compare on bitlevel (narrow it down to 254 or less)
<b>%0000000011101000</b> - result of the compare
Decimal 232
The only problem here is that I don't see where the results are <em>seldom</em> different in the final row than what the original first few bits in all the examples I also did on paper unless the second row has lots of zeros compared to the first row so I think I am missing a key point?
It is getting a little confusing now understanding the exact function of bitwise AND. Can someone expand to fill in the gaps here?
Am I, at least, close on this operation?
Thanks.
Bart
I'm on the run today, so ultra-fast replies...
* Program starts for the evening for the first time ever:
Read 0,B0
(B0 now contains %00000000 as it has not had anything wrote to it yet)
W0=W0+23
(W0 now contains %0000000000010111 as W0 is a 16 bit WORD and 23 was added to, basically, zero)
...and B0 has 00010111 inside it!
Write 0,B0
(B0 now contains %00010111 as B0 just saves the first 8 bits of the 16 bit WORD to eeprom)
We're assuming all along that B0 is the LOWER 8 bits (bits 0 thru 7). If it happens to be the UPPER (bits 8 thru 15), then rather than playing with B0, we simply play with B1 instead. You can find out which is which through simple experimentation.
Loop:
RANDOM W0
So, first time around, 23 gets saved to EEPROM, next time its 46, next time it's...
So, what am I missing here with the bits and writing out what is happening at a BIT level?
I think you figured it!
You're smack-on with the bitwise compare examples. I don't see you're confusion, all your examples are 100% correct.
I guess my confusion is in the result. I was expecting it to be <em>more</em> different than the original if that makes sense. I guess it really is since using %00001111 on something like %10011101 it does make it different.
So, in your examples all that & $000F is there for is to get rid of ALL other bits except the first four? That's how it is used in this project, but & could have other uses besides "bit stripping"?
In fact, this could also be used for my case of only wanting a "0" or a "1" by making it $0001 or %00000001
<b>%0001101101011011</b>
<b>%0000000000000001</b>
<b>%0000000000000001</b> results
Decimal: 1
<b>%0001101101011010</b>
<b>%0000000000000001</b>
<b>%0000000000000000</b> results
Decimal: 0
I'm getting ideas....
The even/odd still has me puzzled, but I will need to read the thread again now and see if it makes more sense.
Thanks,
Bart
Okay. Honestly, I don't see this. The closest thing I can come up with it that by using an ODD number the first bit will alternate between 0 and 1 where as if an EVEN number is used the first bit will always be 0 which would mean 128 bytes possibilities wouldn't come up.Quote:
Originally posted by Melanie
+23 is just an ODD number. You can have any ODD number here - even ONE. If you use an even number, you will not have 256 random seedings, but 128. I'll leave you to figure why.
In reality though we're adding a number to a RANDOM number which could be odd or even and always saving just half the WORD anyway so all 256 possbilities for the seed number should come up over time.
This is the only thing I can think of, but it brings back another point.
If I continue to add a number to the eeprom eventually, as you mentioned, the bytes are going to add up to more than 256. Using 23 it would take no time at all to "fill up". How is this handled by the program?
<b>Read 0,B0
W0=W0+23
If W0>65535 then... </b> ?? What the heck happens. It can't be more than 65535. Does the system truncuate it to 65535 so I can still <b>Write 0,B0</b> ?
Or does the result cause a crash?
Thanks.
Bart
No it won't crash... you'll just ignore the upper 8 bits... it'll work like this...
The first column is initial EEPROM Contents, the second column is after you've added 23 (remember 23 is just an ODD number I've pulled out of a hat), and the third column is what is saved back to EEPROM for the next evening...
Since only the lower 8 bits of the word are saved, the saved value can only be in the range 0-255.Code:Start Random Saved to
EEPROM seed EEPROM
Value (+23) Value
------ ------ --------
0 23 23
23 46 46
46 69 69
69 92 92
92 115 115
115 138 138
138 161 161
161 184 184
184 207 207
207 230 230
230 253 253
253 276 20
20 43 43
43 66 66
etc etc
Can you see now what's happening in your EEPROM location?
when you get to 253 in EEPROM, you add 23 and W0 becomes 276, but because you're only saving the eight lower bits of W0 back to EEPROM, the actual value you save will be 20...
And yes, with the ODD/EVEN offset, if you use an EVEN offset you will never seed an ODD number, so you can't possibly have more than 128 seed values, whereas if you use an ODD number, you will eventually rotate through all 256 values.
This arrangement gives you a nice seeding whereby the homeowner should never be able to recognise any sequences as repeating themseves... in theory it should be 256 days before the sequence repeats.
Melanie
Perfect sense.
When I wrote last night I was writing +23, but in my mind I was thinking that we were adding a random number not a constant so I was seeing both odd and even possibilities being wrote.
So, I guess that indirectly I knew the answer! :-)
Couldn't this:
Read 0,B0
W0=W0+23
Write 0,B0
also be written as:
Read 0,B0
B0=B0+23
Write 0,B0
Even when I use RANDOM W0 later it should know W0 to be somethig like %0000000011011011 since a B0 value was previously written at start up?
I'm going to post a bit of code sometime today. I've been thinking about it using my new found knowledge of bit locations. I'm curious if it would work.
Thanks.
Bart
Yes you can do as per your example, as long as your RANDOM statement uses W0 (or it's assigned name).
One other thing that we discussed briefly.
The B0 or B1 bytes store only the bottom or top byte of the word so the maxium value in either would be 256 so we get 256 seeds if we use the odd number addition. Good for one different random cycle each night for 256 nights.
If I read and write BOTH B0 and B1 to eeprom addresses 00 and 01 then, using the odd number addition. I could get up to 65535 seeds correct?
Or, as you say, enough for 179 years of a different random combination each night? More than anyone could keep track of even if they wanted to.
Right or wrong?
Bart
Right... but what's the point? As if anyone's going to even remember 256 combinations.
No point. Just wanted to make sure I had my head around it.
Can't you remember 256 combinations? What kind of <em>Simon</b> player are you? :-)
Bart
dumbdumbdumb!