PBP and PBPL

[keymuu]

Hi again :D

Noticed that when you have PBP v.2.50 you also have PBPL !

So I tried it with/via Microcode Studio v.3.0.0.5 but run directly to an error:

ERROR: Macro DIV32?CW not found in macro file.

As I just struggled out from previous problem (with the kind help from Darrel) and this one sounds like a big fight ahead...:(
however, hope not!

Suspecting that some data is in a wrong place, but what is there? No idea...

So, the question is, what all should one do before adopting the PBPL?
Should you move some files from one location to another? Or something else?

The software that I try to compile with PBPL is in the same directory as PBP and PBPL, that is C:\PBP...

Thank you in advance

[Charles Linquis]

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.

[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):mad:
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? :confused:

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? :confused:

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 ... :confused:

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/showpost.php?p=38468&postcount=99

[keymuu]

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/showpost.php?p=38468&postcount=99

I'm using PIC 18F4550 :rolleyes:
You say that you may have found solution... Are you referring to the 18F4550.BAL? If so then the solution is not there, because I have that file in C:\PBP directory. If you are pointing to something else, please let me know what you are pointing at! Thank you anyway for trying to help me on this matter...

You can see the code that can be compiled without errors with PBP but not with PBPL...

...So, do you have any other suggestions, how to proceed from here...?

[Darrel Taylor]

You can't put these lines in your program.

BANKA $0000, $005F
BANK0 $0060, $00FF
BANK1 $0100, $01FF
BANK2 $0200, $02FF
BANK3 $0300, $03FF
BANK4 $0400, $04FF
BANK5 $0500, $05FF
BANK6 $0600, $06FF
BANK7 $0700, $07FF

They are in that .bal file Dave was talking about.

And you need the .bal in the USB18 folder, not the one in the PBP folder.
<br>

[keymuu]

You can't put these lines in your program.

BANKA $0000, $005F
BANK0 $0060, $00FF
BANK1 $0100, $01FF
BANK2 $0200, $02FF
BANK3 $0300, $03FF
BANK4 $0400, $04FF
BANK5 $0500, $05FF
BANK6 $0600, $06FF
BANK7 $0700, $07FF

They are in that .bal file Dave was talking about.

And you need the .bal in the USB18 folder, not the one in the PBP folder.
<br>

Thanks Darrel!

I'm confused, I have the same file in both places and when comparing them, they are equal. I do not know how there could be a difference between a file that is in two places, they should be equal, shouldn't they?
If they aren't equal, which one is more valid, or 100% valid? :confused:

Maybe I have overwritten one? Could this be possible?????

The problem here is not yet solved, but thank you all for your help so far. :)

I will take a brake and will be back again after 8 days, in the meanwhile I shall .... don't be envious ... perhaps I tell you afterwords what I did during those 8 days...;)

[Darrel Taylor]

It's very likely that you've overwritten one.
Here's what they should look like...
<table border=1><tr><td>PBP folder
'************************************************* ***************
'* 18F4550.BAL *
'* *
'* By : Leonard Zerman, Jeff Schmoyer *
'* Notice : Copyright (c) 2007 microEngineering Labs, Inc. *
'* All Rights Reserved *
'* Date : 06/29/07 *
'* Version : 2.50 *
'* Notes : Long *
'************************************************* ***************

BANKA $0000, $005F
BANK0 $0060, $00FF
BANK1 $0100, $01FF
BANK2 $0200, $02FF
BANK3 $0300, $03FF
BANK4 $0400, $04FF
BANK5 $0500, $05FF
BANK6 $0600, $06FF
BANK7 $0700, $07FF
'EEPROM $F00000, $F000FF
LIBRARY "PBPPI18L"
'LIBRARY "PBPUS18L"

include "PIC18EXT.BAS"

PORTL VAR PORTB
PORTH VAR PORTC
TRISL VAR TRISB
TRISH VAR TRISC

include "PBPPI18L.RAM"

