Can you post the current cod if it has changed from the last time. Then maybe Darrel can find the problem.
Can you post the current cod if it has changed from the last time. Then maybe Darrel can find the problem.
Dave
Always wear safety glasses while programming.
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...
is useless.Code: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
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)...
Last edited by mister_e; - 28th January 2009 at 22:28.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
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
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...
... 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![]()
(L/2)*(L/2)The result of that alone is over 30 Billion./HDIV32 is actually a DIV31/15. The maximum divisor for DIV32 is 15-bits or 32767/1000
37234 is too much.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>
DT
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.
Yes true, but tricking around ... that was my hope but I do not how, so there I would have needed some help/HDIV32 is actually a DIV31/15. The maximum divisor for DIV32 is 15-bits or 32767
37234 is too much.if that is usually possible at all to calculate small parts at time...
Rhetorical or not, I know I'm stubborn/1000There's at least 3 decimals of precision you won't need, so why are the numbers so big to begin with? (rhetorical question)...
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....
Thank you Darrel you really know things, not kidding.... :-)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>
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....
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....
Isn't possible?![]()
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.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 ...
And frankly, none of your formulas work out to what you say it should.
For instance in post#26When I plug that into the spreadsheet I get 860,313.14The 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)
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 thatBut it's not, it's 30,646,528,782.<hr>... (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
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.
Last edited by Darrel Taylor; - 30th January 2009 at 02:36. Reason: Constants changed
DT
The attachment was missing from previous .... it is her now , sorry![]()
never mind... still thinking too loud here![]()
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Bookmarks