..the speed advantage of that "FPU" chip is maybe ~3x against arduino @16MHz, if you add the transfer overhead, the advantage slowly disappears.. Maybe a "parallel" mode (with an interrupt fired when FPU ready) where you load the fpu with data, run the calc there, and in parallel you do something else in the avr.. That way you may try a massive parallel number cruncher with ie 256 FPU chips connected to an arduino, provided you can write the code properly for such a mainframe :)..
Hmm, but you guys are still talking about small instruction sets though. If you can execute saved code blocks, then you can potentially do things like cryptography on the FPU while sending nothing but input, output, and commands to the FPU, right?. That's potentially worth something.
Either way, I really appreciate your taking the time to buy one of these and run it through paces for us.
Constantin:
Seems to me that using SPI to lash two Arduinos together would allow you to achieve almost identical results with the added advantage of a easy-to-use compiler and IDE.
I'm inclined to agree. After all, it's still just 32-bit processing. And with a second chip you could customize what you want it to do (in C ... not some obscure language) and have full control over how it does it.
SirNickity:
Hmm, but you guys are still talking about small instruction sets though. If you can execute saved code blocks, then you can potentially do things like cryptography on the FPU while sending nothing but input, output, and commands to the FPU, right?. That's potentially worth something.Either way, I really appreciate your taking the time to buy one of these and run it through paces for us.
I too appreciate your efforts and reports. I think that there is still some value in this product to be had for certain applications. Perhaps if it was called a co-processor instead of a floating point processor, expectations would be not so high. The fact that it has other features, GPS parsing, extra I/O, etc, as they do seem to have packed a lot of things into the package and might still make it useful for some.
Lefty
I got the uM-FPU FFT instruction to work so that I could compare it against the PlainFFT package. It is obvious that what will slow things down is getting the data in and out of the uM-FPU so I messed around with various methods until I came across the WRBLK and RDBLK instructions. With some code and help from Cam Thompson of MicroMega I was able to transfer the data into and out of the chip in blocks of 64 floating point numbers at a time with the FPU library modified to use the SPI divider DIV2 instead of the default DIV4.
The PlainFFT package does a 64-point FFT in 19.3 milliseconds and my code for the uM-FPU does it in 16.25ms. The breakdown of the time is:
write data(us) = 2112
FFT(us) = 10368
read results(us) = 1888
Total(ms) = 16.25
As has been mentioned, this probably isn't that much faster than PlainFFT that you'd want to use the uM-FFT unless you were doing an awful lot of them and/or you were doing something else in parallel on the Arduino.
Perhaps if it was called a co-processor instead
MicroMega's datasheet calls it a "32-bit Floating Point Coprocessor".
If you can execute saved code blocks
Yep, you can. You can load multiple functions into the chip and then call them as and when needed. Their GCDistance demo does that.
Pete
Hope I've got my orders of magnitude right this time 
I'm sure there is a killer app for this chip... but I still don't see the flashing reason why one would use this unit....
Seems like one could achieve the same performance on an Atmega, simply by boosting the clockspeed to (a perfectly legal and supported) 20MHz. At the price those guys are charging, one could have a three-core Arduino at work (crystal and all). The 12-bit ADC is nice, but they can also be had externally for less. So I don't get it yet, but that's OK.
That FPU chip is a nice gadget, and quite useful, when used as a small external calculator for running some "demanding and precise" algorithms (ie PIDs, navigation calcs, astronomy calcs, sensors fusing/Kalman filters, pattern recognition, etc..) in parallel with arduino's main task (ie sense and actuate). However, for most calcs today a better than 32bit floating point precision is needed (ie 32bit fp is "less precise" than a 32bit integer). So in case it would support 64bit fp (only 2x slower) and I would have a possibility to load a "math subroutine" into it (ie. an RPN or Forth like stack machine or like an external HP15C ), even with that speed, I would be very happy.. Provided such an external calculation may take hundreds of msecs or ~seconds, you can significantly speedup the main task and the responsiveness of the system as well. And you can connect several FPU chips if required (scalability)..
Scalability, et al are nice but consider the minimal up charge to go to a maple or digilent solution... You get oodles of speed, a 32 bit chip, and a arduino form factor.
As limited as the software IDE / libraries may be on these platforms, they're still better than trying my hand at assembly code (at least for non-luminaries like myself). The last time I programmed assembly code was on a microcomputer almost 30 years ago and I'm glad technology has moved on.
Rob, I must admit they are very fast on responding the potential customer requirements !! 
They took pic24hj (or dspic33fj ??) in dip28!! (so my next advice to them would be to take pic32mx2xx in dip28 ~basically pin compatible and 32bitter). So when thinking about an FPU chip then this uM-FPU64 is THE option, indeed. The only aspect you have to consider is these chips take a lot of current when running math @ 40mips (~60-70mA) (maybe the newest revisions are better). Be aware - 3.3V only. The dspic33fj can do DSP so ie. FFT is done VERY fast (when in Q15 format). It can do 12bit ADC as well. For $25 it is a VERY nice gadget to play with..
PS: the speed of a 64bit float calc will be ~0.7x of the older uM-FPU's 32bit float calc, I guess..