'*-----------------------* EOF 18F4550.BAL *--------------------*
</td><td>USB18 folder
'************************************************* ***************
'* 18F4550.BAL *
'* *
'* By : Leonard Zerman, Jeff Schmoyer *
'* Notice : Copyright (c) 2007 microEngineering Labs, Inc. *
'* All Rights Reserved *
'* Date : 05/09/07 *
'* Version : 2.50 *
'* Notes : *
'************************************************* ***************

BANKA $0000, $005F
BANK0 $0060, $00FF
BANK1 $0100, $01FF
BANK2 $0200, $02FF
BANK3 $0300, $03FF
'BANK4 $0400, $04FF
'BANK5 $0500, $05FF
'BANK6 $0600, $06FF
'BANK7 $0700, $07FF
'EEPROM $F00000, $F000FF
'LIBRARY "PBPPI18L"
LIBRARY "PBPUS18L"

include "PIC18EXT.BAS"

PORTL VAR PORTB
PORTH VAR PORTC
TRISL VAR TRISB
TRISH VAR TRISC

include "PBPPI18L.RAM"

'*-----------------------* EOF 18F4550.BAL *--------------------*
</td></tr></table>

If they aren't equal, which one is more valid, or 100% valid?
They are both 100% valid.
One is used for USB, the other is used for NON USB programs.
<br>

[keymuu]

It's very likely that you've overwritten one.
Here's what they should look like...

They are both 100% valid.
One is used for USB, the other is used for NON USB programs.
<br>

Thank you Darrel, you have sharp eyes and clearly a brain behind those eyes!

I'm back from a nice one week refreshing holiday, with new energy...

After correcting my own mistake (overwriting 18F4550.bal) there was “real” progress :), reduced the amount of errors [126] and warnings [220] to only four, but brought back “an old problem”... :(
“ERROR: Macro USBINIT? Not found in macro file”
and those three other errors also (usbservice,usbin,usbout).

Searched around this thread “ERROR: Macro USBINIT? Not found in macro file” and read every mail that was somehow related to this situation and the only difference I could find was that PBPUSB18.MAC should be in C:\PBP\USB18 directory. I checked that and did not find PBPUSB18.MAC file in C:\PBP\USB18 directory. Why did my USB work earlier without that file in USB18 directory?

So to try something I dropped a copy of it there, as advised somewhere around here, but unfortunately it did not help this kind of an old problem... I had USB working earlier with PBP but what now when trying to get PBPL working?

Any suggestions how to proceed from here? :confused:

[Darrel Taylor]

.... don't be envious ... perhaps I tell you afterwords what I did during those 8 days... WELLL.... make me turn green :)<hr />

The compiler doesn't actually look in the USB18 folder.

Any files in that folder that are needed for your program should be COPIED into the same folder as your project.

And your project should not be in the PBP folder. It should be in it's own separate folder somewhere else.

The macro not found error usually means that it's not finding LIBRARY "PBPUS18L" in the .bal file. If you haven't COPIED the .bal file from the USB18 folder into your project folder, then it finds the one in the PBP folder, which has the wrong library line commented.
<br>

[keymuu]

WELLL.... make me turn green :)<hr /> Green is one of the major colors of nature...:D

The compiler doesn't actually look in the USB18 folder. Ok

Any files in that folder that are needed for your program should be COPIED into the same folder as your project. I have learned that somewhere earlier... but ...

And your project should not be in the PBP folder. It should be in it's own separate folder somewhere else. This is kind of new to me! I have known that that all (including your project) should be in the same in same folder, meaning all should be in C:\PBP. I was earlier wondering why MicroCode Studio has as default folder C:\Program Files\Mecanique\MCS ? Maybe this explains it then... and I should have copied things there instead of the contrary action... copying all to C:\PBP

The macro not found error usually means that it's not finding LIBRARY "PBPUS18L" in the .bal file. If you haven't COPIED the .bal file from the USB18 folder into your project folder, then it finds the one in the PBP folder, which has the wrong library line commented.
<br>In the C:\PBP\USB18 folder I can only find PBPUS18L.LIB no other files with the name "PBPUS18L", and it looks like this:

