> Ughh, DOS. Just kidding (sort of)..
>
> Anybody here work with a Real-time OS? I have always been kind of
> curious about how a real time version of Linux differs from a regular
> one. Just stripped out? I'd think a real-time OS would be good for
> something like engine management and monitoring..
>
>
http://en.wikipedia.org/wiki/Real-time_operating_system
>
>
http://www.realtimelinuxfoundation.org/
>
<http://www.realtimelinuxfoundation.org/>
>
>
> Matt-
>
> Me. I wrote my own real time OS back in 1976 on a 6502 in assembly
> language.
> My road test system would take in data every few milliseconds
process it,
> display on the instrument panel with an LCD, and send it to the
printer in
> real time while the printer is printing. All using a ONE megahertz
> processor
> and 2K of EPROM and ONE K of RAM! I also designed and
manufactured the
> SuperKIM
> mother board. Probably the first commercial application of an
embedded
> microprocessor.
> For sure the first real time multitasking microprocessor
software. Before
> the Apple II.
> Read all about it:
>
> Microprocessor-Based System for Roll-Down and Acceleration Tests
> by D.K . Lynn, C.R. Derouin, and Paul Lamar
> Los Alamos Scientific Laboratory
> Published in IEEE Proceedings 29th Vehicular Technology Conference
> (The technical details of the Lamar Instruments real time road test
> system.
> The Phd's get to have their name before mine :))
> Arlington, Illinois, March 28-30, 1979
>
>
http://www.computer-dictionary-online.org/?q=6502
<http://www.computer-dictionary-online.org/?q=6502>
>
http://www.hansotten.com/indexkim.html
>
http://www.kim-1.com/docs.html
>
> Well When Windows came out they busted a lot of real time
applications
> because
> you could directly access the hardware using QB running on DOS.
> There were instructions called IN and OUT that directly accessed the
> hardware at light speed. PEEK and POKE did the same thing.
> All that is gone.
>
> Paul Lamar ...No rotor no motor.
>
>
> Here is the prototype Matt. I went out to the hangar and dug it up.
> Road & Track used it for about five or ten years to
> test cars. This is one of the very first Kim 1s.
> Note; the ceramic packaging and gold pins on the CPU
> and ROMs. I now have it back. The Superkim computer was used
> in the production model for years and then we redesigned it
> keeping most of the features but doing away with the keyboard
> and six seven segment LED.
>
> John Dinkel (on here) wrote a few articles about it.
>
> Computerized Slalom & Skid Pad Testing by John Dinkel
> (Article about the Lamar Instrument Road Test equipment.)
> Road & Track May 1977
>
> Road Testing by John Dinkel
> (Article about the Lamar Instrument Road Test equipment.)
> Road & Track Buyers Guide 1978
>
> Other articles were written in other magazines.
>
> --
> Paul Lamar ...No rotor no motor.
Real-time UNIX is a very different beast than "regular" UNIX. Or Linux.
Both UNIX and Linux are time-sharing OSes. They have a scheduler that
decides which process (program) should run next. The scheduler has a
round
robin with priority system but it is not adequate for real-time
because a
process is allowed to run until it has used up its quota of CPU time or
until it is blocked or waiting for a I/O operation. This means that
a high
priority process might have to wait until the currently running process
gives up the CPU. UNIX used a 2 second time quota. Two seconds is an
eternity for a real-time application.
Real-time OSes can force the running process to give up the CPU to a
higher
priority process whenever the higher priority process needs the CPU.
This is
a major modification to a time-sharing OS. It is not just a matter of
changing the scheduler, and of course this has to be done.
Experience has
shown that there are lots of places where the code assumes the original
scheduling scheme. Sometimes in strange places and at strange,
unexpected
times. And they don't all show up at once. Very difficult to de-bug.
Doc Custer
Retired Software Engineer and sometime Audiologist
That is why I designed the hardware priority interrupt structure
in the SuperKim. If an external event (a rising edge of a pulse)
came along that needed instant response it set one of eight latches.
These latches were connected to a priority encoder. The encoder would
then signal the interrupt request pin (IRQ) on the 6502. The 6502 would
stop what it was doing and read the priority encoder to find out
which of
the eight latches was requiring service. The 6502 would then reset
the latch
allowing another event to set it again. This part of the code took about
20 or 30 instructions and happened in 20 or 30 micro seconds. The
6502 then processed the request.
One of the latches was connected to a real time clock pulse.
This interrupted the CPU every .001 second. Another was connected to
the fifth wheel. The fifth wheel put out 100 pulses per foot
so at 200 FPS the CPU was being interrupted by the fifth wheel
at 20,000 times a second or every 500 microseconds. Way more than
enough
to process that request. This scheme can be used as a super fast
hardware multiply
and divide. If a FPS pulse comes in, sets a latch and reads the fifth
wheel counter at precisely .1 seconds the counter will contain 2000
pulses.
Guess what? That is 200.0 Feet Per Second accurate to one part in 2,000
and that number is merely sent to the display and printer. Takes
only a few
microseconds. Obviously the display and printer are updated at 10
times a
second which is a blur to the human eye. This is only part of the
system.
There were hardware interrupts that came in at other times. The 6522
timer
counters were used to generate these tones fed to the latches.
This was all done with a 1 MHz processor. When the 2 MHz 6502 came out
we were in seventh heaven. The PhD's at Los Alamos Scientific Labs were
so impressed with this system after they read John Dinkels article
in Road & Track magazine that Doctor Dave Lynn called me up and asked if
he could study the system. I wrote all the code in hex (took me a
year) so he offered
to translate it to assemble language and assemble it on the 6502
cross assembler
they had working on the Cray 1 computer back at LASL and send it
back to me.
I said yes so Dave flew over to Hermosa Beach and studied the hex
code on my
kitchen table for two weeks.
He then went back to LASL and wrote the IEEE paper mentioned above.
About the time I got the 6502 assembly language code back from LASL
the Apple II
mother board became available with out the case, keyboard and power
supply.
I bought one and got it up and running.
Bob Bishop from Jet Propulsion Labs in Pasadena contacted me and
said he had
a 6502 cross assembler working on the Apple II. We then used that
assembler to
further develop the code in the road test system. We started another biz
called Microproducts to sell that assembler and hit a gross sales
number
of 200K a year within a year. First assembler available for the
Apple II.
Many Apple II programs were written using that assembler. Another story.
I owe it all to John Dinkel for giving me the contract to develop the
road test system for Road & Track in the first place. Thanks again
John.
I also owe it to my ex wife Rhonda and her cat Kubla (for walking on
the Kim 1 keyboard at night) for supporting me for the year or so
it took to write the code and design the SuperKim. Thanks Rhonda.
A rotary engine fuel injection system built around the SuperKim
would be a piece
of cake.
Paul Lamar ...No rotor no motor.
Thanks Doc for reminding about task scheduling.. I used to think about
stuff like that.
Interesting history Paul. I didn't realize you were a computer geek.
:) With that background, forget the all mechanical FI system. A little
electronics can make things much nicer..
Regards,
Matt-
The Rotary Engine NewsLetter. Powered by Linux.
ACRE NL web site.
http://www.rotaryeng.net
Copyright 1998-2006 All world wide rights reserved.