From Quote.com:
------------------------
At the Embedded Systems Conference this week, Xilinx (Nasdaq: XLNX)
announced the release of new advanced features for its industry-leading
MicroBlaze(TM) 32-bit soft processor core including Hardware Divide,
LocalLink, Instruction and Data caches, and a Barrel Shifter. Delivering
68 Dhrystone-MIPS at 85 MHz in the new Spartan-3(TM) FPGA, MicroBlaze
provides customers with a high-performance, low-cost processor solution
with the effective price of $1.40.

In related news, Xilinx also announced its Embedded Development Kit
(EDK) version 3.2 for designing SoC using Xilinx FPGAs. EDK(TM) version
3.2 innovates the programmable system domain by integrating embedded
hard and soft-core processors, customizable IP, and FPGA logic into a
single programmable platform. With the new version, designers can now
efficiently implement embedded systems using Xilinx Virtex-II Pro(TM)
FPGAs featuring hard embedded IBM PowerPC(TM) cores and Multi-Gigabit
Transceivers and/or a soft processor system using MicroBlaze in
Spartan-3 FPGAs.

-----------------------

By the way, Microsoft unveils $3 Windows CE runtime pricing.

I wonder, if super-fast SOC (System On Chip) with flexible
guts and Windows CE were priced as low as few bucks, who
would buy PICs?

Mike.

P.S. Hey, folks, how do you think, should a newbie choose
MicroBlaze instead of 18FXXXX?

You're comparing apples and oranges, to an extent...plus have you seen how
much IP cores can cost for FPGAs?

With a PIC, you can buy a single unit AND get the functionality you need.
You don't have to drop $25,000 for a CPU core, $5000 for a async core, and
then have to worry about interfacing external DRAM. And try doing FPGA
development with the low-end software and hardware tools -- if you're
hardcore about FPGAs, you'll want to invest in more than the "web-based"
design tools and a $100 FPGA "prototype card".

I'm not saying that FPGAs aren't cool and interesting, but they're really
suited for mid- to high-volume applications still, or applications that
aren't too price sensitive.

You really *can* spend a few bucks on a PIC programmer, a couple of PICs
from the local electronics store, and download enough freeware to do a lot
of hardware projects...either for fun, or commercially.

> At the Embedded Systems Conference this week, Xilinx (Nasdaq: XLNX)
> announced the release of new advanced features for its industry-leading
> MicroBlaze(TM) 32-bit soft processor core including Hardware Divide,
> LocalLink, Instruction and Data caches, and a Barrel Shifter. Delivering
> 68 Dhrystone-MIPS at 85 MHz in the new Spartan-3(TM) FPGA, MicroBlaze
> provides customers with a high-performance, low-cost processor solution
> with the effective price of $1.40.
>
> ...
>
> I wonder, if super-fast SOC (System On Chip) with flexible
> guts and Windows CE were priced as low as few bucks, who
> would buy PICs?

Lots of people, I suspect. Most of my PIC projects are not limited by
compute power, so all the fancy 32 bit core, 85MHz, blah, blah, blah, is
of no benefit to them. Does the Xilinx come in an 8 pin package, 14, 18,
28? How many of them can be arbitrary I/O? Can it run completely from
internal ROM, RAM, and oscillator, requiring only power and ground with
all the other pins I/O? Then can it do all that while on less than a
milliamp at anywhere from 2 to 5.5 volts at 4MHz or so clock rate? I
wouldn't want Windows CE or any other operating system anywhere near most
of my PIC projects.

While the Xilinx specs you mention do sound impressive, I don't think it
is competing in the same market as most PICs.

SCO holds the rights to the UNIX operating system software originally
licensed by AT&T to approximately 6,000 companies and institutions
worldwide (the “UNIX Licenses”). The vast majority of UNIX software used
in enterprise applications today is a derivative work of the software
originally distributed under our UNIX Licenses. Like you, we have an
obligation to our shareholders to protect our intellectual property and
other valuable rights.

In recent years, a UNIX-like operating system has emerged and has been
distributed in the enterprise marketplace by various software vendors.
This system is called Linux. We believe that Linux is, in material part,
an unauthorized derivative of UNIX.
As you may know, the development process for Linux has differed
substantially from the development process for other enterprise
operating systems. Commercial software is built by carefully selected
and screened teams of programmers working to build proprietary, secure
software. This process is designed to monitor the security and ownership
of intellectual property rights associated with the code.
By contrast, much of Linux has been built from contributions by numerous
unrelated and unknown software developers, each contributing a small
section of code. There is no mechanism inherent in the Linux development
process to assure that intellectual property rights, confidentiality or
security are protected. The Linux process does not prevent inclusion of
code that has been stolen outright, or developed by improper use of
proprietary methods and concepts.
Many Linux contributors were originally UNIX developers who had access
to UNIX source code distributed by AT&T and were subject to
confidentiality agreements, including confidentiality of the methods and
concepts involved in software design. We have evidence that portions of
UNIX System V software code have been copied into Linux and that
additional other portions of UNIX System V software code have been
modified and copied into Linux, seemingly for the purposes of
obfuscating their original source.
As a consequence of Linux’s unrestricted authoring process, it is not
surprising that Linux distributors do not warrant the legal integrity of
the Linux code provided to customers. Therefore legal liability that may
arise from the Linux development process may also rest with the end
user.
We believe that Linux infringes on our UNIX intellectual property and
other rights. We intend to aggressively protect and enforce these
rights. Consistent with this effort, on March 7, we initiated legal
action against IBM for alleged unfair competition and breach of contract
with respect to our UNIX rights. This case is pending in Utah Federal
District Court. As you are aware, this case has been widely reported and
commented upon in the press. If you would like additional information, a
copy of the complaint and response may be viewed at our web site athttp://www.sco.com/scosource.
...
-------------------------------------------------

Olin Lathrop wrote:
> > I wonder, if super-fast SOC (System On Chip) with flexible
> > guts and Windows CE were priced as low as few bucks, who
> > would buy PICs?
...
> I wouldn't want Windows CE or any other operating system
> anywhere near most of my PIC projects.
>
> While the Xilinx specs you mention do sound impressive,
> I don't think it is competing in the same market as most PICs.

> Marc Nicholas Geekythings Inc., UNIX, Database, Security
> and Networking Consulting wrote:
>
>> With a PIC, you can buy a single unit AND get the
>> functionality you need. You don't have to drop $25,000
>> for a CPU core, $5000 for a async core...
>
> When MS gets involved in a business, things changed.
> Where are all the simple Operating Systems now?

