Pull Up resistor wiring
- Thread starter siafu
- Start date
apostolakisl
Senior Member
siafu said:
Hmmm, that is not what I expected.
I expected -1 and 1. Let me look into this
apostolakisl
Senior Member
Maybe you can't access the first bit? Otherwise, I can't tell why this wouldn't work.
START
SET VAR1 -1
DELAY 1000
ANDB 0x7FFFFFFF VAR1 VAR1
DELAY 2000
END
START
SET VAR1 -1
DELAY 1000
ANDB 0x7FFFFFFF VAR1 VAR1
DELAY 2000
END
fcwilt
Active Member
It's likely 2s complement format. Consider starting from zero (0x00000000). You increment by one and get 0x00000001. But start from zero and decrement by one you get 0xFFFFFFFF which should be negative 1.
In 2s complement format 0x7FFFFFFF is the largest 32 bit positive number and 0x80000000 is the "largest" negative number.
In 2s complement format 0x7FFFFFFF is the largest 32 bit positive number and 0x80000000 is the "largest" negative number.
apostolakisl
Senior Member
After thinking about for a bit, there is no way the first bit can be accessed in the normal fashion if it is determining sign. It would totally screw up all the math. So this was a bust. I'll have to go back to using multiple lines of code to do absolute values.
apostolakisl
Senior Member
az1324 said:
I forget what I did exactly. But it was different. If I recall, the main thing that was the issue was that because I couldn't just test one value against the absolute value of another value, I had to convert it first. This meant that I had to use branching/subroutines that otherwise wouldn't have been necessary.
It would be nice if there was a function like
TSTEQ VAR1 AVAR2
where the A denotes the absolute value. I didn't want the sign of the number to change, I just wanted one line to test the absolute value.
siafu -- stop running random codes, man. just leave your WC alone. 
You should spend time writing out comments of what each line does until you become an expert.
Lou -- that subroutine is the function. Put your value in RAM1, call ABS and the absolute value will be in RAM1 then you can use it to compare.
Reuse it for other values as much as you want. Just make sure RAM1 is free in whatever scope you are calling ABS.
You should spend time writing out comments of what each line does until you become an expert.Lou -- that subroutine is the function. Put your value in RAM1, call ABS and the absolute value will be in RAM1 then you can use it to compare.
Code:
SET RAM1 VAR2
CALLSUB ABS
TSTEQ VAR1 RAM1apostolakisl
Senior Member
az1324 said:siafu -- stop running random codes, man. just leave your WC alone.
Lou -- that subroutine is the function. Put your value in RAM1, call ABS and the absolute value will be in RAM1 then you can use it to compare.
SET RAM1 VAR2
CALLSUB ABS
TSTEQ VAR1 RAM1
Reuse it for other values as much as you want. Just make sure RAM1 is free in whatever scope you are calling ABS.
I understand how it works. It just bugges things up having to call a subroutine. You use 3 lines of code instead of 1, then you have to have a subroutine also. And it blocks a RAM value from holding any values for other things during the time this code runs.
It would seem to be a simple thing for the CAI firmware to add something like
TSTEQ VAR1 AVAR2 where the "A" simply tells it to drop the signage bit during the comparison (effectively making it 0)
And I think Siafu is just having fun. It does no harm in playing with the code. As long as you keep a working copy saved it only takes 10 seconds to reload it. I'm all for it. I went from a theoretical understanding of bitwise to a working knowledge playing with it here.
That is true, but are you close to the code size limit? It is good to dedicate some RAM to working registers anyway, but if you have nested routines you may need more. If you are running out of memory you could start splitting them up into structs w/ packed 1-bit, 8-bit, 16-bit values. Of course then you need to write the packing/unpacking functions.
Similar threads