;************************************************* ***************
;* PBPUS18L.LIB *
;* *
;* Notice : Copyright (c) 2007 microEngineering Labs, Inc. *
;* All Rights Reserved *
;* Date : 05/09/07 *
;* Version : 2.50 *
;* Notes : PIC18 USB library w/ longs *
;************************************************* ***************

include "\PBP\PBPPI18L.LIB"
goto MAINPROG
include "USB18.INC"
include "USBDESC.ASM" ; Application specific descriptors
include "USB18MEM.ASM"
include "USB18.ASM"

MAINPROG Is that looking normal?

The same file is also in C:\PBP folder as well as
PBPUS18.MAC.
pbppic18.lib
pbppic18.mac
PBPPIC18.RAM
PBPUS18L.MAC
USB18.asm
USB18Mem.asm
usb18.inc
18F4550.bal
18F4550.BAS

The 18F4550.BAL looks like this:

'************************************************* ***************
'* 18F4550.BAL *
'* *
'* By : Leonard Zerman, Jeff Schmoyer *
'* Notice : Copyright (c) 2007 microEngineering Labs, Inc. *
'* All Rights Reserved *
'* Date : 05/09/07 *
'* Version : 2.50 *
'* Notes : *
'************************************************* ***************

BANKA $0000, $005F
BANK0 $0060, $00FF
BANK1 $0100, $01FF
BANK2 $0200, $02FF
BANK3 $0300, $03FF
'BANK4 $0400, $04FF
'BANK5 $0500, $05FF
'BANK6 $0600, $06FF
'BANK7 $0700, $07FF
'EEPROM $F00000, $F000FF
'LIBRARY "PBPPI18L"
LIBRARY "PBPUS18L"

include "PIC18EXT.BAS"

PORTL VAR PORTB
PORTH VAR PORTC
TRISL VAR TRISB
TRISH VAR TRISC

include "PBPPI18L.RAM"

'*-----------------------* EOF 18F4550.BAL *--------------------* Is that looking ok?

I created a new folder C:\PBP\Proj where I copied all those files also with my project, so now something still are missing from folder "Proj" when getting those same four USBmacro errors. I can't figure out what is still missing.
What can be missing?

Can you see what is missing?

[mackrackit]

I can not help much with the USB problem, but I would store my projects in a directory some place other than a sub directory of PBP. C:\projects woud be good. Most of my projects are on a flash drive or a SD card to make it easy to move from machine to machine.

When you have projects in the PBP ditectory and it comes time to upgrade them you will have to go find all of your "stuff" before it is deleted or over written during the new install.

[keymuu]

I can not help much with the USB problem, but I would store my projects in a directory some place other than a sub directory of PBP. C:\projects woud be good. Most of my projects are on a flash drive or a SD card to make it easy to move from machine to machine.

When you have projects in the PBP ditectory and it comes time to upgrade them you will have to go find all of your "stuff" before it is deleted or over written during the new install.

Thanks Dave! :)

Really interesting. What you said is of course true and logical.

I moved all from C:\PBP\Proj to C:\PBProj and compiled again I got rid of those four errors and instead I got "too many errors" meaning four Error[126] \PBP\PBPPI18.LIB 722 : argument out of range (34218 not between 0 and 32767) and that line in .LIB file is "CALL Label", and that drills me, does that mean Label is too far away or what? If this is true, how can one correct that? This brings me back almost to square one :(

[Darrel Taylor]

argument out of range (34218 not between 0 and 32767)

That means your program is larger than the 32k bytes (16k words) available on the 4550.
<br>

[keymuu]

That means your program is larger than the 32k bytes available on the 4550.
<br>

:confused: Could that mean anything else? :confused:

When compiling with PBP (not PBPL) it is 28632 bytes and of course there can not be any longs yet involved when still struggling to get it compile with PBPL. Or, would PBPL build bigger code than PBP when not using VAR LONGs ?

[Darrel Taylor]

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>

[keymuu]

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>

Thank you Darrel, thank you indeed :) You are real PIC wizard :p

So, I will see in future if it is worth to go back to PBP from PBPL...
The code compiled before with PBP=28632 bytes, then I moved away from the code that math that needs more precision and compiled it then with PBP=26026. This indicates that my 16 math eats 2606 bytes that later can be replaced with 32bit math and surely not taking so many lines (and bytes), I removed 280 lines. Now compiled with PBPL=28274, it will be interesting to see how close to limit (32k) the final compilation will be.

Thanks again, and thank you all others also, Dave, Alain, Charles ... :)

[keymuu]

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>Hopefully this is the last question on this subject:

When using PBPL you are not allowed in any part of your formula to have any intermediate results over 32bits! Is this a correct claim or not?:confused:

The question arise from the following formula:
R = ( (H^2) + ((L/2)^2) ) / H and for example
where
L = 315,103 -> 315103 (=LONG)
H = 37,234 -> 37234 (=WORD)

That should give R=703,9 (=WORD)

But instead of that you run to a strange error. When I remove that formula from the program it compiles correctly altogether to 28640 bytes. When I change the formula just to (L/2)*(L/2) gives also a similar error
Error[126].... (32770 not between 0 and 32767) indicating that the (L/2)*(L/2) would take 4130 byte (=32770-28640)
If I use the original formula (R=...) then the exceeding number groves from 32770 to 32886 an increase of 116 byte.

What is going on? Is it really true that you can not calculate in the middle of your formula any bigger value than 2 147 483 647!
(L/2)*(L/2) gives 2 482 247 515 and that is just little over ;) but it is over and one could suspect that to be the reason to this.

How to overcome such a situation? Please let me know:)

[mackrackit]

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

[keymuu]

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

Thanks Dave!

Nice try... however it doesn't work, you need all the bits to get the result R correct. Easy to test this with Excel :o

Actually (L/2)^2 could be calculated earlier in the PC and programmed as a constant to PIC. Then it would reduce the formula
to
R=(H*H + Lsqr2)/H
and
in this case the constant Lsqr2 = 24 822 475 152 and this is too big also for the LONG variable but now used only as a input to the formula. We could also see the formula like this:
R= (H*H)/H + Lsqr2/H = H + Lsqr2/H, this would reduce all calculation to just one little bit tricky (too many bits) part

=> Lsqr2/H

How could this be compiled easily? 35 bits with 16 bits, is it easily done or does it demand some special technique?

If you know, please advice ...

[keymuu]

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

Dave! After all there might be some idea ...:cool:

Let's say L=350123 and H=37234

And as you remember Lsqr2/H = L*L/2*2/H
that also could be written
L/4 * L/H

Then L/4=87530,75 ................. L/4 still over 16bits :(
L/H=9,403314175 ........
But if we divide L with 8 we get L/8=43765,375
and if we take the integer part 43765 (within 16bits!) and the decimal part 0,375. Let us call the integer part Lint and the decimal part Ldec, and we could first calculate Ldec= 8*0,375 = 3
Now we would have everything small enough... After the calculation we need to divide the result with 1000 and after that use only one decimal.

We are seeking for (L/2)*(L/2)/H/1000 ........if we write the formula

((8*Lint)+Ldec) * ((8*Lint)+Ldec)/ 4 / H / 1000 we will get the same result but

PBP does not compile it correctly and you get 0 as the result. If you remove the /1000 you still get 0. If you do not divide by H you get 1022, if you try ((8*Lint)+Ldec)/1000 you get 22. ?????????? it should give 350 !

You can see what I'm trying to do... How should one split things to go right in such a situation?
Could you please help me with this "small" problem :)

[mackrackit]

Looks like you are on the right track.

I think the problem now might be to many (()).. The compiler is confused. :)

((8*Lint)+Ldec) * ((8*Lint)+Ldec)/ 4 / H / 1000