I was referring to IP (Intellectual Property) cores for FPGAs...nothing to
do with MS. You can either design your own FPGA functionality, or buy it as
an IP core (a VHDL package, etc.). It's quite common for IP cores for FPGAs
to run $5000-$25000, depending on the complexity of the core. These cores
are sold by FPGA manufacturers (Xilinx, Altera, etc.) and by third parties
who've done the legwork.

At 03:23 PM 5/24/2003 -0400, you wrote:
>You're comparing apples and oranges, to an extent...plus have you seen how
>much IP cores can cost for FPGAs?
>
>With a PIC, you can buy a single unit AND get the functionality you need.
>You don't have to drop $25,000 for a CPU core, $5000 for a async core, and
>then have to worry about interfacing external DRAM. And try doing FPGA
>development with the low-end software and hardware tools -- if you're
>hardcore about FPGAs, you'll want to invest in more than the "web-based"
>design tools and a $100 FPGA "prototype card".
>
>I'm not saying that FPGAs aren't cool and interesting, but they're really
>suited for mid- to high-volume applications still, or applications that
>aren't too price sensitive.

More than that, FPGAs have an awful lot of unused (read as "power hungry")
silicon logic unused.

I'm an old guy, and over these many years of designing products, I have
NEVER found a case where something else didn't work better than FPGA's,
EXCEPT special, low volume cases such as custom test equipment.

More than that, I am not welcomed at Xylinx, having proved that one of
their products had a serious flaw (unconnected CMOS input internal to the
device). I woull look at some other vendors, such as Cypress.

The major difference between LInux and other operating systems is you are
able to see what is inside in opposite to Windows, Unix and other
commercional software, because Linux is done by enthusiasts. I don't know
how is Unix patented exactly but if there were any breaks of a patent ATT
had wouldn't wait so long.
Buying Windows you get a pretty black box not knowing what happen next time.
Same with Windows CE.

Have you ever heard what difference is between programmers and cokie eaters?
(hope the term is right, English is my thirth or four language).

>> At the Embedded Systems Conference this week, Xilinx (Nasdaq: XLNX)
>> announced the release of new advanced features for its industry-leading
>> MicroBlaze(TM) 32-bit soft processor core including Hardware Divide,
>> LocalLink, Instruction and Data caches, and a Barrel Shifter. Delivering
>> 68 Dhrystone-MIPS at 85 MHz in the new Spartan-3(TM) FPGA, MicroBlaze
>> provides customers with a high-performance, low-cost processor solution
>> with the effective price of $1.40.
"Effective price"...let me guess, I suspect that means something like it uses 5% of the resources in
a $28 part, in 100K units

> On Sat, 24 May 2003 16:26:51 -0400, you wrote:
>
>>> At the Embedded Systems Conference this week, Xilinx (Nasdaq: XLNX)
>>> announced the release of new advanced features for its industry-leading
>>> MicroBlaze(TM) 32-bit soft processor core including Hardware Divide,
>>> LocalLink, Instruction and Data caches, and a Barrel Shifter. Delivering
>>> 68 Dhrystone-MIPS at 85 MHz in the new Spartan-3(TM) FPGA, MicroBlaze
>>> provides customers with a high-performance, low-cost processor solution
>>> with the effective price of $1.40.
> "Effective price"...let me guess, I suspect that means something like it uses
> 5% of the resources in
> a $28 part, in 100K units

It probably means that the cost of the IP core amortized over 100,000 units
plus the cost of the silicon works out to $1.40 ;-)

Spartans aren't terribly expensive, silicon-wise...getting them into a state
you can use in your product is often the expensive part (IP cores,
debugging, programming, etc).

Because you are probably too young to know.
Cookie eaters were not able to program in hexadecimal code :-) and to
correct errors in OS.
I learned to program my first computer when I was 14. It was called LGP 30 -
input device was a typewritter or punched tape, output device typewriter,
memory 1KByte drumm.... It was funny times.

> Because you are probably too young to know.
> Cookie eaters were not able to program in hexadecimal code :-) and to
> correct errors in OS.
> I learned to program my first computer when I was 14. It was called LGP
30 -
> input device was a typewritter or punched tape, output device typewriter,
> memory 1KByte drumm.... It was funny times.
>
> The term of cookie eaters was invented when Unix has born.
>
> Igor
>

I have heard the terms "quiche eaters" and "real programmers" used together
to describe the difference between a poor programmer and a hardcore hacker
type programmer. Something like:

"A quiche eater programs in assembler while a real programmer uses binary
and writes his program directly into the computer core using the front panel
switches."

Mike, this is pretty sweet technology, and with CE at $3 a pop, I could
see applications for it. But I think you are wrong in saying that this
technology is a "PIC killer"

I make pretty "dumb" industrial controls and the small 8, 14 and 18-Pin
PICs are all I need. My first consideration is reliability - even over
price. The items we manufacture are fairly cheap, and if they fail, the
labour alone to diagnose and replace them can be many times that of the
original product. PICs have a proven track record in automotive and
industrial applications and my own records back this up.

On top of that, limiting projects to 4MHz makes it MUCH easier to get
certifications - such as CE and C-Tick etc.

For now, I'm happy with my 8-Pin PICs. This is what I learnt the PIC
instruction set on, and I still have an entire list of projects that I
want to develop with this device - particularly since the introduction
of the 10-bit A/D

> > I WISH I WERE WRONG. But ...
>
> Mike, this is pretty sweet technology, and with CE at $3 a pop, I could
> see applications for it. But I think you are wrong in saying that this
> technology is a "PIC killer"
>
> I make pretty "dumb" industrial controls and the small 8, 14 and 18-Pin
> PICs are all I need. My first consideration is reliability - even over
> price. The items we manufacture are fairly cheap, and if they fail, the
> labour alone to diagnose and replace them can be many times that of the
> original product. PICs have a proven track record in automotive and
> industrial applications and my own records back this up.
>
> On top of that, limiting projects to 4MHz makes it MUCH easier to get
> certifications - such as CE and C-Tick etc.
>
> For now, I'm happy with my 8-Pin PICs. This is what I learnt the PIC
> instruction set on, and I still have an entire list of projects that I
> want to develop with this device - particularly since the introduction
> of the 10-bit A/D
>
> Like somebody mentioned, you have to compare Apples with Apples.

I'd have to agree. High power microcontrollers have been around at least as
long as PICs, and PICs have remained. The reason is that a PIC serves a
completely different market then what a high power microcontroller would be
used for. A PIC was never meant to be a "high power" device, a PIC is for
small controller type apps. Calling this product a "PIC Killer" is like
calling a Pentium 4 a PIC killer, they cover completely separate markets.

Plus, the idea of "configurable" cores is not new, Xilinx, Altera and other
programmable logic companies have been doing that for years, Xilinx has just
put a new spin on it. Good for them, but to compare them to PICs is useless.
TTYL

