Byte variable math, can calculations be greater than 255?

[Brian Z]

I am getting a servo pulse length via a pulsin command, then averaging its value with 150. Will this math work with a byte variable (that should pulsin at between 100-200) since when I add it to 150 it may be as high as 350 before dividing it by two, even though the math is on one line?

let b0 = b0 + 150 / 2

 

[bpowell]

Setting B0 to 200, then using your code above worked for me ... I added 150 to 200 (350) then divided by 2, and the PICAXE gave the result of 175.

So, unless that math was done in the compiler ... it appears you can work with numbers larger than bytes during calculations....but the result you store in B0 must be between 0 - 255.


Edit: I wrote a quick loop to increment the initial setting of B0, just to ensure the PICAXE is doing the math, and not the complier ... still works. So the answer is, "Yes"

 

[westaust55]

Yes, internally during a calculation the math is to 16 bits (0 to 65535)
even when the variable into which the final result is stored is defined as a byte (8 bits) so long as the intermediate math within a calculation does not exceed 65535 then the result is correct.

 

[AllyCat]

Hi,

Yes, of course the above answers are correct, but occasionally the Compiler (or Program Editor) can work to "double-word" accuracy (7+ digits or 31 bits to be precise). It can be useful, for example to show how some "Magic Numbers" have been derived:

symbol LowWord  = 12345678 // 65536
symbol HighWord  = 12345678 / 65536
sertxd (#HighWord," : ",#LowWord)

...then averaging its value with 150.

Strictly, it's not "averaging" (or it's a special case where one of the numbers is constant), more a scaling by a factor of 1/2. Such calculations are often needed with Servos and there was a Recent Thread on the topic. That has a link to a Definitive Code Snippet in post #4, or if you really want to mangle your brain, try post #6.

Cheers, Alan.

 

[Brian Z]

Thanks everybody! I'm in the early stages of making a three channel servo signal translator to control a three wheeled omni-wheel robot with a standard RC controller. A while back I thought I couldn't do three pulsin commands with three servo and servopos commands at the same time, but now I can't remember why I thought that, so I'm going for it. Making the pulsin half as close to 150 as it really is, is for the front wheels in comparison to the back wheel when doing a left-right "slide".

 

[AllyCat]

Hi,

You might find that the PICaxe can't read all three pulses within the same 20 ms Servo Pulse cycle. If the transmitter has more than 3 "channels" then you might be able to select three channels with sufficient spacing, but otherwise you may need to read channels 1 and 3 consecutively and then channel 2, 20 ms later. But once set, the PICaxe will continuously output all three pulses every 20 ms, without any further instructions (until a servo position needs to be changed).

Cheers, Alan.

 

[Aries]

Setting B0 to 200, then using your code above worked for me ... I added 150 to 200 (350) then divided by 2, and the PICAXE gave the result of 175.

So, unless that math was done in the compiler ... it appears you can work with numbers larger than bytes during calculations....but the result you store in B0 must be between 0 - 255.


Edit: I wrote a quick loop to increment the initial setting of B0, just to ensure the PICAXE is doing the math, and not the complier ... still works. So the answer is, "Yes"

Given that B0 is always a variable, there is no way that the compiler could do the calculation rather than the Picaxe itself. Even if the compiler spotted the 150/2, it could do nothing useful with it, because it still has to divide B0 by 2. In general, I think it's fair to say that the compiler works quite blindly, and compiles what you write, rather than doing any shortcuts. For example:

b0 = 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10
b0 = 55

The first line compiles in isolation as 18 bytes, the second as 5 bytes. So the compiler is not recognising the opportunity for simple addition.

 

[bpowell]

The first line compiles in isolation as 18 bytes, the second as 5 bytes. So the compiler is not recognising the opportunity for simple addition.

Good investigation!