HDTenEightyP/NetNews huggingface dataset:
From: sb@next.neuro.emory.edu (Stephen O. Berger)
Newsgroups: comp.realtime
Subject: Re: uCOS
Date: 23 Dec 1992 19:25:55 GMT
Organization: Emory University, Dept of Math and CS
Reply-To: sb@next.neuro.emory.edu
NNTP-Posting-Host: next.neuro.emory.edu

In article <2822@bigfoot.first.gmd.de> gt@prosun.first.gmd.de (Gerd  
Truschinski) writes:
> In article <1gh30pINN4pp@myall.awadi.com.au>, dick@vsl.com.au (Richard  
Sellar) writes:
> |> I have a copy of the uCOS real-time kernel written by Jean J.  
Labrosse but do not have access to the documentation published in the May  
1992 and June 1992 issues of Embedded Systems Programming Magazine.
> |> 
> |> I am trying to obtain these issues of the magazine but in the mean  
time would anybody having an electronic copy of those articles kindly  
e-mail them to me.
> 
> 
> 
> Me too, please.
> 
> Thanx, /gT/
> 
> --
> Gerd Truschinski         | INTERNET:    gt@first.gmd.de
> c/o GMD-First  Berlin    | 
> O-1199 Berlin-Adlershof  | TEL:         +49 30 6704 2662
> Rudower Chausee 5 (13.7) | FAX:         +49 30 6704 5088

  You can get a reprint of the article from University Microfilms
International at 313-761-4700.


Steve Berger (sb@onripx.neuro.emory.edu)
Xref: sparky comp.realtime:1473 comp.os.misc:981
From: kent@swrinde.nde.swri.edu (Kent D. Polk)
Newsgroups: comp.realtime,comp.os.misc
Subject: Re: Real-time OS for PC's
Date: 22 Dec 1992 15:24:05 GMT
Organization: Southwest Research Institute, San Antonio, Texas
NNTP-Posting-Host: swrinde.nde.swri.edu

In article <92356.214536CCVQC@CUNYVM.BITNET> Christopher Vickery <CCVQC@CUNYVM.BITNET> writes:
>I'm curious about the two people who have had problems with Intel
>development tools.  I've been teaching courses using iRMX at
>Queens College since 1984.  The only change/inconsistency that I
>to the present one, an ANSI C compiler that, I was told by someone
>at Intel, was based on their own PLM compiler.  There have been

I used Intel's development tools, including RMX (after it came out) from
somewhere around '79 to about '88. We never bothered to get the C compiler as
we had quit using Intel for new systems around '85 and were just supporting
existing ones after that.

As to tools, ISIS II, the PLM and Fortran compilers we used were the most
stable tools in the lot (luckily). The debuggers, ROM burners, ICE and RMX
for the different platforms, etc. were the tools that were incredibly
frustrating as versions for different processors hardly looked like they came
from the same company. And then there was the time I had to make mods in a
96k ROM product after we had updated the OS. The new romburner software
couldn't burn the ROMs anymore since it couldn't handle offsets higher than
64k and I couldn't run the old rom burner software on the new OS and we had
to keep to new OS for a new product we were working on. I ended up reading
the old roms into memory and hand-patching the blasted changes in hex. Took
me about three days once I figured out what the problem was.  That was the
straw that broke my back.

We moved over to HPUX and their Motorola cross development system after that
and never regretted it one bit. I pretty much chunked the Intel systems we
had except for an ancient 8080, floppy-based system that I hooked to our HPUX
system. We would do all development on unix and download to the DS to compile
and burn roms for the Intel imbedded control products that we were still
supporting.

iRMX, etc. may have gotten a little better after we quit using it, and in
1979, Intel had one heck of a system, but Things Move On and I'm just glad I
did.

Kent Polk: Southwest Research Institute
Internet : kent@swrinde.nde.swri.edu
Newsgroups: comp.realtime
From: gee@dciem.dciem.dnd.ca (Thomas Gee)
Newsgroups: comp.realtime,comp.unix.ultrix,comp.sys.m68k
Subject: Re: SUMMARY: Is there a pSOS Emulator for Unix?
Summary: MTI makes a simulator
Keywords: psos,real,time,unix,emulator
Date: 22 Dec 92 13:58:47 GMT
Followup-To: comp.realtime
Organization: Defence and Civil Institute of Environmental Medicine