Me three. Processing power is great, but the ideal device for any particular job is based on many other factors.

If I were to be given a choice on altering whatever I need on a PIC to suit my needs, it won't be "add more power, reduce price". Instead, I'd take the F872, strip off a few peripherals I'm not using, lose a couple pins, and then drop the price a bit. Only thing I would add is built-in current-limiting resistors (ala LM3914, etc) cause they seem to be the least bang for space in my apps. I run my PICs at <4Mhz, and on a device I'm currently building, I'm thinking of ways to slow it down. Additionally, I can't imagine any Xlinx-class micro being as simple to develop on as PICs are (but that's just an opinion, and not backed by any evaluation of Xlinx products).

I don't see myself looking at the Xlinx datasheet for any reason right now, but I've recently downloaded some lower-end MSP430 datasheets, and AVR datasheets. To me, that class of products are the *potential* PIC killers. However, I'd like to think Microchip will think the same as you (that the Xlinx is serious competition), so perhaps they may drop the prices a bit :-)

Herbert Graf wrote
> ... A PIC was never meant to be a "high power"
> device, a PIC is for small controller type apps.
> Calling this product a "PIC Killer" is like calling
> a Pentium 4 a PIC killer, they cover completely
> separate markets.

The phrase about calling a Pentium 4 a PIC killer
is not as ridiculous as it may seems at a glance now,
in my opinion. Industrial Pentium 4 based single board
computers (SBCs)are getting smaller and cheaper, power
consumption is dropping too. If you want to control
complex industrial devices, not toys, you should think
many times before choosing PIC direction, even if the
computational power is not needed right now.
Is an industrial equipment market completely
separate market, not for PICs?

> Herbert Graf wrote
> > ... A PIC was never meant to be a "high power"
> > device, a PIC is for small controller type apps.
> > Calling this product a "PIC Killer" is like calling
> > a Pentium 4 a PIC killer, they cover completely
> > separate markets.
>
> The phrase about calling a Pentium 4 a PIC killer
> is not as ridiculous as it may seems at a glance now,
> in my opinion. Industrial Pentium 4 based single board
> computers (SBCs)are getting smaller and cheaper, power
> consumption is dropping too. If you want to control
> complex industrial devices, not toys, you should think
> many times before choosing PIC direction, even if the
> computational power is not needed right now.
> Is an industrial equipment market completely
> separate market, not for PICs?

Come now Mike, stop trying to come up with excuses. The PIC is in a
different class. Noone in their right mind is going to develop a product
that, say, reads a keypad (something ideal for a PIC) using an SBC and
succeed in selling it. Remember, volume makes money, and in larger designs
everything counts. You are looking at this situation from a hobbyist point
of view perhaps, in that case an SBC COULD be a replacement for a PIC, the
same reason that I start out all my designs with a 16F877: It's overkill for
the app in mind but in the initial development stage (or in a hobbyist
world) the extra $5 I spend on it is worth it.
You mention industrial designs: sorry, no industrial design is going to
TRUST a "PC" architecture, it is not designed for that environment (both
from a physical standpoint and a functional standpoint). That said, please
try and stay on topic, we are discussing how the Xilinx product you mention
is in a completely different class from PICs.

Heh. Never heard of it in that context, although we have legends of the
exploits of "real programmers."

I was somewhat amused about the people claiming their GREATEST productivity
improvements came from going to multiple monitors. I was trying to decide
whether MY greatest productivitiy improvement was the move from actual card
punch machines to editting card deck images on a 24x80 CRT, or the move from
the 24x80 CRT to a large screen (19 inch B&W?) with room and support for
quite a few 24x80 windows and SOME quite a bit bigger than that...

> The phrase about calling a Pentium 4 a PIC killer
> is not as ridiculous as it may seems at a glance now,
> in my opinion. Industrial Pentium 4 based single board
> computers (SBCs)are getting smaller and cheaper, power
> consumption is dropping too. If you want to control
> complex industrial devices, not toys, you should think
> many times before choosing PIC direction, even if the
> computational power is not needed right now.
> Is an industrial equipment market completely
> separate market, not for PICs?

I have an alarm system in my loft. It's got a small PIC inside it. It
attaches to a bunch of wireless sensors. It will even dial my cellphone and
play a prerecorded message if I want It to. Short of it making coffee for
me, tell me how a Pentium 4 inside that thing would make it:

My point is that sometimes you have to "right size" projects and products.

With respect to power consumption, are you really naïve enough to think that
a Pentium 4 will *ever* have power consumption even remotely approaching
that of a PIC?
I'm starting to think you're trolling, Mike :-p

Mike, this is pretty sweet technology, and with CE at $3 a pop, I could
see applications for it. But I think you are wrong in saying that this
technology is a "PIC killer"

Yeah. "Priced as low as $0.50 each" is like TRUTH compared to a statement
like "effective price of $1.40", whatever "effective price" means. Those
FPGAs aren't cheap on a per-part basis, the development environment isn't
cheap, and they tend to eat power like it was free. And they come in big
huge packages (well, packages with huge numbers of pins, some of which are
actually distressingly and unmanagably tiny for many types of project.)
Perhaps they'll compete with those ATMEGA, EX80s, really huge PICs and
such that I was complaining about off in other threads.

I pulled some Xilinx spartan 2XL devices out of a dumpster. They look
almost managable (64pin QFP?) - has anyone got a clue as to how I might go
about getting them to do something useful?

Noone in their right mind is going to develop a product that,
say, reads a keypad (something ideal for a PIC) using an SBC and
succeed in selling it.

heh. You haven't attended any of the microsoft talks about their
support for "embedded systems", have you? It's pretty scary - it along
the lines of "a windows XP box stipped down to run only a small set of
applications on a limitted hardware configuration." And with a windows
box selling for about $500 and all those "write a huge and crappy but
"conforming" and pretty application in 10 minutes with Hypervisual
SuperJAVAlike++ Builder tool package", it might have succeeded in the
"time to market is everything" world that existed in late 1999. One of
the few useful things to come out of the current ecconomic slump is a
return for some consideration of efficiency!

Herbert Graf wrote:
> ... Noone in their right mind is going to develop a
> product that, say, reads a keypad (something ideal
> for a PIC) using an SBC and succeed in selling it.
> Remember, volume makes money, and in larger designs
> everything counts. You are looking at this situation
> from a hobbyist point of view perhaps, in that case
> an SBC COULD be a replacement for a PIC

No, I'm looking at this situation from post-communist
guy's point of view, trying hard to catch how free-market
works. Personally, I'm not reach enough to be able to
afford cheapest things. I'm forced here to optimize my
purchasing curve to make my work more effective.
Regarding PIC-not SBC-based keyboards. At first,
not SBC, but rather SOC (system on chip) in this case.
At second, mechanical typewriters didn't need any
PIC-like controller at all. Usual keyboards need them.
Future input subsystems ... Try your imagination, you're
a student, but I've a feeling you're two times older
then me.

> You mention industrial designs: sorry, no industrial
> design is going to TRUST a "PC" architecture, it is not
> designed for that environment (both from a physical
> standpoint and a functional standpoint).

Are you referring to PC/104 & PC/104 Plus form factor
industrial standards,
or to 3.5" ESB (Embedded System Board), that is a
de-factor standard for Taiwanese Industrial PC makers
and is broadly adopted by customers.
Or to 5.25" ESB & EBX that is a de-factor industry
standard set by Motorola/Ampro and some other industrial
makers.
Customers do trust in them, as they do in embedded
Operating Systems.

> That said, please try and stay on topic, we are
> discussing how the Xilinx product you mention
> is in a completely different class from PICs.

Agree, a completely different class, like typewriters
class is completely different from following IBM PC XT
with a dot-matrix printer. (Both classes' motors:
1300 rpm from typewriters and step-motors from dot-matrix
printer are scattered somewhere in a dust in my garage :-)

On Sun, May 25, 2003 at 12:25:48AM -0700, William Chops Westfield wrote:
> I pulled some Xilinx spartan 2XL devices out of a dumpster. They look
> almost managable (64pin QFP?) - has anyone got a clue as to how I might go
> about getting them to do something useful?

Download the Xilinx WebPack (free) which is very user-friendly, especially
for free software. Build a Parallel Cable III (search for that phrase on
google and you'll find a PDF schematic from Xilinx) which is only a handful
of passives and 2 74HC125 tri-state buffers.

Xilinx probably has an appnote with a sample hookup. I'm not sure what
a "2XL" would be, sounds more like a suffix (XL = 3.3v in the CPLD parts,
but "Spartan" is their low-end FPGA line).

> Because you are probably too young to know.
> Cookie eaters were not able to program in hexadecimal code :-) and to
> correct errors in OS.
> I learned to program my first computer when I was 14. It was called LGP
30 -
> input device was a typewritter or punched tape, output device typewriter,
> memory 1KByte drumm.... It was funny times.
>
> The term of cookie eaters was invented when Unix has born.
>
> Igor
>

I have heard the terms "quiche eaters" and "real programmers" used together
to describe the difference between a poor programmer and a hardcore hacker
type programmer. Something like:

"A quiche eater programs in assembler while a real programmer uses binary
and writes his program directly into the computer core using the front panel
switches."

> The phrase about calling a Pentium 4 a PIC killer
> is not as ridiculous as it may seems at a glance now,
> in my opinion. Industrial Pentium 4 based single board
> computers (SBCs)are getting smaller and cheaper, power
> consumption is dropping too. If you want to control
> complex industrial devices, not toys, you should think
> many times before choosing PIC direction, even if the
> computational power is not needed right now.

Here's a genuine real world example. About two weeks ago a customer had a
gizmo that had a digital input for when a diesel engine was on, and when
it was being abused by being run too fast. Among other things, this gizmo
sends a message to a central office via satellite when certain events
occur, like the engine being abused.

The problem was that this now needed to be hooked up to an engine that
didn't provide these outputs. The only thing available was a tachometer
signal generated by a magnitized coil in close proximity to teeth on the
flywheel. This is an AC analog signal that produces 127 cycles per engine
revolution. The amplitude is anywhere from a few 100mV to tens of volts
p-p. The job was to design and build two prototype quick and dirty
converters from the tachometer signal to the existing digital inputs.
They don't want the engine abused signal asserted until the engine has
been over the speed limit continuously for 5 seconds. They don't want a
satellite message for every short vrooom of the gas pedal, just for
sustained excessive speed. The exact engine speed theshold isn't known.
The unit will somehow have to be adjusted when installed. And of course,
these two prototype units need to be their hands yesterday. +12V, +5V,
and ground are available. Each unit needs to have two channels (two tach
in signals, two sets of engine on and abused output signals).

I did this with an LM324 front end to convert the tach signal into a nice
0-5V digital signal using a little filtering and hysterisis. Then I
programmed a 12F629 to run with its internal 4MHz oscillator and compute
the period between tach pulses, then filter that a little to make a
reasonably solid 16 bit value internally. A momentary pushbutton was tied
between ground and a PIC pin with passive pullup. The current tach period
becomes the high/low speed threshold when pressed. At installation time,
you run the engine at wherever you want the speed threshold to be, then
press the button. This value gets saved in EEPROM, so it doesn't get lost
on power down. Two pins drive the two inputs of the original gizmo. I
also added two LEDs driven from PIC pins with resistors to +5V. One lit
when the engine was considered on (tach period didn't overflow the 16 bit
internal value), and the other lit when the instantaneous speed was over
the threshold. The LEDs are only for the field installers. The whole
unit will be in a sealed box and never seen by the end user. For two
channels I simply used two 12F629, and still had two unused opamps left of
the four in the LM324. A technician built 2 of these simple circuits on
two small pieces of perfboard. Problem solved.

OK Mike, I'm really eager to hear how a single board computer would have
somehow solved this problem better.

> "A quiche eater programs in assembler while a real programmer uses
> binary and writes his program directly into the computer core using the
> front panel switches."

I hadn't heard the "quiche eater" term before, but shouldn't your quiche
eaters be restricted to writing MFC apps in Super Turbo Visual Basic++
with self-debugging GUI where all new code is just combining templates
that Must Not be Questioned provided by the software gods from the great
temple in Redmond?

Hail be to Redmond,
Source of the source,
Home of the glue,
Land of the bug,
Where ledgend tells us of an aincent race of powerfull lawyers who in
co-operation with the lesser devels know as "marketing" created the mystic
EULA of yore.

> I pulled some Xilinx spartan 2XL devices out of a dumpster. They look
> almost managable (64pin QFP?) - has anyone got a clue as to how I might go
> about getting them to do something useful?

You should be able to build a JTAG programming cable without too much
hassle, and use the free Web software over at Xilinx. If you've already got
an AVR in-circuit programming cable, you might be able to use that as-is or
with some modification. I'm sending you a Xilinx schematic privately.

There are a bunch of people building their own FPGA CPU cores over athttp://www.fpgacpu.org...which might be something interesting to do with
them. Not sure if the Spartan IIs you have have enough gates or not.

> <Attempt to muddle the thread snipped>
>
> > You mention industrial designs: sorry, no industrial
> > design is going to TRUST a "PC" architecture, it is not
> > designed for that environment (both from a physical
> > standpoint and a functional standpoint).
>
> "A physical standpoint", "a functional standpoint" -
> what are these? Who is brand-new EE? Me or you?
>
> Are you referring to PC/104 & PC/104 Plus form factor
> industrial standards,
> or to 3.5" ESB (Embedded System Board), that is a
> de-factor standard for Taiwanese Industrial PC makers
> and is broadly adopted by customers.
> Or to 5.25" ESB & EBX that is a de-factor industry
> standard set by Motorola/Ampro and some other industrial
> makers.
> Customers do trust in them, as they do in embedded
> Operating Systems.

I'm talking about the PC. Would YOU trust a PC in running say, an elevator?
I know I wouldn't, it's way to unstable for that sort of environment. While
some SBCs ARE used in an industrial environment I see little reason other
than laziness for there use.

Frankly Mike you are sounding more and more like a troll, especially with
the comments I snipped (including the attempt to insult me) which were
completely inappropriate, consider carefully before responding.

Herbert Graf wrote:
> While some SBCs ARE used in an industrial environment I see
> little reason other than laziness for there use.

Now you're going a bit off the deep end too. Most single board computers
(which usually implies PC architecture with x86 CPU) are intended for
industrial embedded applications. Sometimes you do need a lot of compute
power while still providing a GUI or whatever to the end user, for
example. The PC platform is not inherently unreliable. That feature is
added by the software. The advantage of using the PC architecture for
these single board computers is that all the compilers and other
development tools are already available and more stable and cheaper than
proprietary architectures due to the much greater volume. I wouldn't want
to run Windows on a mission-critical SBC, but there are lots of other
choices for the PC architecture. In some cases Windows might even be
appropriate where the SBC is used over a traditional desktop system mostly
due to ruggedness, space, weight, or mechanical integration issues.

> Herbert Graf wrote:
> > While some SBCs ARE used in an industrial environment I see
> > little reason other than laziness for there use.
>
> Now you're going a bit off the deep end too. Most single board computers
> (which usually implies PC architecture with x86 CPU) are intended for
> industrial embedded applications. Sometimes you do need a lot of compute
> power while still providing a GUI or whatever to the end user, for
> example. The PC platform is not inherently unreliable. That feature is
> added by the software. The advantage of using the PC architecture for
> these single board computers is that all the compilers and other
> development tools are already available and more stable and cheaper than
> proprietary architectures due to the much greater volume. I wouldn't want
> to run Windows on a mission-critical SBC, but there are lots of other
> choices for the PC architecture. In some cases Windows might even be
> appropriate where the SBC is used over a traditional desktop system mostly
> due to ruggedness, space, weight, or mechanical integration issues.

I agree that SBCs are meant for those environments, I agree that they ARE
used for those environments, however I disagree that they SHOULD be used for
those environments. Call it personal opinion, but a Pentium is not something
I want controlling my car. It was not designed for real time control, it's
architecture has to be "worked around" to be used for real time control.
Again, SBCs are EASY, but that doesn't mean they SHOULD be used, at least
not in my eyes. I guess I'm the only one who thinks this way, oh well...
TTYL

Herbert Graf wrote:
> I agree that SBCs are meant for those environments, I agree
> that they ARE used for those environments, however I disagree that they
> SHOULD be used for those environments.

Then what environments do you think they should be used in, or do you
think they shouldn't exist at all?

> Call it personal opinion, but a Pentium is not something
> I want controlling my car.

I'm looking for a good reason here else this is just a bunch of pointless
hot air.

> it's [the Pentium's] architecture has to be "worked around" to be
> used for real time control.

