converting BCD question
![KC8DKT](https://forums.parallax.com/uploads/userpics/894/n3L6Z13ZPA1ZK.jpg)
why does this not work
but this does
When converting BCD to DEC?· Not a big deal I know but its bugging me not knowing.
temp(1) = temp.NIB1(1)*10+temp.NIB0(1)
but this does
Temp = Temp(1) Temp(1) = Temp.NIB1*10+Temp.NIB0
When converting BCD to DEC?· Not a big deal I know but its bugging me not knowing.
Comments
· temp(1) = (temp(1) >> 4 * 10) + (temp(1) & $0F)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
debug myBytes.HIGHNIB(1)
I seen this in the help file and got the idea it would work with math, my bad, Thanks for the info and new formula.
time··· VAR···· Byte(3)
you can do this:
time··· VAR···· Byte
secs··· VAR···· time
mins··· VAR···· Byte
hrs···· VAR···· Byte
Using this strategy you can access secs as time(0), mins as time(1), and hrs as time(2).· But now you can do direct access as well.· So now you can use the BCD conversion:
· secs = (secs.NIB1 * 10) + secs.NIB0
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
After messing with this I rememberd reading about an array bug some where. Keep in mind that PBasic saves Large to small as well!
temp1 VAR Byte
temp2 var byte
temp3 var word
temp1(0) = 1
temp1(1) = 1
temp1(2) = 1
temp2 = 2
temp3 = 3
debug temp1(0) = 1
temp1(1) = 2
temp1(2) = 1 Word saved before byte. This would be the problem the bug could lead too.
No idea how this helps anyone but it was fun.
Quite regardless of whether there is an actual "bug" or not (which I rather doubt), your example leaves a bit of unfairness behind in its wake. Here's what I mean.
In total, your example works with FOUR bytes, TWO BYTES represented by temp1 and temp2 (one byte each) as well as TWO BYTES from temp3 (a WORD or two bytes), so it would make a good deal more sense to VIEW all FOUR bytes, after the fact, to examine their COMPLETE contents like this:
debug temp1(0), temp1(1), temp1(2), temp1(3)
or
debug temp1, temp2, temp3
Anything less than that hides some of the contents. Personally, in terms of proper and complete examination, I'd much rather see:
DEBUG IHEX? temp1, IHEX? temp2, IHEX4? temp3
but that's just the inherent bit-wacker in me talking
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Word
Byte
Nib
Bit
So your declaration:
temp1·· VAR··· ·Byte
temp2·· VAR··· ·Byte
temp3·· VAR··· ·Word
... would actually be stored in memory (as bytes) in this order:
temp3.LOWBYTE
temp3.HIGHBYTE
temp1
temp2
I guess another point I should have made absolutely clear is that implicit arrays only work with variables of the same type.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
A word of caution about arrays: If you're familiar with other BASICs and have used their arrays, you have probably run into the "subscript out of range" error. Subscript is another term for the index value. It is out-of-range when it exceeds the maximum value for the size of the array. For instance, in the example above, myBytes is a 10-cell array. Allowable index numbers are 0 through 9. If your program exceeds this range, PBASIC will not respond with an error message. Instead, it will access the next RAM location past the end of the array. If you are not careful about this, it can cause ALL SORTS OF BUGS.
Its in the new Help File for PBasic 2.2.5
Anyways, thanks for the new BCD line. Your new array(idx) fix worked out great for one small loop doing input & output converts too and from the RTC...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax