31 biits by 15 bits division could this be added to the Picaxe Manual please

hippy

hippy

Ex-Staff (retired)
We will undoubtedly consider it but it does raise the issue as to what should be included in the manual or not, and what external code is appropriate to be linked from the manual.

Without detracting from what has been achieved and its usefulness where appropriate, some would say 31 by 15 bit division is not that useful with the additional limitations the implementation has and full 32 by 16 or 32 bit divisions are more appropriate and the true complements to in-built 32-bit PICAXE maths, and that is what should be included.

If links to external code are appropriate in the manuals then where do we draw the line or choose which to use or are the most appropriate examples to link to ? Do we link to all example code or simply point out that the Code Snippets section, and the forum in general, offers means to achieve things not explicitly covered in the manuals ?

Rather than add external code links into the manuals it may be better to produce PICAXE maths tutorials which can describe a variety of code and explain the algorithms used and link to those, but of course someone has to understand and describe those and actually produce the tutorials.

As is often the case, what can seem like a simple matter is more complicated than it first appears to be.
 
P

Peter Goldsbury

Member
To me Techincal its all about adding some documentation to extend the utility of Picaxe so users can simply and immediately use. Kind of giving another psuedo command subroutine. The current divide operation is diabolically constraining, so application users like me need this functionality wiothout having to create it. You will see from the feedback already on the 31/15 bit divide post that people are already appreciating using it. Thanks to Alleycat and others, I certainly am as its got me out of a big hole.
 
S

srnet

Senior Member
The problem with putting such extensive bits of code in the manual is that there needs to be thorough 'idiot proof' review and then the code needs a reasonable amount of explanation as to its operation and application. There are no doubt many other routines in the maths area worthy of consideration too, for instance I have routines for a reasonably accurate calculation of COSX and ATANX (provided by ARMP).

I like the idea of a Maths Tutorial, covering such 'advanced' topics, not in a manual, but something that can be dynamically updated.
 
M

mrburnette

Senior Member
... well, here we are again and what is being discussed comes up far too often... PE does not provide the proper environment for user libraries. The fundamental problem is that such math routines and all cousin routines such as I2C and SPI and interface to specific RTC and other sensors need to be libraries.

Putting something like this in a manual (PDF) is inappropriate. Linking from it from a manual (PDF) is inappropriate; but the generic mention of useful routines in the Code Snippets forum is appropriate. Perhaps one of the RevEd staff or the moderators would adjust the search keys to include some single, unique term that would allow PICAXE users to quickly get the results of such useful routine... actually, it should be the users that "vote up" the rankings of any snippet routine to a level that would then trigger an automatic search term.... for example, the search term ADVMATH could be automatically added to the search key if PICAXE members vote the code snippet into that category... I think that if 5% of the active users vote a routine, it should be shown in an automatic search. To make this even more useful, the search index should have a "sunset" of some predefined time period since technology marches on... perhaps 18 months?

I surely would like to hear the cry, "THERE IS A LIB FOR THAT!" among PICAXE users. IMO, this is a critical issue that needs to be solved. Example code can only take you so far... incorporating the code, variables, and concepts is just too much for some users. And while I can do it, I find myself thinking (too often), "Why? Why should I? Arduino has a library... maybe..."

- Ray
 
S

srnet

Senior Member
mrburnette said:
I surely would like to hear the cry, "THERE IS A LIB FOR THAT!" among PICAXE users. IMO, this is a critical issue that needs to be solved. Example code can only take you so far... incorporating the code, variables, and concepts is just too much for some users
Click to expand...
Does it need to be solved, really ?

For libraries to work, dont you need to pass parameters in functions and have local variable and the like ?

Thats very unlikely to happen given the current constraints of how much firmware you can squeeze into a PIC to make it a PICAXE, and an issue which is probably only important to a small proportion of PICAXE users ............
 
M

mrburnette

Senior Member
@srnet,
Well... I think that a solution, or a darn good workaround is needed. But, I respect those members that feel differently. A programmer of your calibre obviously can take a complex example and incorporate that inline to your (existing) code. But complex examples IMO would have much more value to the less experienced if they could incorporate a function-like library.


- Ray
 
P

Peter Goldsbury

Member
mrburnette said:
@srnet,
Well... I think that a solution, or a darn good workaround is needed. But, I respect those members that feel differently. A programmer of your calibre obviously can take a complex example and incorporate that inline to your (existing) code. But complex examples IMO would have much more value to the less experienced if they could incorporate a function-like library.


- Ray
Click to expand...
@srnet,

I seem to have hit a nerve about putting links to external routines in the handbooks, so perhaps your suggestion of a maths function tutorial would be a workaround that opened up some opportunities for many programmers to do things to overcome picaxe limitations that they might otherwise think of as being impossible. Those other trig routines etc may also be useful.

I am not an experienced coder but I had no difficulty using allycat's well documented earlier 32/16 bit divide subroutine in my application as below with great results. I am sure the tutorial could enhance this further for general use. (note below that I have re-assigned absolute word and byte registers eg ww1-4 and wb1-4 for more system flexibility)

;*******************************

;DIVIDE - subroutine to divide a 32 bit number by a 16 bit divisor
;Acknowledgement Alan (Allycat) London on Picaxe forum,
;http://www.picaxeforum.co.uk/showthread.php?21357-Dividing-a-32-bit-number-by-a-16-bit-one/page2
;subroutine takes 52 bytes it typically executes about 180 lines taking around 150ms (at 4 MHz)
; (Testing with code below takes approx 10 msecs on a 18m2 running at 32 mHz)

; Divide ww1.ww2 by ww3 using "Long Division", result will be in ww4
; be careful as this also uses wb2,wb3


symbol numlo = ww1
symbol numhi = ww2
symbol numtop = ww2h ; highest byte of numerator ( = ww2h)
symbol denom = ww3
symbol result = ww4
symbol pass = wb2
symbol carry = wb3 ; Could use bit flag instead (used as zero / non-zero)


divide: ; 52 bytes in subroutine

result = 0 ; Clear result register
carry = 0 ; Clear carry "flag"
for pass = 0 to 16 ; Repeat for each bit position
result = result + result ; Shift left (do BEFORE the final bit is added)
if numhi < denom AND carry = 0 then shift ; Jump if can't subtract
result = result + 1 ; Store the databit
numhi = numhi - denom ; Subtract the denominator
shift:
carry = numtop AND $80 ; Carry flag from numerator top bit
numhi = numhi + numhi ; Shift numerator high left
if numlo > $7FFF then ; Carry bit from low word
numhi = numhi + 1 ; Add carry to high word
endif
numlo = numlo + numlo ; Shift numerator low left
next pass
return
 
You must log in or register to reply here.
Top