That's blatant nonsense! What exactly about the Pentium architecture do
you think makes it unsuitable for real time control? I think a Pentium
can be very effective in that role, and I've used it that way with good
success.

> Again, SBCs are EASY, but that doesn't mean they SHOULD be used, at
> least not in my eyes.

Then provide some genuine arguments to make your point other than you just
don't like them because.

Surely you must admit that some industrial control problems require more
compute power than a simple microcontroller can provide, and more like
what a Pentium-class processor can provide. So what do you do in such a
case? You could chose from any number of high end processors like the
Power PC, Pentium, ARM, etc, etc. Some of these will be better fits in
particular circumstances. For example, some variants of the Power PC are
particularly well suited for communication applications due to built in
hardware support, some ARM variants specialize in low power/MIP, etc. But
if you just need general compute power, most of these will do fine. You
could start with one of these processors, learn its interface details,
design your own RAM, flash, or disk subsystem, and debug everything
yourself. Sometimes that may be the right answer when volumes are high
and it's worth extra engineering effort and risk to get the tightest
possible fit.

However, for many such industrial applications the total processor system
is a small part of the overall cost, or time to market may be important.
In that case the make versus buy tradeoff leans more toward buy. That's
where the single board computers come in. Most of these use Pentiums and
mimic the PC architecure because it is general purpose and has the most
existing software and development environment support.

