Coldfire MCF5272 versus Samsung S3C4510

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

Reply to
Charles Oram
Loading thread data ...

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

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web:
formatting link
- free VFX Forth downloads
Reply to
Stephen Pelc

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.

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.

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??
                               visi.com
Reply to
Grant Edwards

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

formatting link
for a useful mailing list, particularly helpful if you choose GNU tools.

Paul Kinzer QTI

Reply to
news.qgraph.com

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.