How to avoid DIV32 command?

[pxidr84]

Hi everyone,

If you have followed my previous thread, you know that I've problems with the DIV32 command, because it apparently disturbs DT Instant Interrupts (if you're here Darrel, can you tell me if the DIV32 command has really an impact on your interrupts?).

So there is my problem, I've to make the following calculations without DIV32 :

var=1120000/freq
reload=(65535-var)+8

As you can see, "1120000" is too large for a 16-bit register. 24-bit will be good.
"freq" variable range is between 10 and 1200.

So how I can do this with a routine, or anything else?

Thank you.

[Archangel]

Hello pxidr84,
I have never used them before, you might try using " Long " variables available in PBP ver 2.6. As I understand it they are 32 bit variables. Anyone out there with experience please feel free to correct me if wrong.

[pxidr84]

Hello pxidr84,
I have never used them before, you might try using " Long " variables available in PBP ver 2.6. As I understand it they are 32 bit variables. Anyone out there with experience please feel free to correct me if wrong.

Hi,

I've PBP 2.60C, I didn't find any "long" variable. Where it is? :D

[cncmachineguy]

var=1120000/freq
reload=(65535-var)+8

"freq" variable range is between 10 and 1200.


Couple questions:
when freq = 10, var = 112000 so:
reload = -46457

This is ok?

Next question:
Assuming freq comes from A/D, seems like there should be a way to "scale" the A/D to get your reload value. What is the reload span? for instance,
freq = 10, reload = ??
freq = 1200, reload = ??

are the answers -46457 and 64609?

[Archangel]

Hi,

I've PBP 2.60C, I didn't find any "long" variable. Where it is? :D
Declare variables as so:
MyByteVar Var Byte
MyWordVar var WORD
MyLongVar var Long

Then in the view tab (of MCS) click compiler options and put a check in the checkbox marked use long.
I think using LONG variables and compiler uses a bunch more memory though.

[pxidr84]

Couple questions:
when freq = 10, var = 112000 so:
reload = -46457

This is ok?

Next question:
Assuming freq comes from A/D, seems like there should be a way to "scale" the A/D to get your reload value. What is the reload span? for instance,
freq = 10, reload = ??
freq = 1200, reload = ??

are the answers -46457 and 64609?

In reality, the reload var shouldn't go below 0. So, for me, -46457 equals 0.
But 64609 is correct.

My min. frequency is 1Hz (freq=10), reload value=about 0
and my max. frequency is 120Hz (freq=1200), reload value=about 64600

And I don't directly use the 0-1023 potentiometer value, first I convert it to the "freq" variable :


potsense=(potsense<<6)**maxfreq

"maxfreq" correspond to the maximum frequency defined by the user. Here, "maxfreq"=1200. So here "freq" variable varies between 0 and 1200. Note I'm using an additional number to have the 0.1Hz accuracy (for exemple, 50.2Hz frequency equals freq=502).

I will try longs. But I only need one long.

[pxidr84]

Declare variables as so:
MyByteVar Var Byte
MyWordVar var WORD
MyLongVar var Long

Then in the view tab (of MCS) click compiler options and put a check in the checkbox marked use long.
I think using LONG variables and compiler uses a bunch more memory though.

OUCH, I tested this, the program size passed from 8496 bytes to 10000 bytes. :eek:
But I will try if it works.

[Darrel Taylor]

..I've problems with the DIV32 command, because it apparently disturbs DT Instant Interrupts (if you're here Darrel, can you tell me if the DIV32 command has really an impact on your interrupts?).

DIV32 does not disturb DT_INTS, and DT_INTS does not disturb DIV32.

However, DIV32 takes a while to execute, and even longer when you do a multiply before hand to load the registers with a big value.
Trying to use them inside a high frequency interrupt is unlikely to work.

Division with LONGs or N-Bit math is no better. Divisions take a long time in software.

[mister_e]

I would go for a Huge lookup table or loaded EEPROM: those only take few uSec to be processed.

[pxidr84]

I would go for a Huge lookup table or loaded EEPROM: those only take few uSec to be processed.

I havent problems anymore, look at the end of "Unstable sine PWM output" thread.