Re: Fast embedded architectures.
From: Steve Calfee (stevecalfee_at_hotmail.com)
Date: 11/16/04
- Next message: James Beck: "Re: SPI problem"
- Previous message: Mark Borgerson: "Re: SPI problem"
- In reply to: myren, lord: "Re: Fast embedded architectures."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 16 Nov 2004 14:16:54 -0800
On Mon, 15 Nov 2004 23:00:43 -0500, "myren, lord"
<thefowle@wam.umd.edu> wrote:
>
>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.
You are right about the marketing and product "stragedy", I like the
ip2k design. I don't understand that last part.
> Devel costs are just too freaking high.
>
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).
>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.
>
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.
>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 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.
>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.
>
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.
>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
- Next message: James Beck: "Re: SPI problem"
- Previous message: Mark Borgerson: "Re: SPI problem"
- In reply to: myren, lord: "Re: Fast embedded architectures."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
