Phil wrote:
Frank,
As the designer of the majority of the hardware and all the firmware for
the Flight Control System of the M400 Volantor, I have a unique insight to
the system that you may not be aware of.
Thanks for that insight, Phil. I've worked on systems that were equally
tight (8KB ROMs with 1 byte to spare), although perhaps not as large and
tight.
functions on each of eight engines to lock-in RPM commands with
re-calculations for all eight done in under 20 milliseconds.
20 milliseconds per cycle. *Lots* of time.
We are also
reading 11 analog channels of flight instrument data including joystick
commands for pitch, roll and yaw; aircraft pitch & roll, attitude; aircraft
pitch, roll & yaw rates; aircraft pitch & roll angular accelerations; engine
temperatures; engine RPMs; and using this data to calculate stability
compensation commands.
Except I didn't realise that all this aircraft control stuff was
happening. I'd thought it was just doing engine control stuff like
ignition timing and suchlike. What you are doing is impressive!
The Flight Control System is a dual
system with the Redundant 'B' system operating in parallel with the 'A'
system. The 'A' and 'B' system are comparing & synchronizing data between
each other.
I'm curious... what do they do if they disagree? If there's only 2
systems, then voting algorithms don't work!
Now with all that being said, I think you may see why we chose to use
assembly.
Absolutely!
I found that I could write code
that uses roughly 10 times less instructions to perform the same operations.
Yes, this has been my experience when re-coding HLL to assembler.
Your argument about the average C programmer vs the average assembly
programmer just doesn't apply here.
Note that my comments related to the *average* C programmer vs the
*average* assembler programmer.
However, one of the benefits of a HLL is that its *much* easier to
switch to a better algorithm. Once you have 1.5 years of your life
invested in an assembler program, its tempting to tweak and twist it
into shape rather than rewriting it using a better technique (or a
different, faster processor).
Granted, as more and more horsepower and memory are available and languages
such as EC (embedded C) and embedded Linux are improved your case will
become more valid. However I believe there will always be a place for
assembly in an optimized system.
Oh, I agree. However, my view is that that place is in small, isolated
parts, not the entire system.
Sometimes just throwing more horsepower & memory at a project
may not be cost effective, and you are also introducing more hardware that
can just as easily fail as the software.
Hmmmm.... I've found lots more software bugs than hardware bugs. Mind
you, in lots of cases, I was the one who put the software faults there
in the first place :-)
Another thing for consideration is
the fact that as this excess capacity becomes available, I believe newer
programmers become lazy and have no incentive to optimize their software,
witness the bloatware provided by Msoft. Inevitably, as Intel provides more
clocks and faster RAM, Msoft manages to hog the new memory and burn up the
extra clocks with their next version.
Yup to all the above. However, I view it as development tradeoffs... you
can ease the software guy's life a lot by giving him nice hardware to
work with. Just because he can code an entire OS to fit into 4KB doesn't
mean that he should be made to. Or allowed to. Especially if doing so
will increase the overall cost of the project.
I have 20 years of experience with assembly and also program in Pascal,
Fortran, Basic, VB, C, C++
I'll see you on all of those, and raise you FORTH and PL/M.
and for embedded applications I find that nothing
beats assembly for speed, compactness and precision control.
I agree. However, the systems engineering part of my brain says that
sometimes all that speed, compactness and precision control is more
expensive than its worth.
I've
programmed so much assembly that I think in Op-codes, hex and binary.
You ever dream in assembler? I used to, when I was heavily into it.
Nowadays I have nightmares about students ;-)
Having said all the above, I think we're far enough off-topic for the
list to take it to email, or to drop it.
Frank.
This is extremely interesting to me as the Moller Skycar should be the next
mode of transport for the more wealthy among us. Imagine, taking off out
of your back yard and traveling anywhere at 400 MPH within a 500 mile radius.
Especially for those of us that live in grid locked LA or NYC. It can take
hours just to get to the airport. To my way of thinking a taxi cab version
operating from heliports located on roofs of buildings would be a very
viable initial market. Potentially it is cheaper and more reliable than a
helicopter as there are far less moving parts.
Some people poo poo the idea but it is entirely within the laws of physics
given the very high power to weight ratio of the Moller rotary engine.
See the chart below.
Now that the side exhaust port has been developed to improve the BSFC of
the rotary it will be even more practical. Further improvements in
ducted fan static thrust levels should also help.
BTW I think the development of the rocket powered ballistic parachute capable of letting
the entire aircraft down has added to to the Moller Skycar practicality.
Paul Lamar
The AirCraft Rotary Engine NewsLetter. Powered by Linux.
http://home.earthlink.net/~rotaryeng/ http://www.linux.org
