Very first was the Dunlop Maxerette(sp?) fitted to the Jenson FF. Adapted from aircraft technology. Think that only worked with permanent 4WD, though, so perhaps just the one sensor?
- Vote on answer
- posted
5 years ago
Accelerator stuck wide open while car is going fast: what should you do?
Loading thread data ...
- Vote on answer
- posted
5 years ago
The electronics industry didn't make a quantum leap from analogue to microcontroller. There was an intervening period with boards full of logic chips, plenty of which would have been part analogue, such as monostables. Then, not all of it could instantly be mopped up by micros.
Formal proof has limits. Test, test and test again on real product.
- Vote on answer
- posted
5 years ago
I suppose in theory there's little you can do in software that you couldn't hardwire in TTL, but it would take a lot of hardware to do anything sophisticated so would be hard to fit into a car module. I'm guessing the earlier ABS systems were pretty simple affairs.
Yes, formal proofs have been somewhat oversold in the past. All that happens is you move a portion of the debugging from the code to the proof - its irrelevant if the code passes the formal testing if the proof is bug ridden itself and for any significant project the formal proofs can be gargantuan.
- Vote on answer
- posted
5 years ago
How did that work , the difference in wheel speed caused some secondary mechanical pump to work against the brake pump so lifting the shoe off or something similar?
- Vote on answer
- posted
5 years ago
The original Ceefax decoders were in 2 x 3U racks - all TTL. It all got into one dedicated chip/
- Vote on answer
- posted
5 years ago
Was that chip stil hard wired or did it use software by then? The problem with hardwiring is if you find a bug its a LOT harder and more expensive to fix (if its even possible without a redesign) than just updating the ROM code in subseqent batches.
- Vote on answer
- posted
5 years ago
I think Mullard got it right.
- Vote on answer
- posted
5 years ago
It's probably not so bad for software that processes data in a computer system (with "unlimited" resources), which is [hoped to be] scalable and the compiler and os handle the i/o. I don't have experience of this type of project.
The problem is in attempts to rigidly impose these methods on a real time system with complex hardware. High level stuff can be simulated and when incorporated doesn't give problems but the bulk of development is low level work and nothing can be proved except with physical live kit. "Bugs" are not usually coding errors but an incomplete understanding of the system.
- Vote on answer
- posted
5 years ago
I've no idea what you're talking about.