Fast embedded architectures.

True, but bass-ackwards IMHO. The reason for using a common core like ARM is third-party software support. What is the _advantage_ of ColdFire over ARM?

Reply to
Lewin A.R.W. Edwards
Loading thread data ...

Is that really true. It seems to me that cpu choice is almost irrelevant where app code is written in C.

The snake pits of endianness aside it seems the only issues for embedded are the local I/O capabilities. The other issue for embedded is the availability/portability of the tools and support libraries for higher level I/O - like TCP/IP USB etc.

Regards, Steve

Reply to
Steve Calfee

That's why doing a cut/paste is a canny move. They are a silicon company, and don't really care what core sits in the corner of a die. If the customers want ARM, then sell them ARM.....

-jg

Reply to
Jim Granville

IMHO - and I fully realize this is very arguable - your argument (as stated above) only holds water for to-the-metal OSless applications.

32-bit micros tend to be put in applications where it's crazy to write everything from scratch, and much saner to pick a COTS OS (RTOS maybe, but COTS nevertheless).

Even for the specific case where your argument is valid, it is dubious

- it's much easier to port "to the metal" C from one ARM variant to another than it is to port it to, say, x86. And optimization techniques can be very different on different cores.

This is part of what I meant by third-party software support, by the way. Take PA-RISC, for instance. Dead core, despite the fact that it is still being shipped.

Reply to
Lewin A.R.W. Edwards

Hi, I think we are almost saying the same thing.

First though, in what way is a PA-RISC an embedded processor? I thought it was a big HP Unix system?

Second, (for embedded) the use of an OS is to make complex I/O easier. The need for multi-threads/multi-tasking etc is not relevant. However, an OS used to simplify something like TCP/IP or disk access etc, really helps, but is not strictly necessary.

The rise of the GNU tool chain as at least the first available toolset for midrange embedded systems makes the software much more independent of the cpu. So if the toolset of a Coldfire, ARM, Ubicom and X are all GNU, it seems portability is limited by I/O.

Regards, Steve

Reply to
Steve Calfee

snip

Perhaps in the embedded applications you dealt with, but certainly not all. In a system I worked on, it was used to take care of a lot of the hardware details so we didn't have to write hardware specific code for such things as timer interrupts, procesor initialization, etc. It was essentially a make versus buy decision. And we did use the multi-tasking features to ease the development of the software - i.e. better partitioning without the need for writing a scheduler etc.

Of course it is not necessary, but it is often a good idea. :-)

--
 - Stephen Fuld
   e-mail address disguised to prevent spam
Reply to
Stephen Fuld

No, there are highly embedded processors with PA-RISC as the core.

Ah. Well, here we are not even in the same book, let alone the same page. Your definition of embedded systems does not cover the same gamut that mine does. In many high-end systems (and for that matter even midrange systems), the availability of an OS that will handle multitasking for you is a big plus. Life is much too short to reinvent these wheels for every single project. And the projects that demand these high-end processors are precisely those projects that will use high-end OSes (in the main).

Not at all. There's still OS and device driver support. Put it this way: If you had the choice of picking a core that costs $1.00 plus six months of device driver and OS dev (in order to get some proprietary, uncharacterized system up and running), or a core that costs $1.10 plus say two weeks of adapting a BSP for a particular OS that is guaranteed to meet your realtime needs, what's the sensible choice?

The logic is OK, but the premises underlying that logic are false. "The earth is flat, therefore it is unwise to travel too far in a straight line lest ye fall off it".

Reply to
Lewin A.R.W. Edwards

Moto engineers suffer from Not Invented Here syndrome just as much as engineers elsewhere, I'm sure!

Reply to
Lewin A.R.W. Edwards

Not paying way unresonable amounts of money to ARM?

--
	Sander

+++ Out of cheese error +++
Reply to
Sander Vesik

Ok, I did not know that.

Maybe not even on the same planet. I have only worked on 4 systems with a true OS. That was on a PPC, x86, another x86 and Philips Tri-media, and was 2 Linux and 2 free-BSD systems (lawyers much prefer the license terms of BSD over GPL). The rest of the 10s or 100s of systems have been OS free. The os-less systems tended to get into production nearly on schedule and had useful lives of 10+ years.

