They have a couple FP chips IIRC, all with SPI interfaces. I think they're pretty expensive though so you might have better luck with something like a cheap DSP like a DSPic from Microchip.
I don't think anyone makes FPUs any more. If you can't do the FP fast enough on the Rabbit, using an ARM is probably the way to go. The Philips LPC2000 chips are very cheap - you could either use one as an FPU or redesign the whole system. Of course, that depends on whether the software FP on the ARM is fast enough for you, otherwise you'll have to use a device with hardware FP.
Leon
--
Leon Heller, G1HSM
http://www.geocities.com/leon_heller
Leon
I need to find a low cost FPU to interface to a Rabbit 2000 processor. Having done no embedded hardware design in the last 3-4 years I have found myself already drifing away from current trends.
As for the exact precision, no sure at this stage. Still investigating and open on this one. I prefer to avoid DSP's if at all possible and need something that will interface to an 8 bit wide General IO port on the rabbit, so bitbashing serial would also be fine.
All i can find on google is ARM's and DSP's, which are a bit of an overkill. If it comes to this a complete redisgn will be done, which I would dearly love to avoid.
OK, I don't even know what the above means. But if the number of math operations (multiplies, divides) is only a few dozen and the system is "interactive" (user pressing buttons, gets a display within a fraction of a second) then there's no problem doing software floating-point on the Rabbit.
IIRC, the Rabbit is not particularly fast. If the speed is marginal, then a cheap 32-bit processor such as the ARM would surely be fast enough. You can likely just use a C compiler that supports the precision you need.
Do you have a numerical estimate of the number of floating point operations required per second (and the mix, as multiply generally is faster than divide, sometimes a lot faster). For control applications I try to massage the algorithm into a form that minimizes the number of divides in favor of multiplies. But maybe, as Tim says, it doesn't matter much in your case.
Best regards, Spehro Pefhany
--
"it\'s the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
In doing so they probably used factorials... is that why you say you need double precision, you want to reproduce these combinatorics?
If so it's vastly more efficient to write "m choose n" (which is usually a smallish manageable number) than to do the ratio of factorials (each of which may well overflow a IEEE double!)
Well, I feel like I need to insert a comment here. "Double Precision" doesn't necessarily require "Floating Point." Depending on the range in question, it might be possible to scale everything and do integer arithmetic. I've seen some pretty sophisticated digital filters done in integers.
Of course, I'd feel a lot more comfortable giving "advice" if I had some clue just what "jackpot win points" are. And I've been terrified of "statistics" for a very long time. :-)
It is very common in DSP like situations to find 1/X and multiply because it can be coded to be much faster than a divide.
For numbers very near 1, (2-X) = 1/X
1/X = A*B*C*D*(1/(A*B*C*D*X))
If A, B, C, and D are numbers in the form of 1.??, 1.0??, 1.00?? the multiplies needed to bring the denomination near enough to 1.0 can be done as byte or word operations instead of having to work with the full number of bits in the mantissa.
On an 8051, a 64 bit 1/X calculation can be done in a 1mS or so, so I doubt that an external FPU is really needed for a slot machine.
We are doing some fairly computational heavy statistical calculations for creating jackpot win points. The math (apparently) requires double precision, or so the author of the algorithm tells me. I am taking this on face value, as I am yet to have a real good look at it.
In the mean time, we are waiting for regulatory approval to do the win point calculation on a PC and pass it down to the rabbit. The plan is to calculate many win points and have the rabbit do a random selection on one of them. If we can get away with this, then the we can avoid the whole math-coprocessor thing.
Maybe the library you're using to get a random number distributed according to a geometric distribution needs double precision floating point, but there are several trivial ways of doing it with only integers, all very efficiently.
Isn't the rabbits instruction set basically the same as the Z80's?
If so, I know there must be a package out there. The Synclair ZX81 computer's basic used a floating point library. Somewhere around here, I have a disassembled listing of the 8K basic. I remember that there was a hunk of it that was obviously in a different style and was linked in as one solid block. It was obvious that it was a FP library.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.