Hi,

if you choose an Infineon TC1165 TRICORE or similar, almost all your
requirements are fulfilled. It is just, that the speed is limited to 80
Mhz
I don't know about the TWI.

I haven't used it yet, yet I'm planning on using it for doing some
navigational calculations as well (some extended Kalman filter)and need
almost the same specifications. And the tricore fits my bill as well,
except maybe for the speed.

What is nice... It has 2 spi's, and for each ( at least if I remember
correctly) has 6 chip select signals integrated.

GNU Linux should work on it as well.

Greetings B

Mike Noone wrote:
> Hi - I was wondering, what microcontrollers are there out there that have 
> FPUs? I'm working with a board that uses an Atmel AT91SAM7X256 (Atmel ARM 
> uC with ARM7TDMI core), and it is perfect except for the lack of a FPU and 
> maybe the max speed of 55Mhz.
> 
> So what is available as a replacement? Ideally I'd like to see this:
> 
> 32b FPU
> SPI (at least one)
> UART (at least two)
> TWI
> CAN
> timers
> plenty of GPIOs
> available in non-BGA package
> fast (100+Mhz)
> 
> Does such a beast exist? Thanks!
> 
> -Mike

Specifying an FPU is a silly requirement.  All an FPU does is accelerate 
(some) floating point operations, as compared to doing it in software 
(using the standard C libraries).  If you have a particular requirement 
regarding the speed you need (e.g., 100 MACs per millisecond), then say 
so - it is irrelevant whether this is done by FPU hardware or by fast 
integer units and software, since it uses the same source code and gives 
the same result in the same time.

On 17 Apr 2006 14:25:11 -0700, "Isaac Bosompem" <x86asm@gmail.com>
wrote:

>To evaluate trig functions in fixed point you would probably need use
>Taylor series which could become time consuming.

In practice trigonometric functions are calculated by dividing the
argument into segments and selecting a polynomial for the current
segment. To calculate the sin() function to single precision a 3rd or
4th order polynomial is usually needed, for double precision a 6th to
8th degree polynomial is usually used, depending on the size of
segment/sector. When using fixed point in the polynomial, you have to
watch out for under/overflows.

Especially if there is room for a lot of constant tables, most
calculations can be done with quite low order polynomials. In some
cases it might help if the processor contains 32x32=64 and 64:32=32
bit integer multiply and division instructions.

Paul

On Mon, 17 Apr 2006 21:17:44 GMT, Mike Noone
<mnoone.uiuc.edu@127.0.0.1> wrote:


>I could deal with fixed point. All of the floating point stuff I'm doing is 
>for navigation. So it has alot to do with calculating GPS coordinates, 
>distances between coordinates, headings, and lots of trig. But C doesn't 
>have built in support for fixed point. Is there some way to get around this 
>limitation of C that I am not familiar with?

How often do you really need to perform these navigational
calculations ? Once every second or once every millisecond ?

If once a second is enough, the C floating point emulation should be
fast enough on practically any processor.

For very high dynamic vehicles you would need acceleration sensors
anyway, so why not just calculate the GPS position, say, once a second
and convert it to the final coordinate system and then use the data
from the accelerator sensors to extrapolate the speed and position in
the final coordinate system until the next GPS position is calculated.

Paul
 

In article <1145309111.678691.9080@e56g2000cwe.googlegroups.com>, 
x86asm@gmail.com says...
> 
> Mike Noone wrote:
> > "Isaac Bosompem" <x86asm@gmail.com> wrote in
> > news:1145305529.211300.57090@e56g2000cwe.googlegroups.com:
> >
> > > Is there a reason why you choose not to use fixed point?
> > >
> > > -Isaac
> >
> > I could deal with fixed point. All of the floating point stuff I'm doing is
> > for navigation. So it has alot to do with calculating GPS coordinates,
> > distances between coordinates, headings, and lots of trig. But C doesn't
> > have built in support for fixed point. Is there some way to get around this
> > limitation of C that I am not familiar with?
> >
> > -Mike
> 
> Nah, I don't think so unless there is a 3rd party library I am unaware
> of.
> To evaluate trig functions in fixed point you would probably need use
> Taylor series which could become time consuming. I would assume for GPS
> these calculations need to be fast?
> Then forget I asked about fixed point :). 

A lot of the GPS modules out there (Ublox, etc.)  use an ARM processor
without FPU to do the gps calculation.   At 1 to 4 GPS packets per 
second,  you would have to be doing a LOT of calculations to run
out of bandwidth for software floating point emulation.   Until one
project started involving extended Kalman filters with a few hundred
to a few thousand multiplies per cycle,  I was getting along fine
with a  16MHz  68332.

Mark Borgerson

you might try looking at the low end floating point DSP's, Analog
Devices SHARC is a nice $5 CPU with floating point,  in a non BGA
package, SPI but no CAN, TI has something similar,

Andrew M <noone@home> wrote in news:44443a53$0$16643$5a62ac22@per-qv1-
newsreader-01.iinet.net.au:
> 
> The Philips LPC3000 ARM9 has an FPU. Very nice part. 
> -Andrew M
> 

Undeniably. It's unfortunate that it isn't available yet, and will only 
come in a BGA package. Also would have liked to see some flash onboard.

-Mike

Mike Noone <mnoone.uiuc.edu@127.0.0.1> wrote in
news:Xns97A8A5B46A7B0mnooneuiucedu127001@204.127.204.17: 

> "Isaac Bosompem" <x86asm@gmail.com> wrote in
> news:1145305529.211300.57090@e56g2000cwe.googlegroups.com: 
> 
>> Is there a reason why you choose not to use fixed point?
>> 
>> -Isaac
> 
> I could deal with fixed point. All of the floating point stuff I'm
> doing is for navigation. So it has alot to do with calculating GPS
> coordinates, distances between coordinates, headings, and lots of
> trig. But C doesn't have built in support for fixed point. Is there
> some way to get around this limitation of C that I am not familiar
> with? 
> 
> -Mike
> 

The Philips LPC3000 ARM9 has an FPU. Very nice part. 
-Andrew M

"steve" <bungalow_steve@yahoo.com> wrote in news:1145308633.363403.295230
@e56g2000cwe.googlegroups.com:

> not exactly, but take a look at
> 
> MPC5554, MPC555, LPC3180, V850E/CG2TM
> 
> I believe a typical FPU is the size of the core (for ARM anyway) so the
> increase in size is too much of a negative to just include them in your
> typical jelly bean micro
> 

All BGA though.

Surely there are some special purpose uCs with FPUs?

-Mike

"Mike Noone" <mnoone.uiuc.edu@127.0.0.1> wrote in message
news:Xns97A8A5B46A7B0mnooneuiucedu127001@204.127.204.17...
> "Isaac Bosompem" <x86asm@gmail.com> wrote in
> news:1145305529.211300.57090@e56g2000cwe.googlegroups.com:
>
> > Is there a reason why you choose not to use fixed point?
> >
> > -Isaac
>
> I could deal with fixed point. All of the floating point stuff I'm doing
is
> for navigation. So it has alot to do with calculating GPS coordinates,
> distances between coordinates, headings, and lots of trig. But C doesn't
> have built in support for fixed point. Is there some way to get around
this
> limitation of C that I am not familiar with?
>
> -Mike

Just write your own integer versions of the math routines you need. It
sounds hard, but it really isn't. OTOH, if squeezing the last few dollars
out of a product cost is not the point of the project (I see you have an edu
email address) and software emulation is too slow, then go ahead and buy a
bigger hammer ;-)

Bob