On Jan 15, 12:28=A0am, "aleksa" <aleks...@gmail.com> 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)
>
> What else?
Reply by Ulf Samuelsson●January 19, 20102010-01-19
Stef skrev:
> In comp.arch.embedded,
> Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2010-01-13, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>
>>> 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).
>> The bootloader built in to the AT91SAM9 parts will only load
>> into internal SRAM (typically 8 or 16KB). That means you need
>> a small second-stage bootloader than enables/configures SDRAM
>> and copys either your application or a larger bootloader (e.g.
>> U-Boot) into SDRAM and executes. Atmel provieds a sample
>> bootloader than is set up to load U-Boot from dataflash,
>> nand-flash, nor-flash, SD-Card, etc.
>
> Ah yes, now I remember (amazing how soon you forget that stuff if
> you're not working on it anymore). The one we use has 16KB of
> internal SRAM. But make sure you limit the first load to somewhere
> around 12K. The ROM bootloader uses the upper part of the SRAM for
> it's variables and other stuff. If you get in that area the result
> gets 'unpredictable'. (mostly just hangs up).
>
>
Reply by Ulf Samuelsson●January 19, 20102010-01-19
aleksa skrev:
> I've looked at farnell, there are some 450 MPUs and thousands of MCUs,
> which one should I learn, considering:
>
> I'm currently using a standard x86-32 PC for my project,
> but would like to replace the whole motherboard with
> just two chips: cpu and memory.
>
> The code for x86 is written (by me) in ASM, about 64k in size.
>
> This is what I need:
>
> 1. 32-bit CPU
>
> 2. 128k of internal CODE memory, ISP and IAP.
> (in-system, in-application programmable)
>
> 3. min 32MB of DATA memory.
> (maybe SDRAM, directly connected to CPU)
>
> 4. embedded FPU (or a free, precise library).
>
> 5. QFP package (not BGAs).
>
> 6. price: under 30 EUR.
>
> 7. free develepment tools.
>
>
> My knowledge is: Z80, C51 and x86, ASM only.
>
>
You can add the AT32UC3C0xxx later this year
Some lucky guys are already working with the parts.
* 32 bit AVR32 core
* 128-512 kB Flash
* TQFP-144 (with external bus)
* Floating Point Unit (single precision)
* External Bus Interface
* AVR32 Studio is Free (Eclipse + GCC)
BR
Ulf Samuelsson
Reply by -jg●January 16, 20102010-01-16
On Jan 17, 9:01=A0am, "aleksa" <aleks...@gmail.com> wrote:
> 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?
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
Reply by aleksa●January 16, 20102010-01-16
> 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.
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
www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/WinARM-20060606.exe
and created a small C sample that can be compiled and linked.
The GCC version in winarm is outdated, and these are listed as newer:
www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite
www.devkitpro.org/category/devkitarm
www.yagarto.de
which one should I get? (Using windows XP)
Thanks everyone for your replies!
Reply by bigbrownbeastie●January 16, 20102010-01-16
>> 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)
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
Reply by Nobody●January 15, 20102010-01-15
On Wed, 13 Jan 2010 15:16:10 +0100, aleksa wrote:
> 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)
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.
Reply by rickman●January 15, 20102010-01-15
On Jan 14, 12:25=A0pm, Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
> rickman <gnu...@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. =A0I 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 function=
s
> for one pin on the LM3S9B96!
>
> But you're right, that is an incredible amount of functionality they've
> crammed into that one chip.
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
Reply by -jg●January 14, 20102010-01-14
On Jan 15, 9:08=A0am, -jg <jim.granvi...@gmail.com> wrote:
418627.html
another example: a 'Surfboard' (PC keyboard)
http://www.itechdiary.com/tag/vortex86mx
$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