So Herbert, what specifically do you find at fault with this reasoning?

Definitely. Look what it takes today to run a wordprocessor that crashes
more often than WP under CP/M.

>Where are all the simple Operating Systems now?

In PICs, MCS51, Motorola, Hitachi, Rockwell, Mitsubishi, Thomson, Intel
and many other CPUs, which run most of our cars, airplanes, power
stations, washing machines, watches, cell phones, flight reservation
systems, databases, web servers, mail servers, you name it. All these
devices have two things in common: a) they work reliably most of the time
b) they do not contain M$ technology. I can see a pattern here.

Oh, by the way, all the mail servers that made your email to the piclist
possible run non-M$ software, maybe with the exception of your own server.
If you do not believe me, look at the headers. If you can, I mean. Because
some email software won't let you. It's better for you not to know that,
see.

This is a significant symptom for SCO going down with financial trouble.
No serious Linux user will pay any attention to it, no matter what the
outcome of their legal noise. You are quoting this out of context, since
you do not quote the response of the Linux people to this. No SCO IP is,
was or will be contained in any part of the Linux os or of its programs.
The people who wrote them made and make very sure of that all the time.
That is the point about Linux. Its GPL license systematically and
calculatedly, deliberately prevents companies and individuals from cashing
in on Linux IP by hijacking it, patenting it, or pretending it is theirs,
including as IP. Ever. That is the whole point of GPL, see ? Of course you
know that GNU stands for Gnu is not Unix ? This is not a joke (but it is
funny in the context of the SCO pretensions).

I agree that Pentium-class processors have their place in real-time
control, but one of the problems one might encounter (and this is true of
almost all very high end processors) is nondeterministic execution time.
Since you can set up timer interrupts when you need specific timing, it
often isn't an issue, but it can be if you are pushing the processor timing
to its limits and need to know how long a piece of code will take to execute.

