Things like runaway inductor current, for example. This needs to react
within less than a microsecond on today's switchers or it will cause a
pyrotechnic showdown.
Hardware - that's the kind of thing it's good at; stupid, fast, unchanging
tasks.
Remember that we are nowadays talking up to 1MHZ,
not 50KHz anymore.
I don't know about that - because, at least what I saw while doing that sort
of thing, *cost* and EMI is more important than power density. People like
to brag about the MHz converters in brochures - but there is a vast number
of commercial designs running below 150 kHz because the components are
cheaper, they are available *now* and the parasitics are easier to deal
with, epecially with high-voltage outputs. The rules on EMI also tend to
push things lower - as low as 30 kHz because one will wish to avoid the
"step" at 150 kHz where more severe limits kick in (Harmonics).
The "fastest" I did was planar designs running at 350 KHz, which seemed to
give the best balance between "the mechanics" - planar is very much about
mechanical work - and the commonly available components.
700 an hours? Let me know who pays that much and I'll pack up and move.
That's what people will *charge*, not what *you* will be paid for doing it -
a lot of this kind of work is done on a per-job basis by consultants. The
new hand-to-mouth economy!
Anyway, the higher level the code the more you must rely on the quality
of subroutine, compiler etc. Not always such a good idea when it comes
to critical stuff.
I think that is good - because many people will have used the same
components so there is a good chance that the bugs have been found and the
people building the tools often have detailed knowledge of the target
platforms that I will not have; The "bug-book" for a common CPU such as PIII
runs into a telephone-book sized tome. Let the writer of the optimiser code
cry over that, I say.
There is an even bigger chance that I will design new bugs writing my own
libraries ;-)
Documentation is key. With proper docs an assembler approach can be very
clear and understandable. Just some comments in the code isn't enough.
The doc must be written while writing code and not as an afterthought.
Same with circuit design. At least that is my philosophy.
.... Which is sound.
You must meticulously document failure
modes and mitigation, a.k.a. hazard analysis.
I think that is very hard in practice - because how can you *really know*
what this particular instance of hardware and software will behave under all
conditions without doing a full state-space analysis; I bet the universe
will run out of light before that runs to completion!
The hardware may not be exactly what is specified either - unless one buys
special "safety verified" devices.
QA will likely shoot it down,
and rightfully so.
That's what QA *do* ... ;-)
20Hz ain't enough these days. My last switcher was in the KHz range here.
You can get microcontrollers with DSP cores also, so there ;9
