Numbers exceeding 65535

[Flash735]

Hi all! A picaxe newbie question.....


I have a program below where I believe it not to be running due to the size of the compution exceeding a word length of 65535. Does picaxe reject program computions larger than 65535 or it only the word storage length? Any thoughts would be appreciated.....

;Pulsin 10-800usec pwmduty 1-2 ms @61hz

symbol val_1 = w0
symbol on_time =w1

symbol val_2 = w2
symbol val_3 = w3

pwmout pwmdiv64, c.2, 255, 64 ;Picaxe 08m2 wizard minimum 61Hz ;start pwm duty cycle at 64 or 6.3% of 1024

do

Pulsin c.3 ,1,val_1 '(1 unit@64mhz = .625us)

on_time = val_1 * 5900/79 + 102400 * 5/ 8 /1000 ; (.625 is equivalent to 5/8) ; (Computations and Variables to large in this equation I believe?)

pwmduty c.2,on_time

pause 1000


loop

 

[nick12ab]

Calculations resulting in numbers greater than 65535 cause the variable to "overflow without warning" so for example 65534+3=1.

A word variable such as w1 can contain numbers up to 65535 and a byte such as b1 can contain up to 255.

 

[john2051]

Hi, I suppose you could use another byte variable that contains number of 65536

We used a similar idea on the sinclair spectrum, but that was a long time ago.
Regards john

 

[westaust55]

in this program line:

on_time = val_1 * 5900/79 + 102400 * 5/ 8 /1000 ; (.625 is equivalent to 5/8) ; (Computations and Variables to large in this equation I believe?)

you are adding in 102,400 which itself is almost double the max value that a word variable can handle.

Maybe if you provide some explanation as to the source of the equation and what it is for someone here can come up with an alternative method/calculation.

When it comes to multiplication, there are the *, ** and if you have an X1/X2 PICAXE part (?)
the */ math functions which allow you to in effect, capture the "overflow" and work with multiplication having results up to 32 bits,
but keeping tabs on the extra data does require care.

 

[Flash735]

Calculations resulting in numbers greater than 65535 cause the variable to "overflow without warning" so for example 65534+3=1.

A word variable such as w1 can contain numbers up to 65535 and a byte such as b1 can contain up to 255.

pulse = 1280 * 5900/79 + 102400 * 5/ 8 /1000 = 123.74

Therefore the equation above would always result in a wrong answer because parts of the internal calculation are more than 65535? Or are the internal calculations above 65535 are ok. Storing the calculated resultant which is over 65535 creates the overflow. Nick is this what you are saying?


Tks

 

[Flash735]

QUOTE=westaust55;189569]in this program line:

on_time = val_1 * 5900/79 + 102400 * 5/ 8 /1000 ; (.625 is equivalent to 5/8) ; (Computations and Variables to large in this equation I believe?)

you are adding in 102,400 which itself is almost double the max value that a word variable can handle.

Maybe if you provide some explanation as to the source of the equation and what it is for someone here can come up with an alternative method/calculation.

When it comes to multiplication, there are the *, ** and if you have an X1/X2 PICAXE part (?)
the */ math fucntions which allow you to in effect, capture the "overflow" and work with multiplication having results up to 32 bits,
but keeping tabs on the extra data does require care.[/QUOTE]


Hi thanks for the replies,

This may provide a clearer picture on the calculations' origination. I have an rc receiver that outputing in the range of 10usec to 800usec. I'm using a 08m2 picaxe to pulsin. I've used the picaxe wizard to determine that pwmout pwmdiv64 will work at 61hz duty rate of 6-12% to drive a motor controller (1-2msec) . This results in an operating duty cycle of 64000usec/.625usec to 123000usec/.625usec or 102400 to 196800; Range 94400.



On the pulsin: It is 16 to 1280, Range 1264


The pwmduty and pwmout may provide a better result than servopos and pulsout which gave me some erratic operation at the ends of the duty cycle. So I wanted to try pwmduty.




Therefore using 08m2:

Pulsin 10-800usec pwmduty 64-123msec @61hz

