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

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.