L8 = 8 * Lint
LT = L8 + Ldec
R = LT * LT /4 / H / 1000

Maybe???

[keymuu]

((8*Lint)+Ldec) * ((8*Lint)+Ldec)/ 4 / H / 1000

L8 = 8 * Lint
LT = L8 + Ldec
R = LT * LT /4 / H / 1000

Maybe???Thanks Dave!

I did not mention in the previous mail that I don't trust in PBPL, as it seems to me that it can not correctly show how much space your code will take when you are as close to the limit as 3k or so. :mad:

So, your idea is excellent, no doubt :) When dealing with the reliably basic 16bits one should be able to shop the thing even smaller.... or perhaps, if one could fool PBP somehow and use DIV32 where the result is 32 bit. The manual 4.17.8 DIV32 (page 37) says:
"PBP and PBPW's multiply (*) function operates as 16-bit x 16-bit multiply yielding a 32 bit internal result. ....
....
In many cases it is desirable to be able to divide the entire 32-bit result of the multiply by a 16-bit number for ...
...
..... DIV32 relies that a multiply was just performed and that the internal compiler variables still contain the 32-bit result of the multiply...."
Those internal are referred as R0 and R2, right? R0=High and R2=Low, correct?

Then multiplication (manual 4.17.1) there are two operators '*/' and '**'
"The '*/' operator discards the least significant byte of the result (byte0) and returns the 4 higher bytes to the result variable...
... The '**' operator is similar, but ignores two bytes instead of one.... This gives a result that is shifted 16 places to the right..."
Are here any known internal variables (like R0,R2) involved?

Could one possible use the above, using R0,R2 and so, to achieve to do what I'm trying to do?

Please, if you know could you shear you knowledge of how to use internal variables for DIV32, how about those for multiplication?

I did a small check and it seems to me that PBP is using R0-R8 for something.
I kind of know that R0 and R2 is for DIV32, however never utilized them yet.
I suppose that those others are also some intermediate variables. If you know would you please be so kind and tell where they are used and if you want to you could also perhaps give some examples of the use..:)

[mackrackit]

I am afraid I do not understand now. I was thinking the only reason to chop the number up (factor it) was because at one point the value was larger than 32 bits, then once that was dealt with 16 bit had it covered.

Is the math working correctly now for your formula?

What am I missing here.

As far as the code size goes with PBPL, every value is a LONG, even 1. So that is where the extra code space comes from.



I did not mention in the previous mail that I don't trust in PBPL, as it seems to me that it can not correctly show how much space your code will take when you are as close to the limit as 3k or so.
The code space used as far as I know is calculated correctly in PBP or PBPL. What is making you think other wise?

[keymuu]

I am afraid I do not understand now. I was thinking the only reason to chop the number up (factor it) was because at one point the value was larger than 32 bits, then once that was dealt with 16 bit had it covered.

Is the math working correctly now for your formula?

What am I missing here.

As far as the code size goes with PBPL, every value is a LONG, even 1. So that is where the extra code space comes from.


The code space used as far as I know is calculated correctly in PBP or PBPL. What is making you think other wise?
Ok, I was ambiguous :o ... sorry

Please, take a look at #26, there I try to explain why PBPL can't be trusted.

However, the main point shortly:
As the code is now compiled without errors or warnings with PBP it is 26406 bytes + bootloader=1k.

If I compile it, the same code, with PBPL it is 28682 bytes (???), however with a bunch of warnings and one
"Error[126] \PBP\PBPPI18.LIB 690 : argument out of range (32940 not between 0 and 32767)"
and I learned earlier it indicates that the code exceeds 32k.

I do not know why or how it can tell: 28682 bytes used
and on the other hand that the code exceeds 32k :confused:

The PBPL didn't convince me at all, not at all.... How could I proceed from here when not yet implemented all the calculation I need?

There is not so much calculations but this situation can not promise a future for PBPL in this project!

So, this is the reason why I try to come along with the 16bit PBP and not trusting the PBPL.....:rolleyes:

I believe that it can be done somehow, by calculating small pieces at time, but I have not yet discovered how.... please help

[mackrackit]

Can you post the current cod if it has changed from the last time. Then maybe Darrel can find the problem.

[keymuu]

Can you post the current cod if it has changed from the last time. Then maybe Darrel can find the problem.

Please find the attached file testest.txt, it is not so much different from the previous one because I have not have time to develop it when chasing this ... problem... :rolleyes:

Hopefully it still reveals something :o

[mister_e]

Could you at least upload ALL your files here? all .BAS, .ASM, .BAL etc etc in a ZIP file, this way we will work with all the same stuff.

and this...

BANKA $0000, $005F
BANK0 $0060, $00FF
BANK1 $0100, $01FF
BANK2 $0200, $02FF
BANK3 $0300, $03FF
BANK4 $0400, $04FF
BANK5 $0500, $05FF
BANK6 $0600, $06FF
BANK7 $0700, $07FF

is useless.

AND if you're using a 4550, you're out of codespace... as stated before... time for some code optimization.

The obvious would be to move all text string into an external EEPROM or some part in the internal one.

I don't know how crazy the compiler go with it, but you define some variable here and there (at east in gettext sub)...

[keymuu]

Could you at least upload ALL your files here? all .BAS, .ASM, .BAL etc etc in a ZIP file, this way we will work with all the same stuff.

and this...

BANKA $0000, $005F
BANK0 $0060, $00FF
BANK1 $0100, $01FF
BANK2 $0200, $02FF
BANK3 $0300, $03FF
BANK4 $0400, $04FF
BANK5 $0500, $05FF
BANK6 $0600, $06FF
BANK7 $0700, $07FF

is useless.

AND if you're using a 4550, you're out of codespace... as stated before... time for some code optimization.

The obvious would be to move all text string into an external EEPROM or some part in the internal one.

I don't know how crazy the compiler go with it, but you define some variable here and there (at east in gettext sub)...

Attached PBProj.txt, change txt to jar and unzip it - et voilà ...

The BANKs was still hanging there for no reason, now they are not there any more.

I'm using 4550 and I think there is still much to go before the code ready and finished, so I'm sure that I will try to stay away from PBPL = trouble :rolleyes:

The plan is to eventually move all strings to an external EEPROM. If you are referring to the test loop, well it will not stay as well as not the 4 line LCD either.

It doesn't seem to change anything if moving them up from gettext. When building it is nice to have/see them in the first place where you use them. At last you then would collect all to one bunch. But as long there are not local variables then...:cool:
... and on this stage before the frame is totally working the code is more as a test underlying...

The question is still how to calculate R
R = (L/2)*(L/2)/H/1000
when for ex. L= 350123 and H=37234 (in reality L=350,123 and H=37,234)
How could one split (divide, using DIV32 R0,R2 etc) to get PBP calculate the correct answer?

Thanks :)

[keymuu]

The attachment was missing from previous .... it is her now , sorry:o

[mister_e]

never mind... still thinking too loud here :D

[Darrel Taylor]

The question is still how to calculate R
R = (L/2)*(L/2)/H/1000
when for ex. L= 350123 and H=37234 (in reality L=350,123 and H=37,234)
How could one split (divide, using DIV32 R0,R2 etc) to get PBP calculate the correct answer?

(L/2)*(L/2)
The result of that alone is over 30 Billion.
/H
DIV32 is actually a DIV31/15. The maximum divisor for DIV32 is 15-bits or 32767
37234 is too much.
/1000
There's at least 3 decimals of precision you won't need, so why are the numbers so big to begin with? (rhetorical question)<hr />

Let me open a whole new "Can of Worms", and suggest that you use the Microchip Floating Point Math module.
http://www.melabs.com/resources/fp.htm

It'll handle your numbers.
It takes a little getting used to, but it works.
<br>

[keymuu]