symbol val_1 = w0
symbol on_time =w1

symbol val_2 = w2
symbol val_3 = w3

pwmout pwmdiv64, c.2, 255, 64 ;Picaxe 08m2 wizard minimum 61Hz ;start pwm duty cycle at 64 or 6.3% of 1024

do

Pulsin c.3 ,1,val_1 '(1 unit@64mhz = .625us)

on_time = val_1 * 5900/79 + 102400 * 5/ 8 /1000 ; (.625 is equivalent to 5/8) ; (5900/79 equivalent to 94400/1264)

pwmduty c.2,on_time

pause 1000

 

[westaust55]

Still seems to be some confusion with the basic facts:

I have an rc receiver that outputing in the range of 10 usec to 800 usec. I'm using a 08m2 picaxe to pulsin.

On the pulsin: It is 16 to 1280, Range 1264

From PICAXE manual2 (V7.7) page 160:

Effect of Increased Clock Speed:
4MHz 10us unit 0.65536s timeout
8MHz 5us unit 0.32768s timeout

Therefore at 4 MHz, each 10 us incoming pulse duration gives a value increment of 1
Thus at you minimum stated 10 usec the PULSIN command will give a result of 1 at 4 MHz, 2 at 8 Mhz, 4 at 16 Mhz, 8 at 32 Mhz ( 32 MHz is the max clock speed for an M2 part).
Unsure how you get a value of "16".
Likewise for the 800 usec max incoming pulse duration, the PULSIN command will give a result of 80 at 4 MHz, 160 at 8 Mhz, 320 at 16 Mhz, 640 at 32 Mhz.

Believe that we need to get the PICAXE type and input data sorted before we advance further.

 

[srnet]

"I have an rc receiver that outputing in the range of 10usec to 800usec."

Strange one, most RC recievers put out a pulse of 1000us to 2000us for servos.

 

[g6ejd]

In your programme lines:

on_time = val_1 * 5900/79 + 102400 * 5/ 8 /1000

You should convert all those constants to their minimal integer form to help prevent overflow, thus:
on_time = val_1 * 74 + 64

You will get the same result, though does'nt stop overflow and surely the compiler will detect those numbers as over size e.g. like 102400? Yes it does, just tried it, so you aren't showing valid code in your example...

Hope this helps.

Try slowing your code examples down by say a factor of 10 and see if the logic is right (i.e. contain the results within a 16-bit number boundary), if you having it running correctly, then consider moving your code to 24 or 32-bit, there are examples in the forum of 32-bit number handling. Unfortunately the compiler does not give access to the CPU Overflow flag just after a maths command and I suppose it would be really difficult to ensure the overflow status was valid for a maths command just executed if other compiler activity is taking place that also would create an overflow, if that makes sense. You would need to put all the tests in your programme to detect all these, but difficult to do, without creating an overflow in doing so.

As a model aircraft flier, I agree with @srnet there are no rc receivers on the market that I'm aware of with output data pulses at that rate, the result would be outside of the inter-channel bandwidth requirements of a standard rc setup of Tx and Rx, the frame-rates are usually 50 or 60Hz and 1mS - 2mS pulse widths with 1.5mS being a centre/neutral servo position. Is it a mis-print?

 

[nick12ab]

Therefore the equation above would always result in a wrong answer because parts of the internal calculation are more than 65535? Or are the internal calculations above 65535 are ok. Storing the calculated resultant which is over 65535 creates the overflow. Nick is this what you are saying?

PICAXE calculations are performed left-to-right so if at any point in your calculation the result causes overflow the rest of the calculation may not perform as expected since the number will be very different from what you expected it to be.

However, the massive number that WestAust has pointed out is what is causing the issue.

 

[Armp]

Got to give the PICAXE a little help when it comes to number crunching.

Rewrite: on_time = val_1 * 5900/79 + 102400 * 5/ 8 /1000 as

on_time = val_1 * (5900/79 * 5/ 8 /1000) + (102400 * 5/ 8 /1000)

Evaluate the terms on the calculator

on_time = val_1 * 0.04668 + 64

