AC@09:48
TL:DR was tempting.
"There is a *lot* more in a modern full authority digital engine control (FADEC) for an aircraft than a Z80 (or even a credible number of co-operating Z80s) could cope with,"
Well I was aware that more modern engines seem to use active clearance control and it was my impression that military engines have to handle a much wider and regular change in power levels.
especially if you try to develop using the trendier languages for these applications (Ada or to lesser extent C++).
"For a start, the chances of fitting a worthwhile amount of the currently required code and data in a 16bit/64kbyte address space are vanishingly small, and bank switching and similar techniques necessary to bodge extensions to the address space bring their own challenges."
I can say that Pratt & Witney have done quite a bit of work using the USAF 1750A architecture. This is a 16 bitter with a 64K address range (but the optional MMU gives you a whole 1MB to play with). It runs the whole Atlas V launch vehicle.
Multi-precision integer and single precision floating point are required from time to time these days, and in the typical ~20ms cycle time the combination of essential input validation and actual control calculations required for the control loops would not be practical. The size of the data tables required is also surprising; high resolution lookup tables are required for all kinds of things (pressure, temperature, you name it) and these tables consequently are not small.
In the case of the S
When the computer hardware is *so* coupled to the system other options become possible. Off hand the only one I can think of which would routinely exceed 16 bits would be pressures measured in Pa
If table look-up is a key part of your architecture then hardware support for table look-up would be a distinct option.
Part of the reason for this is that, driven by the need for best "mpg", modern jet engines have very little tolerance between the normal safe operating zone and the "whoops" zone (hence best to ignore the idiots Branson and O'Leary and their comments a little while ago re the safety of flying through volcanic ash clouds). This very limited margin for error makes accurate and timely calculations even more important.
A little unfair as engine mfgs preferred *no* exposure to dust clouds. The original exposure limits came form Chernobyl in the mid 80s. The improved efficiency you say FADEC systems gives would also mean they are better capable to actively compensate for performance loss (and report such) to the aircraft.
It's only a couple of decades since analogue systems based on operational amplifiers and the like were considered adequate for engine control (usually in conjunction with a beatifully engineered hydromechanical system fundamentally based on springs and clockwork), and doubtless a Z80 could have replaced one of those controllers, but the economics of affordable flight mean those days are long gone.
Add the need for a language such as Ada (or, believe it or not, C++), and the whole thing just doesn't fit into a 16bit address space, although the full 32bits is far more than is necessary.
Depends what you are using that address space for. The last generation Shuttle Main Engine controller was a Motorola 68000 using 128KB of code programmed in C. The SSME destroyed a number of propellant pumps and 200 atm combustion chambers during its development and during its start cycle requires valve opening measurement to the nearest degree (an encoder was misaligned by this amount. The chamber blew up). Its unmodified throttle range is 65%-109%
If you don't have to host the compiler on the target hardware you can use a pretty aggressive (read large, slow, architecture tuned and expensive) compiler to crunch the source.
""Forth type questions"? Are you sure these are not related to Lucas Aerospace's legacy [= "stuff that works"] 1980s translated (not interpreted, not compiled) threaded-code language, "
The usual term is "threaded interpreted" languages.
which iirc was called LUCOL, and was eventually used on various chips from Texas 9900 "
(16bit) to M68K, including the first UK civil FADEC systems? It enabled extremely simple extremely compact control programs which were trivially simple (that word again) to design, document, code, verify, and test (in this business, simplicity should usually be an advantage).
Echos CAR Hoare's comment about a language too simple for bugs to hide in.
It's so old (and, sadly, obscure) that there's little evidence of its existence, though if you have access to SpringerLink (I don't) there is a paper whose abstract looks promising.
Rockewll Collins seems to have gone a similar way. They developed an actual hardware stack computer architecture but not sure if they went with Forth or some in house design.
"It's flying lots of Rolls Royce civil engines from RB211 onwards, and a few others, "
which suggests it pre-dates even the 16 bit processors of the late 80's. The Z80 has been a popular forth target for some time.
but currently out of fashion in comparison with Ada, even though flying Ada requires either full trust in the compiler (yeah right) or far more testing using the compiler and chip in question than the PHBs like to pay for.
"If FADEC really was doable on a Z80 it would be being done, as Z80s are well known, well understood, and well supported,"
Sort of my point.
" not to mention its biggest attraction to the PHBs, cheap to implement. Other readers may not be aware that Z80s didn't die in the same era when the S100 bus died, Z80s simply moved elsewhere e.g. into ASICs into cellphone handsets, which meant that at one time not too long ago, Z80s were the world's most widely used microprocessor. Obviously handsets are a market now rightly dominated by ARM."
Zilog seemed to have licensed their IP fairly widely. They never seemed to have got a really *successful* 16 (or 32) bit design abter the z80 (but did better than the folk behind the 6502, whose performance did inspire the ARM approach)
The same basic SoC ASIC techniques as are used in a handset are also used in an engine controller although obviously the engine-mount environment calls for rather different silicon fabrication techniques; you can't buy these chips at Maplin.
Well the SSME controller needed both M68k's to be on the same *die* due to cross checking timing constraints. Definitely *not* getting that from Maplin.
When the 16bit address space became a limitation (back in the 1980s) the replacement processors of choice were typically from the 68000 family. Some unlucky folks (others would say foolish folks) chose the short-lived Z8002.
Since then, PowerPCs have generally been a preferred target for quite a while, in large part because of performance per watt factors. Obviously other options are available.
Anyone starting from a clean sheet today (unlikely, cost of entry is too high) would do well to look at licensing an ARM design; one of the many reasons ARM do well in addition to performance per watt is that courtesy of predication (and the Thumb subset) they get excellent code density (less memory for a given application, or a more complex application for a given amount of memory).
ARM would be a good idea and Thumb gives good code density.
Biting the hand that feeds IT