Sean

At 12:51 PM 5/25/2003 -0400, you wrote:
> > it's [the Pentium's] architecture has to be "worked around" to be
> > used for real time control.
>
>That's blatant nonsense! What exactly about the Pentium architecture do
>you think makes it unsuitable for real time control? I think a Pentium
>can be very effective in that role, and I've used it that way with good
>success.

> heh. You haven't attended any of the microsoft talks about their
> support for "embedded systems", have you? It's pretty scary - it along
> the lines of "a windows XP box stipped down to run only a small set of
> applications on a limitted hardware configuration."

I have seen this sort of thing in action, pre-XP. We used some switches
which had controllers running embedded NT. Really nice when they worked;
they did things nothing else on the market did. Perfect fit for our
application. You had one to four switch chassis and up to two separate
controllers running in active/standby failover mode.

Even with a pair of them running in failover mode, the only way we could
ensure reliable operation was to forcce a failover and reboot the
controllers every 30 to 60 days. The vendor's plan to remedy this was to
rewrite the whole thing and convert the controllers to UNIX -- but they
didn't survive long enough.

I doubt things are that much better now. The OS is bad enough, but the
applications are typically so bug-ridden it's truly scary. My theory is
that you *COULD* probably get a bulletproof application running under
Windows, but by the time you successfully get function F written to run
reliably in Windows, you could have had functions F-Z doing fine under
some other OS. Just my opinion.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.

> Herbert Graf wrote:
> > I agree that SBCs are meant for those environments, I agree
> > that they ARE used for those environments, however I disagree that they
> > SHOULD be used for those environments.
>
> Then what environments do you think they should be used in, or do you
> think they shouldn't exist at all?

Areas where life and death isn't an issue. i.e. the hubble space telescope
uses a 386? I think, that's a perfect use since that DOES require alot of
computation and the odd error can be tolerated.

> > it's [the Pentium's] architecture has to be "worked around" to be
> > used for real time control.
>
> That's blatant nonsense! What exactly about the Pentium architecture do
> you think makes it unsuitable for real time control? I think a Pentium
> can be very effective in that role, and I've used it that way with good
> success.

One example? Ever try getting a PRECISE delay out of a Pentium? I wish you
luck, it's not fun. Latency is the main issue I'm talking about, with a PC
architecture it is VERY difficult to get accurate timing, unless you turn
off all the optimizations of course (in which case you still have to deal
with the instruction set being variable clock cycle, and you've ended up
with 386 performance...). The Pentium (and it's relatives) was never meant
for "real time control", it can be used for that, but the amount of effort
involved (and support components) would certainly make me reconsider. I
guess I'm the only one that thinks this way, so be it.

No, and I guess I never will. I also never got a Pentium to read an
analog signal or handle a datacommunication stream, or even execute a
program, without supporting silicon. In a P system the P is the CPU, not
the computer. When you want precise timing on a PIC you can do so using
the CPU alone, but in most cases you will use a timer. Likewise in a P
system. Which of course rules it out for cost-sensitive applications (if
only for the PCB area required).

> > "A quiche eater programs in assembler while a real programmer uses
> > binary and writes his program directly into the computer core using the
> > front panel switches."
>
> I hadn't heard the "quiche eater" term before, but shouldn't your quiche
> eaters be restricted to writing MFC apps in Super Turbo Visual Basic++
> with self-debugging GUI where all new code is just combining templates
> that Must Not be Questioned provided by the software gods from the great
> temple in Redmond?
>

Nah, when the term "quiche eater" was common it was generally used by
assembler programmers having a dig at C and PASCAL programmers.

Please don't get me started on the topic of modern day "quiche eaters v real
programmers". Several years ago I worked with a guy that had two years
experience writing C. He didn't know the difference between & and &&

I often use PC-compatible hardware (either real PC's or some sort of
embedded flavor) for embedded projects. I use Microsoft Visual C++ to build
the application. The run-time environment is a Win32 subset that I developed
myself. A DOS program loads the run-time environment and application into
memory (often from flash drives) and then passes control to the run-time's
initialization entry point. From that point on the program runs in 32-bit
flat model, without paging. This has turned out to be an extremely stable
system.

I'm talking about the PC. Would YOU trust a PC in running say, an
elevator? I know I wouldn't, it's way to unstable for that sort of
environment. While some SBCs ARE used in an industrial environment I
see little reason other than laziness for there use.

I see. You'd rather trust some piece of non-industry-standard hardware
built by some flakey business that might be gone tomorrow (and shallow
pockets), with software written by some long-haired weirdo, than a piece of
industry standard hardware running software with millions of cpu-hourse of
run-time experience from the worlds largest software company (controlling
at least all the "critical functions."?)

>I'm talking about the PC. Would YOU trust a PC in running say, an
>elevator? I know I wouldn't, it's way to unstable for that sort
>of
>environment. While some SBCs ARE used in an industrial environment
>I
>see little reason other than laziness for there use.
>
>I see. You'd rather trust some piece of non-industry-standard
>hardware
>built by some flakey business that might be gone tomorrow (and
>shallow
>pockets), with software written by some long-haired weirdo, than a
>piece of
>industry standard hardware running software with millions of cpu-
>hourse of
>run-time experience from the worlds largest software company
>(controlling
>at least all the "critical functions."?)
>
>:-) :-) :-) :-)
>
>BillW
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email .....listservRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

one of the problems one might encounter (and this is true of
almost all very high end processors) is nondeterministic
execution time. Since you can set up timer interrupts when you
need specific timing, it often isn't an issue, but it can be if
you are pushing the processor timing to its limits and need to
know how long a piece of code will take to execute.

IMO, determinism is overrated (or we'd all be using token ring network.)
Part of the POINT of using a pentium class processor is that if you have a
3GHz processor, you don't NEED to "push the processor timing to its
limits." You have to go to some lengths to justify spending thousands of
dollars of programmer time doing that "pushing" when the faster processor
is comparitively cheap.

> I hadn't heard the "quiche eater" term before, but shouldn't your quiche
> eaters be restricted to writing MFC apps in Super Turbo Visual Basic++
> with self-debugging GUI where all new code is just combining templates
> that Must Not be Questioned provided by the software gods from the great
> temple in Redmond?
>

Nah, when the term "quiche eater" was common it was generally used by
assembler programmers having a dig at C and PASCAL programmers.

When I first heard it, I think it was primarilly directed against all
those unix weenies writing shell scripts, by the C programmers.

It all depends on who you want to insult, and who you want to compliment :-)

Probably you can use the 80/20 rule. Pick a dividing line so that only
20% of the people qualify as non quiche-eaters. Or 10% Or 1%.

