"If you mean me, you're right - my dilettante grasp of electronics is woeful. " - GordonC
No, I didnt mean you! ;-) ... IMO, "grasp of electronics" should not be a requirement for a user of an electronic product.. Sadly, the theremin being what it is, more understanding is required than usual - particularly if one wants to get the best from the instrument.. Understanding of the basic function of capacitance being, I believe, the most important.
"I would get very frustrated at the quality of computer software and hardware, except I understand that while "right first time" is possible, a computer that is nearly 100% reliable is not something I want "
Warning.. Longwinded boring blurb follows.. ;-)....
I think there is some confusion here.. AFAICS, the immense "power" of modern microprocessors is often utterly wasted - their speed and resources gobbled up by inefficient high-level programming.. People throw a DSP PIC into products where an old 6303 8 bit MCU programmed at assembly level by someone competent, would do the same job.... Ok, the cost of the new parts is the same sort of price as the old 6303 used to be, but the extra complexity and inefficient code used for the new part makes it less reliable..
Yes - There are things impossible to achieve with an old MCU - But most of the time a simpler MCU will do the job.
I think the "problem" is "box thinking" - MCU development moved too quickly - people (like me) were excited by the newer parts, so jumped ship frequently, never spending long enough on any part or archetecture to fully utilise its potential - Modular software concepts came on the scene to enable transfer of software from one part to the next, and these became libraries of standard functions or "boxes"... All great at high level - But down at product development level, down in the MCUs fitted in washing machines and control boards - particularly anything where failure is dangerous, one (IMO) needs to fully understand every operation.. And when one did (I stuck with the TMS9900 which was a wonderful MCU, for many years, and with the Cosmac processors) there was a chance that it would "bite the dust" in the competition, and your investment would be less valuable - Those opting for Intel made the right choice IMO, even though their processors were (are) horrible.
And standard libraries containing ready built code modules with often clumsy interfacing to these modules, hides what the MCU is doing.. And when one dissasembles the code and looks at what has been generated for some simple function, one finds horrors which chill the blood..
"it would use a processor that is more than twenty years old (by which time there is a good chance that all the bugs in it have been found and documented), be capable of only a few well defined tasks (probability of bugs increases exponentially with complexity) and outrageously expensive (the cost of thorough debugging is prohibitive.)"
I think the opposite could be true (certainly at the level of MCUs in reasonably simple board-level designs) - Processor bugs etc would not only be documented, but fixed - The "few well defined tasks" would be the opcodes.. so tasks required on a simple design could be implemented, even if the particular sequence of instructions had never been done before. The MCU would be simple so debugging would focus on the code, without the problems of complex interactions one gets with more complex hardware.
Not much of the above applies to personal computers or complex products requiring a lot of computing power (one could not implement the EH Talking Machine in a system using an old 8 bit MCU, one would need a board full of electronics in addition to the MCU).. But one does not need " nearly 100%" reliability for something like that... One does need it for cars and aircraft and satilites.
For me though, it gets a bit "personal" - Even if something I design appears to work well, I have a deep uneasy feeling if I do not know exactly whats going on inside it.. Just been bitten a few too many times by trusting the specification for some software module I put in my product, which doesnt tell the truth - or at least not the whole truth.
This happened to me in my early days with the PSoC, where I relied on the specification for the MDAC User module, and it was a pack of lies - or at least never disclosed major limitations - (the data has since been changed following a big hoo-ha) - It all worked well, but prior to full testing being completed, was taken (despite my protests) and put into a motor for an electric vehicle, where it crashed causing about £50k in costs and lost investment..
So I now write my own software interfaces for the PSoC, in assembler.. And, whilst things like theremins are not critical, I dont want to get a call from someone with a problem that I cannot understand.. I want to know every aspect of the design, and if I include a MCU, this means understanding every line of code in the MCU.. And this means that if a line of code calls a function, I must understand every line of code in that function - So pre-compiled object modules without their source are not used by me.
And doing the above is much slower.. :-(
Fred.