In article <1992Dec17.105337.8378@lmpsbbs.comm.mot.com> solomon@becks.comm.mot.com (James Solomon) writes:
>
>My original post:
>
>>Does anyone know of a software emulator for pSOS that runs as a user process
>>under Unix, more specifically under Ultrix?  Please respond via Email and I'll
>>summarize if there's enough interest.

Hmm, my apologies.  I didn't see this original posting.

>The situation, unfortunately, is not very pretty.  Here is the relevant
>information:
>
>1)  Integrated Systems Inc. (ISI), the makers of pSOS, does *not* offer a pSOS
>    emulator for Unix.

However, a Canadian company called Multiprocessor Toolsmiths does make a pSOS+
emulator.  We are using their development environment Caseworks/RT, and part of
the development suite is a system called Copycat which "is basically a port
of pSOS+/Unison to your host workstation" (Unison is their Unix-like wrapper
around pSOS+).

Our version of Copycat runs on SPARC.  I am not aware of which other platforms
are supported.

Their address:	Multiprocessor Toolsmiths Inc.
		200-6 Gurdwara Drive
		Nepean, Ontario, Canada
		K2E 8A3
		
		Phone: (613) 727-8707
		Fax:   (613) 727-3570

>Jim Solomon (solomon@comm.mot.com)
>Disclaimer:  It's my fault, not Motorola's.

Tom
---
Thomas Gee  -=-  S/W Development  -=-   gee@dretor.dciem.dnd.ca
Aerospace/Biosciences, DCIEM, CFB Toronto, DND, Canada
Disclaimer: the previous is solely the opinion of the author.
Newsgroups: comp.realtime
From: roland@quadsys.com (Roland Besserer)
Subject: Re: Real_time systems
Organization: QUAD Systems
X-Newsreader: Tin 1.1 PL3
Date: Mon, 28 Dec 1992 01:08:25 GMT

