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
http://www.technologystudent.com/elec1/ldr1.htm
Light dependent resistor. Works well in low light. When the ambient light
is high, the resistance is high. When the light level drops so does
resistance. Just turn the lights down to a reasonable level that
approximates twilight and read it. Then do the math and make the chip PWM
allow for it. Easy.
Kevin Alderman
-----
Well, I stand or sit, corrected. I guess I've been gone too long from
electronics.
I had no idea that these little gems existed. Neat.
Regards,
Steve.Thompson
Me too.
Paul Lamar
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.