From: Grant Edwards on
On 2010-01-13, aleksa <aleksazr(a)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
From: -jg on
On Jan 14, 11:53 am, "aleksa" <aleks...(a)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’s 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 ?
From: rickman on
On Jan 13, 5:30 pm, "aleksa" <aleks...(a)gmail.com> wrote:
> > It's a big CPU world out there.  No 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
From: David Brown on
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.

From: Stef on
In comp.arch.embedded,
aleksa <aleksazr(a)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.