Unfortunately, one finds very often that the people in the top 10% of
writing efficient code and understanding your favorite language are not
the same as the top 10% of people who understand the problem that the
program is supposed to solve...

I suppose that is true for high end apps, but if all you want to do is
pulse some pins with microsecond timing accuracy, it will almost certainly
be cheaper to use a PIC than a nondeterministic processor that is fast
enough to guarantee that it will never take too long. In a lot of projects
that I do, I find myself using a bunch of PICs or other cheap
microcontrollers that each do some small function and then communicate with
each other. It would be considerably harder to do all that on one fast
processor and make sure that it all coexists properly in the software.

> one of the problems one might encounter (and this is true of
> almost all very high end processors) is nondeterministic
> execution time. Since you can set up timer interrupts when you
> need specific timing, it often isn't an issue, but it can be if
> you are pushing the processor timing to its limits and need to
> know how long a piece of code will take to execute.
>
>IMO, determinism is overrated (or we'd all be using token ring network.)
>Part of the POINT of using a pentium class processor is that if you have a
>3GHz processor, you don't NEED to "push the processor timing to its
>limits." You have to go to some lengths to justify spending thousands of
>dollars of programmer time doing that "pushing" when the faster processor
>is comparitively cheap.
>
>BillW
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email spamBeGonelistserv@spam@mitvma.mit.edu with SET PICList DIGEST in the body

>
>Unfortunately, one finds very often that the people in the top 10% of
>writing efficient code and understanding your favorite language are not
>the same as the top 10% of people who understand the problem that the
>program is supposed to solve...

The thread is about future tendencies, not about reviving
antique equipment. Future engines with a single board
computers look very naturally.
Regarding " Problem solved" phrase at the end of your
message: I'm not absolutely sure it was. Have you run all
needed tests at all conditions?
And the idea itself of "just threshold" seems to be
highly suspicious. Better way is to send absolute (not
threshold exceeding) data on a daily or weekly basis, for
example. Sending should be done in a reliable manner
(redundancy, acknowledgement etc.)
I bet, a diesel guy will try to pay the "threshold
installing" guy for setting higher threshold and teaching
him how to store lower threshold level when engine crashed.
(get some AC signal near to the tachometer and press the
button).

By the way, an article in Embedded.com
(DOS & Turbo Pascal will do the job?)
-----------------------------------------------
33MHz SBC comes in under $70

The Flashlite 186 is a programmable single-board computer targeting data
acquisition, industrial control, and communications applications. Built
around a 33MHz 186 compatible processor, the Flashlite 186 controller
offers users 44 configurable digital I/O lines, 512KB DRAM, 512KB flash,
two serial ports, and a console/debug port. Additional features include
an onboard 7V to 34V DC voltage regulator, two 16-bit timers, a watchdog
timer, and a socket to expand non-volatile memory by means of M-Systems'
DiskOnChip. The Flashlite 186 supports the addition of LCDs, keypads,
12-bit A/D channels, relay outputs, optically isolated inputs or high
current drivers. A preloaded, royalty-free DOS and a flash file system
provide an environment for embedded development.
The Flashlite 186 is available now for $69 (Qty 1).

*****************************************
Bob Ammerman wrote:
I often use PC-compatible hardware (either real PC's or some sort of
embedded flavor) for embedded projects. I use Microsoft Visual C++ to
build the application. The run-time environment is a Win32 subset that I
developed myself. A DOS program loads the run-time environment and
application into memory (often from flash drives) and then passes
control to the run-time's initialization entry point. From that point on
the program runs in 32-bit flat model, without paging. This has turned
out to be an extremely stable system.
*****************************************

*****************************************
Olin Lathrop wrote:

Here's a genuine real world example. About two weeks ago a customer had
a gizmo that had a digital input for when a diesel engine was on, and
when it was being abused by being run too fast. Among other things,
this gizmo sends a message to a central office via satellite when
certain events occur, like the engine being abused.

The problem was that this now needed to be hooked up to an engine that
didn't provide these outputs. The only thing available was a tachometer
signal generated by a magnitized coil in close proximity to teeth on the
flywheel. This is an AC analog signal that produces 127 cycles per
engine revolution. The amplitude is anywhere from a few 100mV to tens
of volts p-p. The job was to design and build two prototype quick and
dirty converters from the tachometer signal to the existing digital
inputs. They don't want the engine abused signal asserted until the
engine has been over the speed limit continuously for 5 seconds. They
don't want a satellite message for every short vrooom of the gas pedal,
just for sustained excessive speed. The exact engine speed theshold
isn't known. The unit will somehow have to be adjusted when installed.
And of course, these two prototype units need to be their hands
yesterday. +12V, +5V, and ground are available. Each unit needs to
have two channels (two tach in signals, two sets of engine on and abused
output signals).

I did this with an LM324 front end to convert the tach signal into a
nice 0-5V digital signal using a little filtering and hysterisis. Then
I programmed a 12F629 to run with its internal 4MHz oscillator and
compute the period between tach pulses, then filter that a little to
make a reasonably solid 16 bit value internally. A momentary pushbutton
was tied between ground and a PIC pin with passive pullup. The current
tach period becomes the high/low speed threshold when pressed. At
installation time, you run the engine at wherever you want the speed
threshold to be, then press the button. This value gets saved in
EEPROM, so it doesn't get lost on power down. Two pins drive the two
inputs of the original gizmo. I also added two LEDs driven from PIC
pins with resistors to +5V. One lit when the engine was considered on
(tach period didn't overflow the 16 bit internal value), and the other
lit when the instantaneous speed was over the threshold. The LEDs are
only for the field installers. The whole unit will be in a sealed box
and never seen by the end user. For two channels I simply used two
12F629, and still had two unused opamps left of the four in the LM324.
A technician built 2 of these simple circuits on two small pieces of
perfboard. Problem solved.

Actually Hubble uses 486's I believe and the reason they do use them is
primarily because they are one of the few processors that have enough CPU
power with a large enough feature size (25um? 30?) that a single solar
proton wont blast the track away. (as in cut the tracks in the CPU itself).
when you are talking space and micro controllers the primary concern is
radiation hardness, ECC ram, and multiple simultaneous calculation and
verification. the ram needs to have full error correction as single bit
flips due to a solar proton or electron energising a gate are actually
fairly common. this can happen in ram banks and in processor registers. To
overcome this generally you have 3 identical "processing systems" that do
the same calculation and then compare with each other to look for errors.
As far as I'm aware there arent any PIC's or other micro's that can do that.
(btw voyager used 8(?) power PC chips (without the ability to multiply or
divide in hardware to run its systems))

> ... The Pentium (and it's relatives) was never
> meant for "real time control", it can be used
> for that, but the amount of effort involved
> (and support components) would certainly make
> me reconsider.

About "real-time" things.

From http://www.microsoft.com/windows/embedded/docs
-----------------------------
Designed from the ground up for the embedded marketplace, Windows CE
.NET delivers a robust real-time OS for rapidly building the next
generation of smart mobile and small footprint devices.
-----------------------------

Herbert Graf wrote:
> Ever try getting a PRECISE delay out of a Pentium?
> I wish you luck, it's not fun. Latency is the main
> issue I'm talking about, with a PC architecture it
> is VERY difficult to get accurate timing...

Herbert Graf wrote earlier:
> You mention industrial designs: sorry, no industrial
> design is going to TRUST a "PC" architecture, it is
> not designed for that environment (both from a
> physical standpoint and a functional standpoint).
> That said, please try and stay on topic, we are
> discussing how the Xilinx product you mention is in
> a completely different class from PICs.

Well, trying and staying on Xilinx topic...
Any problem getting a PRECISE delay out of Xilinx?

Peter L. Peres wrote:
> >Where are all the simple Operating Systems now?
>
> In PICs, MCS51, Motorola, Hitachi, Rockwell, Mitsubishi,
> Thomson, Intel and many other CPUs, which run most of
> our cars, airplanes, power stations, washing machines,
> watches, cell phones, flight reservation systems,
> databases, web servers, mail servers, you name it. All
> these devices have two things in common: a) they work
> reliably most of the time b) they do not contain M$
> technology. I can see a pattern here.
>
> Oh, by the way, all the mail servers that made your
> email to the piclist possible run non-M$ software,
> maybe with the exception of your own server. If you do
> not believe me, look at the headers. If you can, I mean.
> Because some email software won't let you. It's better
> for you not to know that, see.

Hi, Peter.
What should I do in order not to be misunderstood by
you anymore? I didn't try to advocate MS.

By the way, can't say for washing machines and watches,
but I heard a rumor that databases and web servers
sometimes have MS guts :-)
And this phrase about non-M$ stuff: "a) they work
reliably most of the time" just for being non-M$.
Plato, Aristotel are cool guys, but truth ...