andrew@megadata.mega.oz.au (Andrew McRae) writes:
: The complexity of these systems is mostly (I say again, *mostly*,
: not *always*) unwarranted and often add to the overall cost
: of the system (in terms of memory, CPU, software cost etc.)
: In the truly embedded world, it is often better to simplify
: the OS and make the processes/tasks running under it `co-operative',
: so that timing contracts are met.
: 
: .... (deleted)
:
: I have come to the conclusion that preemption is to be
: avoided *if at all possible*, since it carries a lot of
: baggage with it. But having said all that, it certainly
: has its place outside of the hard real time world, especially
: in systems that require some aspects of real time behaviour, such
: as responding quickly to user input, yet sharing CPU resources
: fairly amongst competing processes, where some processes are considered
: higher priority (e.g the X server responding to mouse/keyboard events,
: yet while processing large bit images). Threads will help a lot.
: 
One of the best postings on the subject. Although I agree with your 
statements and conclusions I think it's worthwhile pointing out the
cooperative task approach is only really suitable in fairly simple
real-time designs. Increasingly complex and particularly highly dynamic
designs, requiring constant code/task modification, are typically better
coded using a flexible real-time kernel that employs pre-emption,
scheduling, priorities, etc.

Yes, you will pay a price: overall performance penalties, increase in
basic resource requirments, increased software costs, etc. But complex designs
are much easier to maintain in such an environment and software coding and
maintanability become primary concerns.
-- 

Roland Besserer
QUAD Systems
roland@quadsys.com
From: nickgill@doc.bmd.trw.com
Newsgroups: comp.realtime
Subject: DOS in real-time, any problems?
Date: 20 Dec 92 16:05:59 MST

Hello,
 
I am looking for any information on DOS in a real-time enviroment.
Please-mail me if you know of any leads on problems that occured
in a real-time environment or on embedded computers as a result of DOS.
Thanks,

Nick

P.S.
Also, if you know where I may obtain info on Motrola 68000 vs Intel 80086
for real-time applications.
From: clayton@master.lds-az.loral.com (Tom Clayton)
Newsgroups: comp.realtime
Subject: Discussions on VMEbus?
Date: 21 Dec 92 22:57:52 GMT
Organization: Loral Defense Systems

Could someone steer me to the appropriate newsgroup for discussion of
topics relating to VMEbus or Futurebus+?

Thanks much,
Tom
Newsgroups: comp.realtime
From: dphelps@cbnewsf.cb.att.com (david.j.phelps)
Subject: Micro controllers
Organization: AT&T
Date: Mon, 21 Dec 1992 12:15:54 GMT


Hello all,

I don't know if this is the right place to post this, but here
goes. I am studying for a degree in Real-time computing in England
and I am looking at the subject of Micro controllers as a project. If
anyone has had any experience of micro controllers, could you please
answer the questions below ? I would be very grateful.

1. Which micro controllers have you used ?


2. Which micro controller do you prefer and why ?


3. Which do you find easiest to program/interface ?


4. Have you had any problems with a specific micro controller ?


5. Have you had satisfactory technical support ?


6. Do you find that software is easily available for your chosen
   micro controller ?


Thanks to anyone who can help. Could you please send your responses
to my mail address ? Thanks.


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

Dave Phelps (Cheltenham & Gloucester College of Higher Education, England)

daphelps@mlsma.att.com
Newsgroups: comp.realtime
From: ri@nacsis.ac.jp (Ri Soutetsu (ASANO LAB))
Subject: tasks precedence
Organization: University of Tokyo, Japan.
Distribution: comp
Date: Fri, 25 Dec 1992 08:36:50 GMT

Hello, I am a beginner of real-time scheduling.

I have a question.

Is it important to deal with task precedence in scheduling real-time
tasks?

	Thanks in advance.

--
-----------------------------------------------------
 Sotetsu Ri

 University of Tokyo, Japan.
 E-Mail ri@nacsis.ac.jp
From: kboland@research.egr.duke.edu (V. K. (Keith) Boland)
Newsgroups: comp.realtime
Subject: Wanted: 1992 Real-Time Systems Symposium proceedings
Date: 28 Dec 92 19:12:27 GMT
Organization: Duke University EE Dept.; Durham, NC

Does anyone know how I could purchase an advance a copy of 
the 1992 IEEE Real-Time Systems Symposium proceedings
(usually held in early December)?   Our library will not 
get a copy until the April/May time-frame and I would like 
to be able to see them before then.

Thanks in Advance,

- Keith Boland
  kboland@egr.duke.edu
Newsgroups: comp.realtime
From: enertec@netcom.com (The Gang at Enertec)
Subject: real-time X/Motif data display user interface tool
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 23 Dec 1992 15:18:28 GMT



We are looking for a Unix / X / Motif product for the 486 platform
that provides a GUI interface for the definition and display of real time
data, including the ability to produce "trend" displays for the data.

Products that we have looked at include: FactoryLink from US DATA (under SCO)
and GE Cimplitity (under ISC).  Both of these products contain the ability to
draw graphical displays, then attach real-time data elements to those displays
in order change the color, size or values shown on those displays at run-time.

We are looking for a product that will do these things, PLUS provide us the
ability to build X/Motif applications (ala ISC's BuilderXcessory or UIM/X)
that will interact with the user and have the same look-and-feel as the windows
produced by the display generation tool.

If anyone has seen others products on the market that provide this or similar
capability, please drop us a line.  We'll post a summary of responses if anyone
else is interested.

Thanx in advance,

John Feras

enertec@netcom.com


-- 
enertec@netcom.COM
Netcom - Online Communication Services San Jose, CA
From: nickgill@doc.bmd.trw.com
Newsgroups: comp.realtime
Subject: What's wrong with DOS in real-time?
Date: 24 Dec 92 10:51:51 MST

I have read EDN's 26Nov92 Special Report: 43 chips on file.
Can anyone tell me why the 8086 Intel chip is not as good
as a 68000 Motorola chip as an imbedded computer in real-time
applications? 
Note: The 8086 uses DOS and the 68000 uses a real-time
kernal.
Thanks,
Nick
Xref: sparky comp.realtime:1468 comp.os.misc:979
Newsgroups: comp.realtime,comp.os.misc
Subject: Re: Real-time OS for PC's
From: Christopher Vickery <CCVQC@CUNYVM.BITNET>
Date: Monday, 21 Dec 1992 21:45:36 EST
Organization: City University of New York/ University Computer Center

I'm curious about the two people who have had problems with Intel
development tools.  I've been teaching courses using iRMX at
Queens College since 1984.  The only change/inconsistency that I
have been aware of was a change from the Mark Williams C compiler
to the present one, an ANSI C compiler that, I was told by someone
at Intel, was based on their own PLM compiler.  There have been
bugs in their development tools, but my experience is that they
fix the bugs and the tools are reliable.  I've certainly never
seen inconsistencies from version to version -- except when going
from the "traditional" C compiler by Mark Williams, which never
was reliable enough to work with in my opinion, to the current
ANSI C compiler, which has finally made me give up PLM for good.
-------
Christopher Vickery, Computer Science Department, Queens College (CUNY)
Flushing, NY 11367-0904  vickery@ipc1.cs.qc.edu (718)997-3500
Newsgroups: comp.realtime
From: paulo@ohmeda.com (Paul E. Ourada)
Subject: Re: real-time X/Motif data display user interface tool
Organization: Ohmeda Monitoring Systems
Date: Tue, 29 Dec 1992 21:17:57 GMT

enertec@netcom.com (The Gang at Enertec) writes:

>As a postscript to our search, the following vendors have been reported to
>supply products that provide the required functionality:

>V.I Corp - DataViews: DVDraw, DVPlay, and DVTools.
>(413)-586-4144 or email vi@vicorp.com

[stuff deleted]

I must reply that we have in-house the above mentioned product.  I 
recommend highly that one gets a liberal demo license and verify that
this product will do what you want with the ease that you require.

We intended to use this product as a prototyping tool, and we have
discovered that in order to get it to do some relatively simple things
we have had to expend considerable effort.  It was not all that useful
for prototyping.  We were running it on a Sun IPX with graphics accelerator
and it was still too slow.  So, I don't know what the original realtime
requirements were, but it was too slow to handle block moves at 30 samples
per second or there abouts.

Regards,

Paul Ourada
Ohmeda Monitoring Systems
paulo@ohmeda.com
From: michael@chg.mcd.mot.com (Michael Bodine)
Newsgroups: comp.realtime
Subject: Re: Discussions on VMEbus?
Date: 22 Dec 92 14:57:09 GMT
Organization: Motorola Computer Group, Schaumburg, IL

clayton@master.lds-az.loral.com (Tom Clayton) writes:
>Could someone steer me to the appropriate newsgroup for discussion of
>topics relating to VMEbus or Futurebus+?
That would be comp.arch.bus.vmebus.
-- 
[  Michael Bodine, michael@chg.mcd.mot.com, Dial: (708) 576-7840, FAX: x8875  ]
[  Motorola TSD; Loc IL38; 1100 Woodfield; Suite 334;  Schaumburg, Il  60173  ]
Newsgroups: comp.realtime,comp.os.misc
From: beaudoin@ireq-robot.hydro.qc.ca (Martin Beaudoin)
Subject: Re: Real-time OS for PC's
Organization: Le laboratoire de robotique de l'Institut de recherche
	d'Hydro-Quebec
	<92352.130927CCVQC@CUNYVM.BITNET><id.VHYV.TDF@ferranti.com>
	<1h4o70INNea7@swrinde.nde.swri.edu> <92356.214536CCVQC@CUNYVM.BITNET>
Date: Sun, 3 Jan 1993 02:33:04 GMT

In article <92356.214536CCVQC@CUNYVM.BITNET> Christopher Vickery <CCVQC@CUNYVM.BITNET> writes:

   I'm curious about the two people who have had problems with Intel
   development tools.  I've been teaching courses using iRMX at
   Queens College since 1984.  The only change/inconsistency that I
   have been aware of was a change from the Mark Williams C compiler
   to the present one, an ANSI C compiler that, I was told by someone
   at Intel, was based on their own PLM compiler.  There have been
   bugs in their development tools, but my experience is that they
   fix the bugs and the tools are reliable.  I've certainly never
   seen inconsistencies from version to version -- except when going
   from the "traditional" C compiler by Mark Williams, which never
   was reliable enough to work with in my opinion, to the current
   ANSI C compiler, which has finally made me give up PLM for good.
   -------
   Christopher Vickery, Computer Science Department, Queens College (CUNY)
   Flushing, NY 11367-0904  vickery@ipc1.cs.qc.edu (718)997-3500

Same here. I've been using iRMXII, iRMXIII and iRMXIII/DOS since 1990,
and the tools are indeed quite reliable. iRMX lacks some software
developpement tools, as provided by good Unix platforms, but porting
the lacking tools to iRMX is quite feasible (as I did for tar, make
and diff...) .  

Intel decided not to port its Pascal compiler to the 32 bits
environnement, like it did with ASM386, IC386 and PLM386. But you can
still use the 16 bits compilers like pas286 and ic286 with iRMXIII and
iRMXIII for Windows, so it's not so bad...

The code that was working on iRMXII was ported to iRMXIII and later to 
iRMXIII/DOS without any problems. I'm looking forward to install the
latest version of iRMX for Windows real soon (TCP/IP support...).
 
Intel also provided me with a pretty good and fast on-line support. I
recommend iRMX for anyone serious enough and open enough to take the
iRMX plunge.

--
Martin Beaudoin                         mbeaudoin@ireq-robot.hydro.qc.ca
Institut de recherche d'Hydro-Quebec    Tel: +1 514 652-8136
Varennes, QC, Canada   J3X 1S1          Fax: +1 514 652-8435
Newsgroups: comp.realtime
From: quandt@mcs213c.cs.umr.edu (Brian Quandt)
Subject: Lynx and Chorus
Date: Thu, 31 Dec 1992 18:10:31 GMT
Organization: University of Missouri - Rolla


We are still looking for a real time OS for a 386/486 platform.  
Currenlty we have been evaluating Lynx/OS and have found it 
to be the best of ones we have looked at so far.  However, it 
can be (and frankly is) a pain!  Many of their tools such as
compilers, linkers, etc are old and really need to be updated.  We
dont understand why they don't upgrade this stuff to more current
software when most of the stuff is already public domain (mostly
GNU stuff).  Here's a typical problem we have experienced with Lynx:
	We would like to use the large amount of PD software out there
	so we download it from the nets and then try to compile.  On
	average less then 5% of the stuff we try will compile without
	major screwing around.  Short list of failures: xf, tk, and even
	tcl would not compile.

So Anyways, does anyone know anything about Chourus?  I have heard
they are trying to become a part of SCO (or extension or whatever).
My big fear is that SCO is sys 5 and Chorus is berkely 4.3.  All I hope 
is that the product that may result from SCO and Chorus is 4.3 becuase
I sure as heck don't want to take a step backwards to sysV.k




Newsgroups: comp.realtime
From: kent@swrinde.nde.swri.edu (Kent D. Polk)
Newsgroups: comp.realtime,comp.os.misc
Subject: Re: Real-time OS for PC's
Date: 21 Dec 1992 15:34:56 GMT
Organization: Southwest Research Institute, San Antonio, Texas
NNTP-Posting-Host: swrinde.nde.swri.edu

In article <id.VHYV.TDF@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <92352.130927CCVQC@CUNYVM.BITNET> Christopher Vickery <CCVQC@CUNYVM.BITNET> writes:
>> One real time OS that is available for the PC is iRMX for Windows from
>> Intel.
>
>Beware. We have been using RMX for some years and Intel has a real bad habit
>of abandoning development environments. They sold us on a nice line of Intel

Not only that, but every time there was an upgrade to the development tools
that were 'supported' (for a time) or if you purchased tools for a different
processor, it appeared that they were always done by a completely different
development group.  There appeared to be very little consistancy of operation
between them. Products created with one version often could not be recreated
without much difficulty using the 'update'. This was extremely annoying and
led to finally dropping the use of Intel products by the company I was
working for at the time.

Kent Polk: Southwest Research Institute
Internet : kent@swrinde.nde.swri.edu
Xref: sparky comp.realtime:1471 comp.os.misc:980
From: mac@coos.dartmouth.edu (Milton A. Colvin)
Newsgroups: comp.realtime,comp.os.misc
Subject: Re: Real-time OS for PC's
Date: 22 Dec 92 13:18:25 GMT
Organization: Dartmouth College, Hanover, NH

My experience with iRMX was that the current release of the network
software iNA960 was never compatible with a current release of the OS.
Upgrades opften involved hardware modifications. Installation always
required a site visit by an engineer.

Of course, this was 8 years ago. C wasn't even available.

Intel isn't a systems company.
Newsgroups: comp.realtime
From: toseyb@fraser.sfu.ca (Joseph Robert Tosey)
Subject: Re: Real_time systems
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 28 Dec 1992 18:50:35 GMT

: I have come to the conclusion that preemption is to be
: avoided *if at all possible*, since it carries a lot of
: baggage with it.

I've worked with two proprietary RT OS's, and one which is a hybrid
(half proprietary, that is).  I agree--even for very complex systems,
preemption is undesirable but unavoidable.  We use an unconventional
system to minimize preemption, which I'll summarize below since
there is such interest in this area.

We allow (encourage) engineers to create tasks for our application
whenever such makes for a clean design.  As a result, we are currently
running about 500,000 lines of code and 100 - 1000 real time tasks on
a 68030.  Quite simply, we partition the tasks into priorties,
create a single task for each priority (mostly, anyway) and run a loop as
described previously within this task.  Thus hundreds of tasks fold into a
few more than half a dozen 'real' preemptive tasks.

The effect is dramatic.  The latency for task switching within a priority
is little more than a procedure call.  No interrupt or switch through
supervisor state required.  Few semaphores or other complex mechanisms are
required, because even our timers run within the same scheme.  The savings
are everywhere.

The savings in memory is dramatic too.  Why, given a savings of 300 real
tasks, we save at minimum 300 * 2k/stack = 600k.

Thus complexity and cost is way, way down, but we still have the benefit
of preemption in the (rare) situations we need it.

By the way, our system provides an application, supports about 16 terminals,
three network (via serial or satellite lines), handles 50 phone calls
per second and supports a database of 500,000 subscriber records.

Not bad for a 68030.  The clincher is that we have enough ummph in the
system and soft deadlines to boot, so we've never had to do any sort of
technical scheduling analysis.
Newsgroups: comp.realtime
From: enertec@netcom.com (The Gang at Enertec)
Subject: Re: real-time X/Motif data display user interface tool
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 28 Dec 1992 23:04:46 GMT

As a postscript to our search, the following vendors have been reported to
supply products that provide the required functionality:

V.I Corp - DataViews: DVDraw, DVPlay, and DVTools.
(413)-586-4144 or email vi@vicorp.com

SL/GMS - SL-Draw
Contact Michael Meagher uunet!gandhi!mike (415) 927-1724.

statsci - Splus 
send e-mail to joe@statsci.com


I have also heard of a product called Sammi from a company called Kinesix (or
something like that).  I have no literature on them currently, but they sound
VERY appealing to us because they provide an API to allow application programs
to pipe data to the dynamic graphic elements, and we have and existing system
/ database.  It seems that calling their API to display our data graphically
would allow us to minimize our engineering costs.  If anyone has seen or used
this product, your input would be greatly appreciated.

Thanx again,

John Feras

-- 
The Gang at Enertec
EMAIL	enertec@netcom.COM
MAIL	811 W. 5th Street, Lansdale PA 19446
PHONE	215-362-0966