FWIW, there are parts in the AT91SAM9 family with enough internal flash to eliminate the need for the dataflash.
--
Grant Edwards grante Yow! Hello, GORRY-O!!
at I'm a GENIUS from HARVARD!!
visi.com
that.
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 ?
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
AT91SAM9260.
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.
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:
Coldfire V4? (has FPU, but don't know about SDRAM)
What else?
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
AT91SAM9260.
The ARM is starting to sound like a CDP1802 on steriods.
--------------------------------------- This message was sent using the comp.arch.embedded web interface on
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.
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
Coldfire fails your #1.
If you now have this:
then you should search for smallest x86 modules, and start with one of those with a somewhat available and with some design life left, processor.
One example google pops up:
-jg
418627.html
another example: a 'Surfboard' (PC keyboard)
$99 : Gecko Surfboard used processors Xcore86 (Vortex86MX) SOC clocked at 1.0GHz, 512 MB memory DDR2 RAM, 2.5-inch hard drive or SD memory card/SDHC being able to use the operating system Linux or Windows XP.
A very nifty looking idea... :)
-jg
s
Yes, it will be hard to use all of the functionality of this part in one design, both because of the limited I/O count and just because it will be hard to find an app that needs all this functionality. At $15 per, it is a little pricey as well. I'm also very interested in the EnergyMicro parts. Their performance is more limited at 32 MHz, but the power consumption looks pretty good. We'll see when they get complete specs out.
Rick
It's do-able, but it's not a rational approach. The ARM has 16 registers (including the PC), and 14 of them are general-purpose. There are no "preferred" registers like on x86. So much of the movement between registers and temporary storage is unnecessary.
It would make more sense to translate whole functions rather than individual instructions. It would make even more sense to translate them to C; there is seldom a significant benefit to using hand-crafted assembler on a 32-bit RISC architecture.
AT91SAM9260.
I made a port of an embedded system built with an Intel 80C188EB to Atmel AT91R40008 (ARM7TDMI).
There was about 50 kilobytes of code, initially written in Borland C version 4, and some pieces in Borland assembler. The final binary was generated using Paradigm Locate.
The new toolkit was (and still is) the GNU compiler suite, GCC and binutils. The original GCC version was 2.95, and the one currently in use is 4.3.2.
The porting took about a week, including compiling the GNU toolset and porting the assembler code in ssystem startup and multi-thread kernel. Most of the C code compiled and worked out-of-the-box.
-- Tauno Voipio
See
As "Nobody" suggested, I will translate my x86 code to C and compile it with GNU.
Of course, I will first have to learn C.
And before that, I'll have to check the speed of ARM @ 200MHz compared to PI @ 166MHz, especially the software FPU speed. Are there any tables like: FPU ADD/DIV/COS/etc per second?
I've started by downloading the winarm from
The GCC version in winarm is outdated, and these are listed as newer:
Thanks everyone for your replies!
Not across that combination.
Your best approach is probably to get you hands on a simple ARM toolchain, and use the silicon hardware to time things for you.
eg The LPCxpresso's start under $30, and will give real numbers.
-jg
aleksa skrev:
You can add the AT32UC3C0xxx later this year Some lucky guys are already working with the parts.
BR Ulf Samuelsson
Stef skrev:
With the AT91SAM9260, it is limited to 4 kB. I have my own version of AT91bootstrap at: ftp://
BR Ulf Samuelsson
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.