EmbeddedRelated.com
Forums

Which CPU to choose?

Started by aleksa January 11, 2010
On 2010-01-13, aleksa <aleksazr@gmail.com> wrote:
>> Dataflashes are available in much larger sizes and since he wants SDRAM, >> I suspect that will be at least several MB large. > > Actually, my code is some 64k, but the dataflash is already on-board, > so making it a boot device for '9260 is a logical step.
FWIW, there are parts in the AT91SAM9 family with enough internal flash to eliminate the need for the dataflash.
> Run-time data can be some 16MB, that's why I need SDRAM.
-- Grant Edwards grante Yow! Hello, GORRY-O!! at I'm a GENIUS from HARVARD!! visi.com
On Jan 14, 11:53=A0am, "aleksa" <aleks...@gmail.com> wrote:
> > Where do you plan to store your code to load into the ram? > > In a 2MB dataflash (which already is on-board) > > > You haven't said anything about the requirements of your project. > > I really forgot that, and it's important. > > The original code runs well on PI @ 166MHz, so I need something close to =
that.
> Big part of x86 code uses FPU. > > Besides SDRAM pins, I need some 30 I/O pins. > (5V tolerance is always good, but not required)
SDRAM is the toughest nut here, so trying Cortex M3 SDRAM controller in google, finds a few ["TI=92s new LM3S1000 Series additions augment the series with a versatile External Peripheral Interface (with modes to support SDRAM, SRAM/Flash, Host-Bus, and M2M),"] so they could be worth a look ?
On Jan 13, 5:30=A0pm, "aleksa" <aleks...@gmail.com> wrote:
> > It's a big CPU world out there. =A0No reason to limit yourself to one > > manufacturer. > > You are absolutely right, thanks.
BTW, in another thread here someone mentioned a new part, not quite in full production that I think does what you need in a small package, LM3S9B96 from Luminary Micro, now TI. I am really impressed with all they have packed into this part and it sells for only $9 at qty 1k. Check it out! Rick
aleksa wrote:
>> ARM meets most of your requirements apart from FPU. I would look at AT91SAM9260. > > I knew I'll have to learn ARM someday! > > On the first look, ARM has some pretty strange instructions, > (what, no CALL, only one-deep BL?) don't know yet if conversion > from x86 to ARM is doable...? (did a Z80 > x86, it was simple) >
Welcome to the world of RISC processors. ARM is typical in that there is no real stack - that's up to the programmer to arrange. "call" is a branch-and-link, and "return" is a jump-to-link-register. If a called function needs to call something else, it needs to save the link register first. x86 to ARM assembly translation would not be simple. Any direct translation would waste much of the ARM's resources (since it has far more registers, and things like conditional instructions that don't exist in x86), and be tedious for x86 instructions and addressing modes that don't match up. It would be a waste of time and give you poor results unless you do so much manual tuning that you might as well re-write it.
In comp.arch.embedded,
aleksa <aleksazr@gmail.com> wrote:
>> Where do you plan to store your code to load into the ram? > > In a 2MB dataflash (which already is on-board) > > >> You haven't said anything about the requirements of your project. > > I really forgot that, and it's important. > > The original code runs well on PI @ 166MHz, so I need something close to that. > Big part of x86 code uses FPU.
If the FPU performance is that important, it might be tough to match the P1 performance with a cpu without harware FPU. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) A computer scientist is someone who fixes things that aren't broken.
OK, here is my new CPU wish-list:

1. nearest in instruction semantics and speed to PI @ 166MHz.
2. integrated SDRAM controller.
3. 30 I/O pins avaiable (besides SDRAM pins).
4. integrated FPU.
5. free develepment tools.
6. any package, any price.

Coldfire V4? (has FPU, but don't know about SDRAM)

What else?


> On the first look, ARM has some pretty strange instructions, > (what, no CALL, only one-deep BL?)
The BL instruction stores the return address in a register, instead of pushing it to the stack. This is a CISC vs RISC tradeoff. If you want several-deep calls, you must do the stack handling yourself. Usually this is done with push/pop (thumb) and stmfd/ldmfd (arm) in your function prologue/epilogue. Best regards
>aleksa wrote: >>> ARM meets most of your requirements apart from FPU. I would look at
AT91SAM9260.
>> >> I knew I'll have to learn ARM someday! >> >> On the first look, ARM has some pretty strange instructions, >> (what, no CALL, only one-deep BL?) don't know yet if conversion >> from x86 to ARM is doable...? (did a Z80 > x86, it was simple) >> > >Welcome to the world of RISC processors. ARM is typical in that there >is no real stack - that's up to the programmer to arrange. "call" is a >branch-and-link, and "return" is a jump-to-link-register. If a called >function needs to call something else, it needs to save the link >register first.
The ARM is starting to sound like a CDP1802 on steriods. --------------------------------------- This message was sent using the comp.arch.embedded web interface on http://www.EmbeddedRelated.com
aleksa wrote:
> OK, here is my new CPU wish-list: > > 1. nearest in instruction semantics and speed to PI @ 166MHz. > 2. integrated SDRAM controller. > 3. 30 I/O pins avaiable (besides SDRAM pins). > 4. integrated FPU. > 5. free develepment tools. > 6. any package, any price. > > Coldfire V4? (has FPU, but don't know about SDRAM) >
I believe they support both SDRAM and DDR ram. Another option would be MPC55xx devices from Freescale - some of these have full FPUs, others have single-precision FPUs if that is good enough.
> What else? > >
rickman <gnuarm@gmail.com> wrote:
> BTW, in another thread here someone mentioned a new part, not quite in > full production that I think does what you need in a small package, > LM3S9B96 from Luminary Micro, now TI. I am really impressed with all > they have packed into this part and it sells for only $9 at qty 1k. > Check it out!
Once upon a time, a Luminary rep told me that to keep the devices simple to use, each pin has at most one alternate function (which explains the huge number of devices they put out). I counted twelve different functions for one pin on the LM3S9B96! But you're right, that is an incredible amount of functionality they've crammed into that one chip. -a