PBP and PBPL

[keymuu]

PBPL has LONG (double-words) as a new data type. You don't need DIV32 when using PBPL. Just define your variables as LONGs and do the division.

Thanks Charles!

Yes I had one DIV32, commented it at got a bunch of errors (126) and warnings (220), 4 errors and 16 warnings . The errors:
Error[126] \PBP\PBPPI18L.LIB 722 : argument out of range (34218 not between 0 and 32767)
and the warnings (two kinds, for .LIB and .MAC):
Warning[220]\PBP\PBPPI18L.LIB 788: address exceeds maximum range for this processor.
Warning[220] c:\pbp\godiam.mac 1414: Address exceeds maximum range for this processor.

This processor is PIC18F4550.

So, what should I try next????

[mackrackit]

So, what should I try next????

Get rid of the DIV32 or do not use PBPL.

[keymuu]

Get rid of the DIV32 or do not use PBPL.

Ok, that would of course solve the situation

However, I have routines that need precise calculation where ... well 16 bit is not enough, I would need about 24 bits to calculate what I need to calculate.

So, if Microchip provides a LONG variable for v2.50 users it should also work... or?

What is wrong when getting those errors an warnings? Please help!

[Acetronics2]

So, if Microchip provides a LONG variable for v2.50 users it should also work... or?

What is wrong when getting those errors an warnings? Please help!

IF you use PBPL ...

May be you should declare your DIV relevant vars as LONG ... no ???

IF you use DIV32

May be you've noticed it's ( ONLY ? ) a 31 x 15 bits operation ... Manual $ 4.17.8

that need precise calculation

This sentence always make me laugh !!! may we know about those calculations ???


Alain

PS:

So, what should I try next????

To re-arrange your program not to exceed the 32k limit ... probably some redundant or overkilling calculations ...
BTW ... I remember Skimask ( Wish you a happy new year ,Ski ! ) wrote an interesting paper about that on this Forum ...

[keymuu]

IF you use PBPL ...

May be you should declare your DIV relevant vars as LONG ... no ???

IF you use DIV32

May be you've noticed it's ( ONLY ? ) a 31 x 15 bits operation ... Manual $ 4.17.8

Yes, I know that and have build hundred of lines to calculate what I need (but have not tested that yet),
in one place I need:
'------- ex. L = 349,989/2 = 349989/2 = 174,995 => 174995
'------- ' (L/2)^2 = (L/2) * (L/2) square it
That should give 30 623 250 (=01 d3 46 12h)
and this is not the only one.

So it would really be nicer to use the LONG variable instead of doing tricks and getting the program longer.
By tricking I mean something like this:
lsb = L0.0 : mL0 = L0 >> 1 ' remember lsb, then shift lower 8 bits right
mL0.7 = L1.0: mL1 = L1 >> 1 ' shift middle
mL1.7 = L2.0: mL2 = L2 >> 1 ' shift higher 8 bits right

Or saying it in other words if you can (on the upper level) do the same thing within 10 lines instead of 200 lines, why wouldn't you try to do so then?

This sentence always make me laugh !!!

So, you will live longer...

may we know about those calculations ???

I will send the formula later...

To re-arrange your program not to exceed the 32k limit ... probably some redundant or overkilling calculations ...

There still room for the program to grow. At the moment 28632 bytes used + 1k for the bootloader... so the limit is not close yet, but I think tricking would bring it fast closer

BTW ... I remember Skimask ( Wish you a happy new year ,Ski ! ) wrote an interesting paper about that on this Forum ...

What kind of story would that paper tell?

Still I think, if Microchip provides PBPL then it also should work... you could convert your existing program to using LONG if you have use to it. If you have then remove your DIV32 (possible R0 and R2) and use LONG variables instead. Isn't that neat?

Or do you not think so???

[mackrackit]

keymuu,

Have you seen this?
http://www.melabs.com/resources/articles/longs.pdf

For what it is worth, I have been going the 18F way just so I can use LONGS and not have to do the "tricks".

You still have to deal with the decimal point in the usual way, but we have to have a challenge some place

[keymuu]

keymuu,

Have you seen this?
http://www.melabs.com/resources/articles/longs.pdf

For what it is worth, I have been going the 18F way just so I can use LONGS and not have to do the "tricks".

You still have to deal with the decimal point in the usual way, but we have to have a challenge some place

Thanks Mackrackit.

We do not have floating point variables so we have to deal with the decimal point somehow else. When you have enough bits (32) it is so easy to ... we have ten fingers

I have not seen that earlier, I will print that article longs.pdf and read it tomorrow or so when I do not have my computer in front of me.

So, is it really true that nobody can tell what caused the errors and warnings in #3 ...

Please, if you can give some hints of what might cause those errors and warnings, please let me know