From: aleksa on
> You wanted >M< B not >K< B... Fortunately, NXP (et al.) does have
> inexpensive ($12-15) microcontrollers that do support external SDRAM.
> Their parametric search is the place to look (several options) but one
> example is the LPC2292.

Thank you, but for some unknown reason, I prefer Atmel.


From: David Brown on
aleksa wrote:
>> Floating point libraries for the 32-bitters have,
>> in my experience, become quite reliable; I think
>> that the gnu library should work just fine for you.
>
> Honestly, I don't know anything about gnu.
>
> I am now overloaded with information, so w/o searching
> for gnu libraries, I have two questions:
>
> How many bytes are used to represent a number?
> (8 bytes is what I use now)
>

In most cases, single-precision floating point is 4 bytes and double is
8 bytes - that's the IEEE standards. Some hardware (and some software
libraries) support extended floats at 12 bytes, or long doubles at 16
bytes, and some libraries for small devices only support singles.

> I suppose it is written in C, can it be linked with asm?
>

Floating point libraries are almost always provided as part of a
compiler toolchain - thus they come with your C compiler (or other
compiler). It is certainly possible to use software floating point
libraries with assembly, but I doubt if many people do so. Presumably
you are now going to program in C rather than assembly - your original
decision to program in x86 assembly and then move away from the x86
platform means that all your source code must be written anew. You
would not want to make that same mistake twice - program in C, and the
compiler will handle hardware floating point or software floating point
according to the capabilities of the device.

From: rickman on
On Jan 13, 9:17 am, "aleksa" <aleks...(a)gmail.com> wrote:
> > You wanted >M< B not >K< B... Fortunately, NXP (et al.) does have
> > inexpensive ($12-15) microcontrollers that do support external SDRAM.
> > Their parametric search is the place to look (several options) but one
> > example is the LPC2292.
>
> Thank you, but for some unknown reason, I prefer Atmel.

Dude,

If you are going to pick processors based on unknown reasons, why are
you asking for help from us? Everyone has their personal preferences,
usually based on what they are familiar with. But it sounds like you
are not familiar with any processors other than the x86 devices. Why
would you have a preference for Atmel??? Oh, I forgot, "unknown"
reasons...

It's a big CPU world out there. No reason to limit yourself to one
manufacturer.

Rick
From: rickman on
On Jan 13, 9:16 am, "aleksa" <aleks...(a)gmail.com> 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)

"Those who cannot remember the past are condemned to repeat it".
There is a reason that your conversion between the Z80 and the x86
processor assembly code was easy... they are both in the same
processor family. The Z80 was designed by a competitor to the 8080 to
be upward compatible and the x86 was the 16/32 bit upgrade from
Intel.


> AT91SAM9260 looks good, thanks.
>
> I've downloaded SAM-BA app from atmel,
> but found no schematics for programming cable.
> (haven't read the FAQs yet)
>
> '9260 must have at least two external components:
>   1. dataflash (holds the code for booting only)
>   2. sdram (holds code and data for normal operation)
> right?

Where do you plan to store your code to load into the ram? Most
systems use dataflash for storing boot code and parallel Flash for the
full application, although there is no reason why you can't use the
dataflash for the full application if it is not too large. 64 KB
shouldn't be a problem.

You haven't said anything about the requirements of your project. It
may well be that the 9260 is overkill or underpowered for your needs.
This part has a pin count of 208 (which also has a very large
footprint). You might find another part that will do the job in a
smaller package. The requirement for a large memory does tend to push
up the pin count, but I have seen parts with an external memory bus in
128 or 144 pins which is significantly smaller. Is size an issue?

Rick
From: Stef on
In comp.arch.embedded,
rickman <gnuarm(a)gmail.com> wrote:
> On Jan 13, 9:16�am, "aleksa" <aleks...(a)gmail.com> wrote:
>>
>> '9260 must have at least two external components:
>> � 1. dataflash (holds the code for booting only)
>> � 2. sdram (holds code and data for normal operation)
>> right?
>
> Where do you plan to store your code to load into the ram? Most
> systems use dataflash for storing boot code and parallel Flash for the
> full application, although there is no reason why you can't use the
> dataflash for the full application if it is not too large. 64 KB
> shouldn't be a problem.

Dataflashes are available in much larger sizes and since he wants SDRAM,
I suspect that will be at least several MB large. So booting from dataflash
and copying code to SDRAM should also not be a problem for >MB apps.
(you may have to write some second level loader code yourself, the standard
loader may only load a few KB to get you started).

We use an AT91RM9200 booting from 1MB dataflash with 16MB SDRAM for code and
data.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

If Robert Di Niro assassinates Walter Slezak, will Jodie Foster marry Bonzo??