> Herbert Graf wrote:
> > Ever try getting a PRECISE delay out of a Pentium?
> > I wish you luck, it's not fun. Latency is the main
> > issue I'm talking about, with a PC architecture it
> > is VERY difficult to get accurate timing...
>
> Herbert Graf wrote earlier:
> > You mention industrial designs: sorry, no industrial
> > design is going to TRUST a "PC" architecture, it is
> > not designed for that environment (both from a
> > physical standpoint and a functional standpoint).
> > That said, please try and stay on topic, we are
> > discussing how the Xilinx product you mention is in
> > a completely different class from PICs.
>
> Well, trying and staying on Xilinx topic...
> Any problem getting a PRECISE delay out of Xilinx?

Not really, why do you ask? Since it's just an FPGA precise delays are
limited by routing, but since that's known before hand it can be accounted
for (except for thermal variation), what are you trying to get at?

Herbert Graf wrote:
> One example? Ever try getting a PRECISE delay out of a Pentium?

No, of course not. That would be a misuse of the tool. The Pentium like
just about all high end processors can not guarantee exact instruction
timing. However, even with PICs that is certainly not the first choice
method except in specialized cases or very short delays. The vast
majority of my PIC projects don't contain any code that uses the number of
instructions executed for accurate timing. OK, so you can't do that with
a Pentium, just like all other processors of its class I can think of.
Basically, that's a feature you give up for higher CPU performance. On
the flip side, the Pentium does have up to 256 separate interrupt vectors
and is much faster. This makes it easier to do accurate timing the right
way.

>Crashed Computer Traps Thai Politician, 14 May 2003
>http://aardvark.co.nz/daily/2003/n051301.shtml
>
>Thailand's Finance Minister had to be rescued from inside his BMW
>limousine after the onboard computer crashed. Door locks and power
>windows were inoperative, leaving the Minister and his driver
>trapped. They got a nearby guard to free them by smashing a window.
>
>BMW's more up-market 7-series range uses a computer system called
>i-drive which has Microsoft's WindowsCE at its core.
>http://www.microsoft.com/presspass/press/2002/Mar02/03-04BMWpr.asp

Yes. WS or Wordstar ran/runs on CP/M and MS-DOS (and a short lived Windows
version), and was published by Wordstar International. WP or WordPerfect
ran/runs on MS-DOS & Windows (and a few other OS) and was published by
WordPerfect Corporation.

I've got a microblaze dev system sitting here. Will I use it instead of a
PIC? No...because as many have said, it really doesnt fit the same
applications. Although, they will be releasing or already have released a
picoblaze where it will fit in smaller FPGA and CPLD's.

As mentioned, many of the PIC's have built in hardware functions that you
would end up doing in software, or buying cores, or using something from
opencores.org, to do the same thing. You can't do A/D in the xilinx or
altera parts. Doing a UART is all in software...not that it can't be done
because it is done everyday but its the convience of the stuff......

I think that Microblaze was intended to compete more with the Altera NEOS
processor.

But just as TI and Mot bring out new chips...does everyone flock to use them
instead of PICS? No....well, perhaps depending on the applications. I'll
use a PIC for a controller over a FPGA because its better suited for it.
Doing state machines in verilog isn't the most enjoyable thing to do, but I
have done it because also I had large FIFO's that are EASY to do in HDL.

> And this phrase about non-M$ stuff: "a) they work
>reliably most of the time" just for being non-M$.
> Plato, Aristotel are cool guys, but truth ...

No connection with philosophy, just statistics. Count the number of times
your elevator or car breaks down wrt the number of times you need to
reboot the computer. M$ requires a Schopenhauerian approach, Plato or
Aristotel would crash it too easily by reducing it to absurdity or similar
;-) ;-) Your life is whatever you believe it to be, never mind the
stoopid facts. You can always ignore them if you do not like them, or
explain them away somehow, as long as you believe the explanation it's ok.
Relax. Relax. Breathe deeply ...

About buggiest..
I only recieve
"The specified request cannot be executed from current Application Pool"
Tried Opera, Mozilla, MSIE

Anyway, the best realtime system i think would be to integrate time critical routines in a way that they catch interrupts and take care of time critical things, without relying on some more or less known kernel.

Like integrating realtime routines in the kernel. Of, course then we need a well documented and configurable kernel, a plus if it is well known, supported, and future safe. Like Linux.

There already are versions like this, that allows you to run your code as highest priority, yet you have a full modern OS to back your app, with advanced filesystems, network, graphics, whatever.