(L/2)*(L/2)
The result of that alone is over 30 Billion.
That is why I was asking if somebody would know some gimmicks and tricks to cut up that formula using "trick tools" available... calculating that in small steps or something like that.


/H
DIV32 is actually a DIV31/15. The maximum divisor for DIV32 is 15-bits or 32767
37234 is too much.
Yes true, but tricking around ... that was my hope but I do not how, so there I would have needed some help :o if that is usually possible at all to calculate small parts at time...


/1000
There's at least 3 decimals of precision you won't need, so why are the numbers so big to begin with? (rhetorical question)
Rhetorical or not, I know I'm stubborn :p ...

Really, test with Excel and skip the least significant digit (just one) compare with calculating with the calculation with all numbers and you will see that I'm not joking, at least with this matter :D....


Let me open a whole new "Can of Worms", and suggest that you use the Microchip Floating Point Math module.
http://www.melabs.com/resources/fp.htm

It'll handle your numbers.
It takes a little getting used to, but it works.
<br>
Thank you Darrel you really know things, not kidding.... :-)

Why couldn't this pop up earlier?(Rhetorical question) :-)
I downloaded those, took the example directly from that page and it compiled without errors. I will next play around with it and see if it is possible to solve "this" with it. If not then the "splitting" will be actual again....

[keymuu]

Let me open a whole new "Can of Worms", and suggest that you use the Microchip Floating Point Math module.
http://www.melabs.com/resources/fp.htm

It'll handle your numbers.
It takes a little getting used to, but it works.
<br>

The example alone takes almost 7k of code space, precisely 6898 byte used.
There is really no room for the real application for it. Copying that example to my code brings up familiar errors telling that we go over the limit with about 3k. Obviously the FP-library is too big.... and easy to estimate that I would need slightly more functions than the example has.

