The best explanation of real time issues I have ever seen. A laser
printer and how it works is used as an example. Also my explanation
in 1979 or there abouts. Addicted to learning. For me learning is
entertainment.
Paul Lamar
For embedded systems there is the RTOS or Real Time Operating System.
It operates differently from our normal OSs and is used for time
critical applications. Lets start with an example that we are
familiar with- our EFI. Granted on the surface an EFI system is quite
simple. Measure the amount of air coming in, calculate the amount of
fuel needed for a perfect fuel/air mixture and then turn that into a
PWM for the fuel injectors and go again. If we want to add spark to
the mix then you need a crank angle sensor so that our little box
knows how fast our engine is turning, where the crank is, when to
fire the plugs as well as our perfect fuel mixture. Sounds easy
enough. So for every revolution the computer needs to know manifold
pressure, temperature of the incoming air, temp of the engine and
RPM. From the CAS it reads as many as 32 teeth per revolution and the
other data presto it works. Until it doesn't.
All of our calculations are based on getting the needed info at the
right time. If it doesn't come at the right time, then what happens?
The big fan up front stops and the pilot starts to sweat.
This is where the RTOS comes in. It is already used in critical
applications like medical instruments, autopilots, EFIS systems,
FADEC and so many more. Its basic premise is that in order for the
system to work we MUST have certain info by a certain time. It
wouldnt work very well for our system to stop working while we wait
for a CAS signal, or a temperature input. The RTOS knows that we need
this input by a certain time, but if it doesn't come then a flag is
raised, it uses a pre determined value for the variable and we can
limp home. When our cars go into closed loop the computer is now just
pulling from a table rather than making calculations. Our fuel
economy goes down, performance is reduced but we can get home. When
an autopilot is looking for an input from the GPS and it misses its
appointment, what does the autopilot do? It uses the last known good
input, throws a flag to let us know and reverts to maybe heading mode
or GPS heading, etc. and then you get to take over but you didn't
crash. Why? Because the time constraints were built into the system,
it knew when the mail was late and it let you know.
For an EFI system, the embedded RTOS is the only safe way to go. No
boot up, no wait time, just power on and it goes. Texas instruments
has a small dev board with dual lockstepped ARM processors that are
designed to run the RTOS. Not only do you get the benefits of the
RTOS, you get the benefit of dual processors reading the same
sensors, supposedly coming up with the same solution and comparing
notes to make sure they are right. And it costs about $20.00. Yes you
can use the provided IDE and yes you will program it in C, but the
benefit is that when we fly we get to come home even if there is a
problem along the way.
RTOS is proven, required in some FAA certified electronic systems,
and best of all its open source and free. RTOS
<
http://www.freertos.org/about-RTOS.html
Kevin Alderman
Maximite BASIC is real time. So is DOS with QB as are most single
board computers like the Ardrino and the Mikroe line. What is not is
multitasking or multi-user operating systems line Windows and non
real time Linux. In cases like that they have schedulers that decide
what programs or threads are worked on and when. As a application
programmer you normally have no control over that. Also certain
programs or or threads have priority over other programs. That too
the application programmer has no control ovedr. Real time Linux lets
you change those parameters.
When writing a hardware control program for the Maximite or the
arduino the programmer has total control over what happens and when
it happens within the limits of the speed of the processor.
Paul Lamar
OK, I agree with what you said, apparently I didn't say something
right. With all of these boards and regular C programming you have
it read a sensor and do something. In my airplane I have an Arduino
Teensy under the pilot seat that is programmed to operate my lights
and flaps. Seems simple enough. It looks for a signal on a pin, and
if this pin goes high my strobes come on, navs, etc. My panel lights
are connected to a POT. If the pot goes up, brighter lights, pot goes
down, no lights. But I have in the mix a light sensing resistor so if
it is really dark outside the lights will only go so high.
For the flaps it reads my airspeed. Above 110 you wont get flaps.
Below 110 and above 90 you can get 10 degrees and so on. It does more
but my point is this- it is always looking for airspeed, checking
those pins for voltage and watching for a response from that LDR. If
any one of those inputs fail, that part of the code ends up waiting
for that input or gets something I cant use. I didn't build in a lot
of "safety code" because that would mean that the variable would
default to some safe value and might cause an action that I dont
want. I didn't want my flaps to start dropping or worse start to come
up, etc. The backup is to disable the ECU and handle the flaps
manually through hardware.
The point of all this is that these programs go step by step. Miss a
step and fall down. Wait too long for a signal and it will be too
late for ignition, etc. With RTOS everything is scheduled. If the
packet is late the program knows that the train leaves at 4 and it
goes on to the next stop and doesn't miss the next station waiting
for this one. RTOS was designed specifically for this type of
application.
The closest thing to it that I know of for automotive type uses is
the Freescale (formerly Motorola chip) HC or HS series with X-GATE.
The X gate processor collects the inputs and does the initial
calculations filling the ADC variables. The main processor then uses
this data to operate the main program and control the injectors,
wastegate, etc. This is the processor that Megasquirt was designed
around and others. From the beginning running automotive applications
was in its genes. It has additional noise protection, additional
power supply filtering and more. In the code we build in parameters
that we expect the variables to be in. We couldn't be running at 8500
rpm at 9 inches MAP. So, the comparisons begin.
All I am trying to say is that there are some things that work better
than others. This came about through trial and error and the error
parts were costly in lives and property. Just like the turbos on
certified engines, I am sure it took a few fires before they got the
mounting and installation correct. This EFI system runs the entire
engine, and to bet your life on something that 1. was picked because
it had the cheapest chip in it and 2. was picked because it worked
with only 20 lines of code is nuts. This approach is intentionally
installing a single point of failure for everything into your
engine.
If you go and find the open source Megasquirt 1 or 2 code, download
it and go through it. It is written in C. It is pretty thorough. I
don't like that it is one long program. C and C++ will let you use
header files- one file for ignition, one for injectors, etc. If you
need to modify one select it and do it. Your ignition file can read
an external table which can be modified on the fly. Its much easier
to break the program down into slices than have 100,000 lines of code
to scroll through.
The Freescale board is about $80, the megasquirt 1 or 2 is available
open source for free. With high impedance injectors and a couple
more chips you aren't far from a working EFI. One designed for racing
and automotive use with lots of safety and backups built in. You can
modify the code as you wish. My ultimate machine will have the EFI,
but mechanical fuel injection as well. The ignition will be CDI and
controlled by the ECU. If the ECU fails a straight 20 degree advance
HE sensor will trigger the spark. I plan to be able to fly home.
Kevin Alderman
I see what you are saying. The Maximite has a very simple time
interrupt. The command is:
SETTICK period, target [,nbr]
This will set up a periodic hardware interrupt (or “tick”). Four tick
timers are available ('nbr' = 1, 2, 3 or 4). 'nbr' is optional and
if not specified timer number 1 will be used. The time between
interrupts is ‘period’ milliseconds and ‘target' is the line number
or label of the interrupt routine.
The idea is to use this to check all your sensors. If one is not
working take appropriate action.
I was a big fan of Mega Squirt in the begging. It was written in 6800
assembly language. I was very familiar with that. It actually was
designed by Chuck Peddle while working for Motorola. The story is
Chuck came up with a better version and the management refused to
implement it. "We already have a 6800 microprocessor" He quit and
went to work for MOS Tech. Produced the 6502 KIM 1 which was the
Maximite of its day.
The KIM1 had keyboard, display and mass storage. The mass storage was
an audio tape recorder. Not random access unfortunately but that was
years before the floppy disk let alone the hard disk or even the
Apple II.
Steve Wozniak adopted the 6502 for the Apple and the rest is
history.
I met Chuck and asked him if he would mind my calling my board the
SuperKIM. Chuck said no problem.
Getting back to the Mega Squirt. They added daughter cards which made
it a cluge when they updated the processor. Motorla fell behind in
processor speed and power. The 6502 became the basis for the early
ARM and was eventually upgraded to arguably the most powerful
embedded processor available. You probaly have one in your cell
phone.
Mega Squirt also switched to C and lost control over the exact time a
process would take. They also lost me :-) In assembly language you
know excatly how long an instruction or series of instructions will
take to execute down to the nearest nanosecond.
The number of 6502 clock cycles was specified for each and every
instruction. This is not given in any high level language that I know
about. I use an O-scope to measure it when I am writing an
application in high level languages like BASIC.
Here are some jpg about it.
Paul Lamar
-------------------------
I'm mostly lurking right now and learning a lot of things.
However, given I did have a small education in electronics (tube
stuff, actually), I thought I might question the following:
"...light sensing resistor...".
Wouldn't that be a photo transistor? And the "output" of that
would then control the intensity of your lighting. Yes?
It is amazing how fast they can react (using a capacity to slow
them down a tad) to flying into a cloud. All the dash and GPS
displays dim rapidly and then recover as soon as you are back in
bright sunshine (I do instrument flight, so yeah, it is a big
deal to me).
In fact, in years gone by, using Motorola Two-Way Commercial
radios, we taped over (using a white tape) the green light of the
control head, so that at night it wouldn't blind you. When photo
transistors became available, Motorola put those in and they
would automatically drop intensity.
Ah the ancient old days....
Steve Thompson
The Rotary Engine News Letter. Powered by Linux.
If you want off the list PLEASE let me know and I will
remove you. ACRE NL web site.
http://www.rotaryeng.net
You Tube
http://tinyurl.com/beqqxas
Copyright 1998-2016 All world wide rights reserved.