Floating Point Unit chip for my XMEGA

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I need a chip that can work as a Floating Point Unit. I need it for bitmap scaling and 3D graphics. Is there any?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes. ARM Cortex M4.

From many different manufacturers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

+1 for the M4

 

However there used to be an add-on FPU chip you could get to attach to 8bit integer only CPUs:

 

http://micromegacorp.com/umfpu-v...

 

You might want to explore that. However it should not come as a shock to you to discover that apparently what is under the label is a small ARM chip.

 

So you have a choice: either use an integer CPU and an add-on ($20 !!) FPU or just pick a CPU that has FPU inside.

 

What makes Cortex M4 different from Cortex M3 is that M4 = M3 + FPU

 

Having said all that, almost no 8bit embedded app ever really needs floating point anyway.

 

Of those that do the software simulation of FPU from the C library (libm.a perhaps?) is more than adequate.

 

So what is the application here that is so FPU intensive that it actually requires float in silicon? And if it is so FPU intensive why aren't you looking at DSPs?

Last Edited: Mon. Jun 22, 2015 - 09:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I saw that Gamebuino (using Atmega328) can go 3D rendering so I was thinking if maybe my XMEGA could too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

3D just needs sin() and cos(). You can do that on any AVR with software fp emulation libraries in the C compilers. HOWEVER performance is not that great - it might be better to use precalculated tables sin[] rather than sin() etc.

 

It will also depend on the pixel resolution and how quickly updates are required as to what might be achieved.

 

You probably aren't going to write "Flight Simulator".

 

Having said that the first IBM PC had 320x200 CGA resolution and a 4.77MHz only just 16 bit processor and Bruce Artwick wrote the original Flight Simulator for that. So perhaps... (it did not have hardware FP either).

 

Microsoft FS 2.13

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm thinking about something like Doom or Minecraft on XMEGA using external RAM for video buffer memory and a FPU for calculating 3D things. I think that in 3D rendering, there is surely multiplying with floating point numbers when scaling objects and that's why I (think I) need a FPU. If 3D does this really with only sine and cosine and AVR can do fractional multiplication, then I'll be happy without the FPU.

 

EDIT: My version of Doom and Minecraft, not the real games

Last Edited: Mon. Jun 22, 2015 - 05:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:
I'm thinking about something like Doom or Minecraft on XMEGA ... and a FPU for calculating 3D things.
IIRC the early versions of Doom used fixed-point arithmetic.

µC eXperiment

AVR GCC Fixed-Point vs. Floating Point Comparison

March 31, 2015

https://ucexperiment.wordpress.com/2015/03/31/avr-gcc-fixed-point-vs-floating-point-comparison/

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's nothing magical about floating point numbers that enables them to represent a greater number of values than integers.  They represent a greater range with lower accuracy, and make it easier to think about when you want something to be scaled by something like 0.78.  And, I'd hate to break it to you, but the AVR just does the regular old multiplication.  If you want it to work for what you have in mind, you'd have to scale everything to make whole numbers cover the range you want.  So instead of defining things in common terms where maybe 1 unit = 1 meter or something, make that same object 1024 units.  If you want it to be half the size, do a right shift and now it's 512 units.  If you want to translate it over an amount 1/10th of its size, that's no longer 0.1, it's 102.  If you need better granularity, make that 1024 an even larger number and go from there.  And forget anything approaching minecraft.  Doom is rudimentary 3D, and an alternative simplified implementation is doable.  Minecraft is very cpu/memory intensive fairly advanced 3D intentionally made to look rudimentary, and it's firmly out of the realm of an 8 bit mcu unless you're doing a 2D implementation more akin to dwarf fortress, and even then it takes a huge amount of memory as far as xmegas are concerned.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doom? That was developed in 1992/93. That was between 80486 and the first Pentium. They didn't write it for an 8086. I believe the minimum quoted spec at the time was 33MHZ 80386. You are kidding yourself if you think you are going to run something like Doom on a lowly 8bit micro. (well at a playable frame rate anyway).

 

I seem to remember that when Atmel launched the AVR32-AP7000 they had a demo running Doom on something like a 640x480 LCD. That was "pretty clever". But an AVR32 runs at >50MHz, is 32bit and has some FP/DSP support:

 

https://www.youtube.com/watch?v=...

 

(look how low the pixel resolution is in that though the frame rate isn't bad).