Coldfire MCF5272 versus Samsung S3C4510

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,
I'm trying to choose a processor for a new project and I need a 32-bit
processor with on-chip Ethernet with around 50MIPs performance and (of
course) cheap. At the moment my best bet looks like either the
Motorola MCF5272 or the Samsung S3C4510. Price-wise they are pretty
close, speed wise they seem to be pretty close and they seem to both
have not-too-expensive development boards available. Can anyone who
has used these chips comment on their experiences? I plan to run
either eCos or ucLinux on the board.
- Good points and bad points
- Are the debug tools any good? (Looks like the Avocet tools for
Coldfire only run on Windows).
- eCos support for the MCF5272 seems to be a bit spotty (I tried
building it) - how good is it for the S3C4510 (eCos support for the
SNDS100 board is there)
- Support from Motorola or Samsung

Thanks,
Charles Oram

Re: Coldfire MCF5272 versus Samsung S3C4510
On 20 Oct 2003 17:56:06 -0700, snipped-for-privacy@hotmail.com (Charles Oram)

Quoted text here. Click to load it

Clients of ours have built and developed S3C4510 systems and
are very pleased with them. The Ethernet controller is complex
but very fast - this is typical of integrated 10/100 systems.

I can't comment on C tools chains as we don't use them. From
observing other companies, I can only say that if you don't
get a matching compiler and OS sources you may end up with
a nightmare.

Stephen
--
Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: Coldfire MCF5272 versus Samsung S3C4510

Quoted text here. Click to load it

I've used the 4510 (I did the original eCos port to the SNDS100 -- though
mine had a 4500 on it). The 4510 is a decent part. However, support from
Samsung is problematic for small customers.  The Samsung docs are marginal.
They were translated by somebody with rather poor english skills, and range
from cryptic to outright misleading.  

There were bugs in the 4500 Ethernet DMA controller requiring that software
verify the Ethernet frame CRC.  That cut into throughput a bit.  At one
point I was about 70% convinced that the 4510 had an analagous problem with
tx frames getting corrupted before the CRC was generated, but it was rare
enough that I had a tough time catching the problem.  If you're using a
higher level protocol that handles errors (e.g. TCP/IP) then it's OK.

The 4530 had all sorts of bugs in the UART: the FIFOs were almost unusable,
and flow control just plain didn't work.

Quoted text here. Click to load it

I used Greenhills ARM compiler for a few days under DOS/Windows, then
switched to GCC under Linux and never looked back. I was perfectly happy
with GDB for debugging, though I found an occasional printf() was generally
easier that hooking up GDB.

Quoted text here. Click to load it


Getting information out of Samsung is tricky.  AFAICT, there are no FAEs in
the states who know anything.  Sometimes they'll only admit a problem exists
after you've proved it to them.  They don't seem to ever fix any existing
parts -- bugs get fixed when new part number come out (e.g. 4500 -> 4510
fixed the receive Ethernet corruption problem), but they don't seem to rev
masks to fix bugs.

That said, it's hard to beat the Samsung parts for price/performance.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: Coldfire MCF5272 versus Samsung S3C4510
There are many commercial tools for ColdFire, as well as GNU tools.
Commercial tools include Diab, Greenhills, Metaware, Metrowerks, ...  We use
Diab & EST tools (now owned by WindRiver), they work well, they're expensive
though.  See www.wildrice.com/coldfire for a useful mailing list,
particularly helpful if you choose GNU tools.

Paul Kinzer
QTI

Quoted text here. Click to load it



Site Timeline