PBP and PBPL

[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

[mackrackit]

Can we see the code that gave the errors?

[keymuu]

Can we see the code that gave the errors?

The code is not ready, not tested, except for i/o-extender, eeprom and rtc, the "big picture" is just written but not tested except for compilation:

The attached code compiles without errors with PBP,
but not with PBPL (gives those errors in #3)...

Really hoping it reveals something

[mackrackit]

To be honest I have not played with USB yet, so I may be full of it as usual... but I may have found a solution.
Read Steve's note on this post.
http://www.picbasic.co.uk/forum/show...8&postcount=99