Multiply 0.04668 by 2^16 gives 3059, and use the ** operator to divide the result

Gives on_time = val_1 ** 3059 + 64

Never overflows for any value of val_1

 

[Goeytex]

Seems to me what you are trying to do is read the receiver output with pulsin and then then retransmit with PWM.

You already determined with the PWM Wizard that the slowest PWM is 61hz. But that is with the Picaxe set to operate at 4Mhz. So for clarity the program should have the line < setfreq M4 > somewhere at the beginning.

At 4 MHz each pulsin unit represents 10 microseconds not .625us. (.625 is for a Picaxe running at 64 mhz). The 8m2 will not run at 64 MHz yet you are making calculations based upon .625 us per pulsin unit.

If your RC receiver is normal, then its output will be pulses somewhere in the range of 600us to 2.4 ms with a time period of 20ms . That translates to a pulsin range of 60 to 240 with the Picaxe operating at 4mhz. It will probably be closer to 80 to 220 (servo full travel) .

With a PWM frequency of 61 hz ( we are operating at 4mz not 64) the time period is 1000 / 61 or 16.4ms (rounded) with a duty of 0 to 100 percent represented by PWM duty from 0 to 1023. Therefore each duty unit represents 16400us / 1023 or 16us (rounded). So to get a pulse width from 800us to 2400us the PWM duty will range from 50 to 150 where 50 * 16us = 800us and 150 * 16 us = 2.4 ms.

Now you simply have to do the math where a pulsin of 60 to 240 correlates to a PWM duty of 50 to 150. I showed how to do that on your previous thread so no need to repeat here. If I am correct in assuming what you are wanting to do then the code below should get you started.

#picaxe 08m2
 setfreq m4

symbol duty = w1 
symbol pulse = w0  

pwmout pwmdiv64, 2, 255, 0 
do   [INDENT]pulsin c.3,1,pulse   
duty = pulse  * 5 /9 + 17   
pwmduty 2, duty
[/INDENT]
loop

 

[Flash735]

Seems to me what you are trying to do is read the receiver output with pulsin and then then retransmit with PWM.

You already determined with the PWM Wizard that the slowest PWM is 61hz. But that is with the Picaxe set to operate at 4Mhz. So for clarity the program should have the line < setfreq M4 > somewhere at the beginning.

At 4 MHz each pulsin unit represents 10 microseconds not .625us. (.625 is for a Picaxe running at 64 mhz). The 8m2 will not run at 64 MHz yet you are making calculations based upon .625 us per pulsin unit.

If your RC receiver is normal, then its output will be pulses somewhere in the range of 600us to 2.4 ms with a time period of 20ms . That translates to a pulsin range of 60 to 240 with the Picaxe operating at 4mhz. It will probably be closer to 80 to 220 (servo full travel) .

With a PWM frequency of 61 hz ( we are operating at 4mz not 64) the time period is 1000 / 61 or 16.4ms (rounded) with a duty of 0 to 100 percent represented by PWM duty from 0 to 1023. Therefore each duty unit represents 16400us / 1023 or 16us (rounded). So to get a pulse width from 800us to 2400us the PWM duty will range from 50 to 150 where 50 * 16us = 800us and 150 * 16 us = 2.4 ms.

Now you simply have to do the math where a pulsin of 60 to 240 correlates to a PWM duty of 50 to 150. I showed how to do that on your previous thread so no need to repeat here. If I am correct in assuming what you are wanting to do then the code below should get you started.

#picaxe 08m2
 setfreq m4

symbol duty = w1 
symbol pulse = w0  

pwmout pwmdiv64, 2, 255, 0 
do   [INDENT]pulsin c.3,1,pulse   
duty = pulse  * 5 /9 + 17   
pwmduty 2, duty
[/INDENT]
loop

Hey all,
I think what twisted me around was the "pwmout pwmdiv64". When I read about that one from the Wizard, I incorrectly assumed all caluclations would have the relationship of .625 usec at 64mhz. Now I know that was incorrect. I believe I'm getting much better at the picaxe math and duty cycle operations. Thanks for all the help!