pbo
See multi-version dissimilar software: https://en.wikipedia.org/wiki/N-version_programming
Furthermore most modern planes are designed to be able to fly with one engine inoperative, even those which have only two engines.
Of course there exist very complex components in the category of microcontrollers, some of them even offer enough resources to run Linux, but if you stick to the $1-$5 range the specs are very limited.
Here are two examples, the first one costs around $3 and the second one is less than $1.
http://www.ti.com/product/tms320f28027 http://www.atmel.com/devices/attiny85.aspx
I develop on such platforms and even though there is an interesting challenge in programming these tiny processors and optimizing CPU cycles and memory usage all the time, in the long run it becomes quite strenuous because there is only low-level stuff and I miss the expressiveness and flexibility of more abstract languages.
I write assembly for DSPs on a near-daily basis. Up until a few months ago there didn'nt even exist a C compiler for the target architecture.
Even when you write C code for an embedded platform that does have a decent C toolchain, you cannot truly understand what you're doing without spending a lot of time looking at the generated assembly, and writing some of it yourself.
However, this kind of architecture has nothing to do with the x86. RISC, no cache, in most cases no MMU (and rarely any DMA), an extremely simple and straightforward pipeline, etc. I've written assembly for several such architectures, but compared to them I find x86 assembly intimidating.
If you'd like to read more about this kind of systems, this document could be a starting point: http://www.ti.com/lit/ml/slup232/slup232.pdf
It sums up pretty well the stakes and technical challenges with digital power supplies.
This kind of development is very demanding, because you can't afford to leave any bugs in your program but at the same time you're always shipping late because of tight schedules and often blurry specifications.
On top of that hardware and software development cycles are concurrent, so no target hardware available when you're writing your code.
In these conditions the only way I found to have something that works is to keep it very simple:
1. Simple algorithms
2. Simple data structures
3. Few abstractions
4. No dynamic memory allocations
One application for this is lasers. I'm part of a team that works on a converter that uses wall power as an input to continuously charge a few dozens ultracaps then empties them all at once to fire very short pulses in the hundreds of kW.
What I find the most impressive about this is that the mechanical engineers have managed to fit this in a 2U rack.
Revenue and margins yes, but far from break-even.
I used to work in a lab with a researcher who designed complex mechanical systems with lots of rotating parts made from rare and expensive materials. Everytime he needed even the slightest modification he had to wait for at least three months to have a new part machined.
[1] http://webecoist.momtastic.com/2010/08/09/insular-dwarfism-1...
[2] http://webecoist.momtastic.com/2010/08/02/animal-gigantism-1...
However my applications run on systems with very limited resources (and a Harvard-ish architecture, e.g separate data/program memories) and I wonder how far tools like ClojureC could go with regard to these constraints.
One of the most interesting stories is about a man who lost his ability to intuitively recognize things and needs to reason about their features to find out what they are.
This is my shoe, no?
No, it is not. That is your foot. There is your shoe.
Ah! I thought that was my foot.
See http://news.xinhuanet.com/english/2008-12/30/content_1058293...
- At a research lab. They had a massive Stratasys which cost around $30,000. They used it all the time for experiment setups; they had a whole workshop with CNC mills, lathes, etc. and the 3D printer was one machine among the others. It was used as much as the others, no less, no more.
- At a hardware startup. We never bought a 3D printer, but we used on-demand 3D printing services (Shapeways, Ponoko, Sculpteo, etc). This allowed us to iterate rather quickly on design matters - we were doing consumer electronics.
For my personal use I don't think I'll buy a 3D printer within the next 5 years.