Fast embedded architectures. - Page 3

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

Translate This Thread From English to

Threaded View
Re: Fast embedded architectures.
On 18 Nov 2004 17:37:08 -0800, snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards)

Quoted text here. Click to load it
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



Re: Fast embedded architectures.


snip

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

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



Re: Fast embedded architectures.
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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).

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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".

Re: Fast embedded architectures.
On 19 Nov 2004 02:52:20 -0800, snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards)

Quoted text here. Click to load it
Ok, I did not know that.
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it

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


Re: Fast embedded architectures.
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Re: Fast embedded architectures.
Quoted text here. Click to load it

  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


Re: Fast embedded architectures.
Quoted text here. Click to load it

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

Re: Fast embedded architectures.
Quoted text here. Click to load it

Not paying way unresonable amounts of money to ARM?

--
    Sander

+++ Out of cheese error +++

Re: Fast embedded architectures.
Quoted text here. Click to load it
 >
Quoted text here. Click to load it

I love your analysis on the IPxks.  They really point out what these
chips are all about.

Unfortunately, the marketting is fscked.  The design is fscked.  "If i
only had more speed" IS NOT the solution to modern integrated
processors.  Even when its true.  Devel costs are just too freaking high.

I've spent way way WAY too long building a bit banged async rs-485 light
dimmer / sensor network off the scenix SX chips to think bit banged
uarts are even remotely permissible on a system ever again.

There's really no reason not to have UARTS on a system.  the design
costs cant be THAT much.  Bit banging async serial is pain enough, i
dont want to begin to have ot imagine doing the same thing for ethernet.
    4 mb addressable space, what sort of restriction is that?  i dont
want to build my own banking system too!

The IP3k especially seems like its competing more with FPGA's than it is
your conventional control-oriented embedded processor (the 8threaded
0-cost context swtich should be the first give-away something is funny).
  I'm really really worried though that development would be
rediculously difficult, what with such a multi-threaded design.  Having
to do EVERYTHING in software.  There's way too much too develop, not
enough hardware helping out, and way too many concurrency issues to mess
the whole thing up.  The tools had better blow away everything i've seen
before, but i kind of doubt that they're be up to the challenge.  I'd
want to be able to step through one thread while hte processor was active.

Before anyone goes around taking these harsh words too seriously, I
really dont have any idea what programming these things is like.  I'd be
very interested.  The devel kit comes with a lot of code, I know that.
I assume you have to use the OS they give you/you purchase to use that
code.  That sounds like some frightening lock in, but I guess if your
making a solution your only goal is to ship it.  I'd be really
interested to here peoples experience actually using these.

-Myren

Re: Fast embedded architectures.

Quoted text here. Click to load it

My experience too, ubicom is simply pushing the problems elsewhere,
and that elsewhere (concurrency issues) is a nasty place. I think
Motorola's embedded PowerPC family integrated with multiple TPUs is a
better solution. I want more parallel hardware support, not less.

Re: Fast embedded architectures.
On Mon, 15 Nov 2004 23:00:43 -0500, "myren, lord"

Quoted text here. Click to load it

You are right about the marketing and product "stragedy", I like the
ip2k design. I don't understand that last part.

Quoted text here. Click to load it
My experience with the ip2k is that the SDK/os keeps development time
in line with other significant embedded development. This means you
can do a web server (for configuration and interface), custom I/O
software (some in assembly) as easily as other solutions, maybe
quicker. You just cannot compare development with a PIC/SX and with
the C programmable, fast! ip2k (and maybe the ip3k, I don't know).
 
Quoted text here. Click to load it

My experience is that most problems are from resource limitations.
This means if you have enough memory and speed, doing bitbang
implementations are not such agony. It is only when you are really
close to the max capability of the chip does the development time go
asymptotic with respect to completion.

Quoted text here. Click to load it
The way I think they use multithreading is not like done in Linux. You
do not try to run SMP. You allocate a thread to a specific I/O device
and minimize the inter-thread communication. Done this way you don't
even need an interrupt routine, one thread just watches for a I/O
event and handles it. So to run a 100base_t interface, one thread
handles all I/O and is fed data buffers from the main application
(which I think is run in only one thread). The only concurrency issue
is the communications between threads. Supposedly read-modify-write
instructions are atomic for easy semaphores etc.

Like I said this is no PIC.

Quoted text here. Click to load it
I have not used the ip3k tools. The ip2k gdb is pretty marginal but
generally you can find work arounds to such things as single stepping
with a heavy interrupt load. Supposedly the ip3k had the thread aware
version of gdb.

Quoted text here. Click to load it



Site Timeline