Suggestion: Floating Point support

kranenborg

Senior Member
Hi all,

I am new to the PICaxe concept, new to this forum, and do not have any PICAxe hardware up to now, but I definitely want to use a PICaxe in the near future. I have done quite some hobbying on analog electronics using the Philips EE kits (see my website at http://www.kranenborg.org/ee), but now I want to combine these designs with the PICaxes.

Here is my point: wouldnt it be very nice if support for floating point arithmetic be added?

Having roamed the internet I found three approaches:
1) Implement the Floating point subroutines (32 bit versions only) that are provided by Microchip and integrate this into the PICaxe's code.
2) Use the PAK-XII or PAK-XI from AWE (http://www.al-williams.com/pak12.htm)using RS232 protocol (ie. serin-serout communication) or direct using shiftin-shiftout
3) Use the uM-FPU from Micromega Corp. (http://www.micromegacorp.com/fpu/uM-FPU.html)

personally I would favour option nr. 3: It is a brand-new, small 8-pin, relatively cheap co-processor that support the SPI-protocol. I understand that this is almost identical to the ic2 bus protocol, and the device should function properly in the ic2-bus of a PICAXE-18X/28X/40X.Also only a very small library would be useful to support high-level commands (see for example the BASIC-STAMP-2 documents and software links on the site)

Second best option: can't choose between 1 and 2 ...

Maybe there are already plans for Floating Point math support?

Regards,
Jurjen

 
 

Technical

Technical Support
Staff member
The supplier of the uM-FPU is currently developing PICAXE routines, so we would recommend this route.
 

kranenborg

Senior Member
I got into contact with the mu_FPU developer, and he replied that
" ... I don't think the I2C interface is going to be quite as
straightforward as it might be in other circumstances due to a couple of
ready/wait optimizations that are used on the uM-FPU. I'll look into the
issue in more detail once I get a PICAXE to test. ..."
Still I hope the i2c solution is possible, it saves some pins, and possibly some code lines and execution cycles



 
 
Top