My experience with the OS based systems is that they are a win if the OS already handles lots of the infrastructure that you need, file systems, web servers, TCP/IP etc. They also allow large groups of less skilled "application" programmers to do the user interface in some trendy new language like C++, Java or XML (ok not a language, but trendy). These systems were general purpose computers shoehorned into some embedded application. They were late (slow development), disappointingly slow (user interface), and buggy. But they did have the ability to be upgraded later, after all they were general purpose in an embedded box.

Of the four, the simplest OS system was very successful, one was killed in the dot.bomb 2000 bust, and 2 are slowly getting into production as consumer products.

My first response is to ask the volume expected, but even then I would agree with your example because even large volume products care about time to market. However, it seems the $1.00 singlechipper cost is fixed, but the $1.10 ends up as $11.00 or $111.00 because the amount of memory needed, speed requirements, development time, etc is always underestimated.

I know you were using the $1 cost as only an example for cost comparison, but there are some real chips, like PICs and 8051s in that ballpark doing real embedded systems. But, is $1.10 a real ballpark for a system using a "real" OS? It seems like it would jump at least

10 to 100 times.

Lets not even get into the can of worms that defines a "real time" OS, it seems generally that just requires 10x more processing power than the normal load ever anticipated -- and "usually" you get your "real time" response.

If the first part of that sentence as true, I would definitely agree with the second part :)

But the assertion I made is that an OS-less system using GNU tools is not very processor architecture sensitive. However, in a single chipper the processor memory attributes, speed, and cost are exactly the issue. And this thread is about "fast embedded architectures".

~Regards, Steve

Reply to
Steve Calfee

Actually I should put this in the past tense, as the last part I know of went out of production a year ago or thereabouts. It was a PRIME example of both the "it's easy to swap cores" and "it's pointless to swap in a core without good third-party support" arguments. The chip in question was a bunch of x86-compatible peripherals pulled out of a silicon vendor's PC chipset portfolio, stuffed on the same die with a PA-RISC core configured to look like a 486 (little-endian mode, and a couple of bus interface tweaks too I think). It was dead because nobody was porting operating systems to it. USTask was ported sometime in the Lower Cretaceous Era (or should that be, Cretinaceous), but as of 2004 even gcc is no longer really supporting the target.

And these are both VERY significant advantages. Also the big advantage you didn't mention is third-party application code which is already written for OS ABC is generally easier to port to an embedded version of OS ABC than to a totally different OS. I'm thinking multimedia playback, for instance.

Nuh-uh, don't flip the issue :). I was talking about the cost differential between CPUs with similar capabilities but different cores. The cost delta covers IP licensing and silicon die area.

In other words, I am following up on the assertion that it's easy for CPU vendors to switch cores (which is true) by pointing out that there is no reason for them to switch in an unpopular core that has similar performance to a popular core. Hence my original contention that ARM is a better longterm survivor than ColdFire. The big guns in 32-bit embedded systems are ARM, MIPS and PPC, with SuperH maybe in there too. There are various bizarre totally proprietary 16/32-bit architectures in niches like DVD/DVB applications, and ColdFire is better supported than those weird undocumented beasts, but it's still not a good choice for a new longterm design because it is IMHO certain that you'll need to design it out in the foreseeable future. The battle for market leadership is already lost.

Agreed, let's not - because it's irrelevant to this argument specifically, and often doesn't mean anything in the real world either; the systems we're talking about merely have to be "sufficiently realtime" to service I/O quickly enough to maintain some given performance level. But that's not germane to the issue we're arguing here.

That wasn't your original assertion; OSes weren't mentioned. Your original reply _assumed_ that the systems were all OSless (so the only important factor was dev tool support). This ignores the following:

  1. Development tools aren't equal on all platforms, so an unpopular core is a foolish choice compared to a popular core. I personally have spent many man-months fixing problems that were either dev tool bugs, or could have been found in a tenth or a hundredth the time with better tools. These problems get ironed out faster on popular cores.
  2. The majority of real-world 32-bit embedded systems use an OS, generally a COTS OS. Take a browse through your local Best Buy, opening up all the routers, WAPs, NAS appliances, STBs, cellphones and so on. I'd say your particular career experience is highly unusual.
Reply to
Lewin A.R.W. Edwards

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.