"What goes up comes also down, always..." :(

So, if it would be possible to split the formula to smaller calculate one part at time or utilizing R0,R2 or something....:rolleyes:

Isn't possible? :confused:

[Darrel Taylor]

Yup ... Worms ...

If you got rid of the USB bootloader you'd have another 4K to play with.
Talk about a Code HOG!


Really, test with Excel and skip the least significant digit (just one) compare with calculating with the calculation with all numbers and you will see that I'm not joking ...
I have tested it ... with "Open Orifice" not Excel.

And frankly, none of your formulas work out to what you say it should.

For instance in post#26
The question arise from the following formula:
R = ( (H^2) + ((L/2)^2) ) / H and for example
where
L = 315,103 -> 315103 (=LONG)
H = 37,234 -> 37234 (=WORD)

That should give R=703,9 (=WORD)When I plug that into the spreadsheet I get 860,313.14
EDIT: OK, I see that your sample numbers changed along the way.

By the way, why do some people use commas as decimal points?
And do you then call it a "decimal comma"?
Then what do you use for 1000's separator ... periods?

Then in post#28, you say that
... (L/2)^2 could be calculated earlier in the PC and programmed as a constant to PIC ...
... in this case the constant Lsqr2 = 24 822 475 152 But it's not, it's 30,646,528,782.<hr>

At any rate, let's assume that what you wanted was actually (L/2)*(L/2)/H/1000

IF L = 350123 and H = 37234 then the result is 823, and of course the numbers are too big for PBP.

But, as I was saying before, you have 3 decimals of precision that you don't need.
So if you reduce the 2 numbers 1 digit each so that L = 35012 ,H = 3723 and the divide is 100 instead of 1000, then the largest interim number is 306,460,036 and the final result is once again 823.
Well within PBP's limits with DIV32.

[keymuu]

Yup ... Worms ...

If you got rid of the USB bootloader you'd have another 4K to play with.
Talk about a Code HOG!

I have tested it ... with "Open Orifice" not Excel.

And frankly, none of your formulas work out to what you say it should.
I have heard that Open Office is compatible with Excel, but how far does this compatibility go? Surprising if it wouldn't use the same amount of precision or bits to calculate what Excel on the spreadsheet...:confused: Can't really comment...



For instance in post#26When I plug that into the spreadsheet I get 860,313.14
EDIT: OK, I see that your sample numbers changed along the way.
My mistake, that i did not keep the example numbers constant along the way. But the "locally" they should show the case....


By the way, why do some people use commas as decimal points?
And do you then call it a "decimal comma"?
Then what do you use for 1000's separator ... periods?

That is the way numbers are handled in Scandinavia. You are right, the 1000's separator is period and often space also. My mistake again, did not remember that the other parts of the world do no use that. When the world is as global as it is today, one do not (at least not I) even see that small difference (comma, period) in numbers, you just see the number the right amount and I can't remember right now if there ever had been a misunderstanding close to me concerning this matter... automatically handled by your brain. But frankly speaking you can here see more and more your way of using separators, so I guess that ultimately the comma as a decimal separator will disappear....


Then in post#28, you say that But it's not, it's 30,646,528,782.<hr>

At any rate, let's assume that what you wanted was actually (L/2)*(L/2)/H/1000

I wrote in that way so that there would be more elements to play with and hoped some mastermind could do something with that, for example something like this:
(L/20)*(L/20)/H but this does not of course help anything....


IF L = 350123 and H = 37234 then the result is 823, and of course the numbers are too big for PBP.

But, as I was saying before, you have 3 decimals of precision that you don't need.

So if you reduce the 2 numbers 1 digit each so that L = 35012 ,H = 3723 and the divide is 100 instead of 1000, then the largest interim number is 306,460,036 and the final result is once again 823.
Well within PBP's limits with DIV32.
As I told earlier, Darrel you are, I don't know how to say this so I just say GREAT! You have a fantastic intuition, wow... :p

Also Excel is a great tool (Open Office spreadsheet perhaps also), I could with the help of it realize a point that has been kind of hided all the way here.
You can of course not reduce H at all, but on the other hand you could divide the intermediate result (L/2)*(L/2)=30646528782 (L=315123 and real 315,123) as far as to a word !!!!!, I think. At least my preliminary experiments show so with "these" example numbers. Lets call (L/2)*(L/2)=30646528782 = Lsqr2
Having H=37234 (real 37,234)
Next we need to divide Lsqr2 with H, so
Lsqr2/H = 823079,1422 (correct answer, we need the four most significant digits, and those seems to be 8230). Now the question, with how many digits can you get this result (8230)?
Yes, that is right five digits = 30646 !

So, 30646/37234=0.8230... Never mind where the decimal separator is... the numbers are correct, yessssss !!!

If we would have one more digit in the dividend we would be on the sure side, with so few digits (5) there are still some unsureness around.
Lets call the short Lsqr2 (30646) to Ls

We have Ls=30646 and H=37234
So now PBP should accomplish the following formula:

R=(Ls/H)*10000

Should be perfectly within the limits but it gives R=0 :-(

Now, do you have any ideas how to proceed from here?

Thanks :)

[keymuu]

Yes I'm stupid, blind and.... who know what..:o

Of course you can not do the division like that, instead:
rr = 10000*L
R = div32 H

And this gives the correct answer :D

I will still do some testing and soon I will tell if this was the final solution.........

[keymuu]

"rr = 10000*L
R = div32 H
this gives the correct answer"
Yes indeed ... as long L=350123, really...

What a coincident :eek:

Have only tested different values for L,
when H=37234 and noticed that I was wrong, totally wrong(?). :o

When L=310123 or 360123 (both values slightly over the real and needed values) the result R is more or less wrong.

L=360123 gives 8704 when it should be 8707, not a big error but too big anyway.

L=310123 gives 6401 and it should be 6457 this error again is huge...

Maybe there is some work around this, but I don't know one, do you?

For ex. if we say we will stay within L=310000 to 360000 and H=20000 to 40000,

we could "graphically" see the lines through the L points and H points,
meaning the points from min to max, and from these calculate an offset to result.
Or something like this...

Perhaps there is some other solution(s), does anybody know this??
Please help :)