Digital Replacing Analog...

[Klaus Kragelund]

On Thursday, August 27, 2020 at 10:01:48 PM UTC+2, Phil Hobbs wrote:

On 2020-08-27 11:18, Tom Gardner wrote:
On 27/08/20 16:11, Mike Perkins wrote:
On 27/08/2020 06:57:58, Ricketty C wrote:
I have been working on some circuitry to pull the plug on a motor on
reaching an overload condition before it can tear up the gears or
break the shaft (which the others on the project have done several
times).  This shut down was measuring the motor current and pulling
the plug, then allowing the MCU to restart it when needed.

Later it was realized a new motor should not be run over 12 volts, so
we need something to limit the voltage.  A regulator often requires
significant head room to work, so I used the same pass transistor to
add a voltage output limit.

Now it looks like the entire circuit can be done in an FPGA along
with a bunch of other stuff, and not cost any more.  The design time
will be a lot less as well although the analog circuit is already
done in simulation.

Four transistors, two comparators and a pocket full of passives
replaced by a few FF and gates inside a chip where they will never be
seen, just chug along.

My policy is simple, anything where real time is measured in ns is
best done in a FPGA. Anything in ms is best done in a MCU.

Most timings in the uS region can be done in a MCU and given this is a
motor with a slow build up to failure this sounds eminently doable in
a MCU where development time is much faster. Most MCUs have good build
in ADCs.

I guess this decision was made by someone who only has experience on
FPGAs?

I suspect the last point is correct. However...

With an MCU, it would be necessary to ensure that the
motor protection was running correctly at all times.
That\'s not only in operation but also when a processor
hits a breakpoint (of any kind) during debugging.

An LM393 and a MOSFET are very comforting sometimes. I always have an
analogue backup for mission-critical things like that.

A single circuit is not enough for safety

When doing approvals they can inject a fault in both standard circuits and protection circuits. So normally you need duplicated protection circuits to get a product approved

Cheers

Klaus

 

[Tim Williams]

\"Tabby\" <tabbypurr@gmail.com> wrote in message
news:9e465888-fc9b-4001-99fb-6be7e5d7887do@googlegroups.com...

On Thursday, 27 August 2020 14:46:27 UTC+1, Tim Williams wrote:
Replac...ing? You\'re a couple decades late to the party there...

Digital has been gradually partly replacing analogue since the 1960s. It
will never wipe analogue out though.

Well, by definition. Digital is a subset of analog.

Long, long gone are the days of big boards stuffed with op-amps (or with
discrete logic, for that matter). More and more is integrated into MCUs,
SoCs and such. They often still need op-amps for AFE, power amps for
output, power switches, glue logic -- you\'re never going to eliminate all of
those, in all situations. 2N3904 and CD4011 will never die, among many
others. That\'s not the point, the point is everything inbetween.

Tim

--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Design
Website: https://www.seventransistorlabs.com/

 

[Tim Williams]

\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0bd36331-f550-4e8d-942d-db0c448c8274o@googlegroups.com...

No, this design was just started recently. Other designs aren\'t really
relevant.

Ah okay. It wasn\'t specified, so I was careful to accommodate the
possibility that this was updating an old design.

The fact that an MCU has an ADC doesn\'t mean it has to be used. There are
pros and cons to every design decision and they are too numerous to list
for this matter. Suffice to say the desire is to write less C code when
practical.

Oh, is it a small quantity thing? (Production was also unstated.) By that
I mean, I take it the development costs will not amortize effectively, which
might be a good reason to avoid software development.

And also that the client is very confident in their spec, so changes are not
expected -- programming \"in solder\" being a lot more expensive than
software.

The pass transistor can be whatever works best. Presently it is an AOD4185
used as an on/off switch. I was looking at adding more circuitry to make
it a 12 volt limiter to the motor with minimal drop out when the power
source drops below 12 volts. I realized with some elbow grease the whole
circuit could be done in the FPGA.

There are power management chips for that. Check hot-swap and wired-OR
controllers. Though if you need a few more features than they offer, it
might be best to integrate it by hand.

And again, (ab)using a switching reg (in this case, one that can deliver
100% duty cycle) looks attractive, offering a much longer overload period
(e.g., continuous vs. a few ms), might be useful.

Control loops are not my forte, so I would need to handle this carefully.
But that\'s true in analog and digital domains.

The analog version I\'m playing with in LTspice uses a voltage divider with
a small cap across the high side resistors to an op amp inverting input and
a feedback resistor. The non-inverting input is a fixed voltage reference.
This feeds an N-channel FET which pulls down on the P-channel pass FET, the
AOD4185 driving the load.

Eww, tons of excess loop gain! Try heavily degenerating the NFET, and
putting some kind of local feedback around the PFET (source degeneration is
best, but mind the voltage drop; a current-sense amp might be used here,
though costing phase margin).

A charge pump to create an over-the-top rail isn\'t a bad idea, but not
absolutely necessary. That allows a NFET follower (enh mode) -- much more
stable. Depl. mode also an option, but fewer FETs to choose from.

And look at using a higher voltage op-amp, all that extra level shifting is
a mess and why bother when you can do it straight away, y\'know? Then you
can direct drive the PFET /and/ sense its current (from a small shunt) to
get a fast and stable loop.

As for compensation, try R+Cs instead of R (completely wastes loop gain) or
C (wastes phase margin) across the op-amp (out to -in).

Using the rather slow op amp uses elsewhere in the circuit it
under-performs with large transients. Changing that to an AD744 (picked
semi-randomly from the LTspice model list) the circuit works ok but with
some over drive and transients on current changes.

A partial solution to that, is to use source degeneration (again, mind the
voltage drop, this isn\'t always viable) and a fairly tight gate voltage
clamp (maybe a 5V zener?). Yanking down on the drain pulls big current, and
gate capacitance pulls gate voltage down along with it. Zener yanks the
gate back, limiting current. You can go from, say, >100A transients (under
a momentary-shorting load condition), to only a modest factor above the
design current limit (say 2-10x, the ratio of course depending on how much
voltage drop you can afford on the shunt).

You are behind the times. FPGAs can be as little as $2 and can incorporate
functions that can\'t be handled as well in MCUs. In this case it is on the
board because of a perceived difference in approvals. It\'s odd that we are
using this justification because no one has actually said it will be easier
to get approved... odd, but I\'m not running things.

I was just browsing FPGAs the other day, actually; notice I didn\'t specify
what range of FPGAs. I meant FPGAs as a whole. Median parts seem to be in
the low $10s, with the smallest entry-level parts being $2.

MCUs start at a fraction of that, and median parts are a few bucks.

As for approval, some people consider FPGAs to be \"hardware\", but I don\'t
know of any standards about that (for or against). Good luck.

Rewriting??? Most of what will be in the FPGA has not been implemented
yet. Something as simple as a control loop typically isn\'t much logic. I
did a frequency control loop and many other things in a 3 kLUT device. It
had several modes of operation and had to handle digital audio combined
with digital data in both direction, no reloading to set the mode. If we
ever needed to stretch the capacity we could have split the design into
several different designs and loaded the appropriate one when the system
mode was selected.

Like I said, allowing for the possibility of it being an update thing
instead. Though conceptually, if one is more accustomed to one or the
other, there\'s some mental or diagrammatic \"rewriting\" to fit a given
application to one system or the other. But that\'s high level, and fairly
slight in the overall design process.

I\'ve done a fair share of HDL and the complexity of the algorithm can be an
issue simply because in an MCU you basically don\'t care about that
complexity, but you do care very much about speed and the issues of trying
to make a single processor look like it is handling many things in parallel
which is a magic trick in many ways... hard to do without well trained
hands.

Ah good -- since this is apparently a low-quantity thing, working in what
you know is well worth the development savings. And that\'s good
justification for using a less cost-optimized platform.

One of the software guys is always very eager to start optimizing before
the task has even been scoped! That\'s after we moved from a 20 MHz Arduino
MCU to an 80 MHz ST ARM CM4F.

Heh... I did a personal project over the summer, a little DSP (audio
effects) in an ATXMEGA. Going from GCC 8, to hand optimized assembler, I
expanded the DSP functions from 2 delay taps and 1 filter stage, to 6 delay
taps and 2 filter stages (with CPU cycles to spare). avr-gcc is an
abomination at optimizing.

arm-gcc likely does a hell of a lot better.

While I would not want to implement an Ethernet stack in an FPGA, lots of
complex tasks are appropriate. This one is going to convert differential
pressure readings (across an orifice) with temperature and absolute
pressure to measure a flow rate, then integrate that to measure tidal
volume. The calculations will need to be more than 32 bits, so the
dedicated multipliers will be used in extended precision.

Yes, exactly. Doesn\'t sound like much bandwidth -- something that a 8051
could compute probably, but also well suited to FPGA where you have all the
logic right there, ready to go. The Venn diagram has much overlap.

So what is with the top posting??? Your sig messes up the quoting in
addition to every thing else.

Complaining about top posting? In 2020? Hhhahahhahaha!

....Using newsgroups in 2020? Hhhahahhahaha!.. oh...

I\'m not sure who should be more embarrassed, to be honest. We\'re both in a
pretty silly circumstance.

Tim

--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Design
Website: https://www.seventransistorlabs.com/

 

[Ricketty C]

On Thursday, August 27, 2020 at 3:31:29 PM UTC-4, Lasse Langwadt Christensen wrote:

torsdag den 27. august 2020 kl. 20.29.01 UTC+2 skrev Ricketty C:
On Thursday, August 27, 2020 at 12:16:57 PM UTC-4, Lasse Langwadt Christensen wrote:
torsdag den 27. august 2020 kl. 07.58.04 UTC+2 skrev Ricketty C:
I have been working on some circuitry to pull the plug on a motor on reaching an overload condition before it can tear up the gears or break the shaft (which the others on the project have done several times). This shut down was measuring the motor current and pulling the plug, then allowing the MCU to restart it when needed.

Later it was realized a new motor should not be run over 12 volts, so we need something to limit the voltage. A regulator often requires significant head room to work, so I used the same pass transistor to add a voltage output limit.

Now it looks like the entire circuit can be done in an FPGA along with a bunch of other stuff, and not cost any more. The design time will be a lot less as well although the analog circuit is already done in simulation.

Four transistors, two comparators and a pocket full of passives replaced by a few FF and gates inside a chip where they will never be seen, just chug along.


what an the fpga do that the MCU can\'t already do without the hassle of a new project and the develop environment for it?

Correct me if I am wrong, but you can\'t count on software to protect the system if the software crashes. No?


the break input on the ST timer is hardware

But it is controlled and potentially corrupted by the software. In the FPGA the calcs will be done independently of the software and the interface won\'t provide a means of corrupting the alarms. We are looking at having the user interface controlled by the FPGA (it is very simple) reporting the info to the software and using what is needed in the FPGA. So no settings corruption possible, except by the FPGA.

I\'ve been looking at the I/O count and it\'s going to be dicey unless I use a honkin\' big package because there are so few choices that aren\'t BGA. I really hate the QFP144, but that might be what we have to use. Without that there might not be I/Os for the over current control.

if you already control current and speed why do you need to limit voltage?

Who controls current??? We shut down the system if something is wrong and the motor is over current, like when the software crashes and the motor rams into a solid stop.


aren\'t you using an STM32?

https://www.st.com/resource/en/application_note/dm00080497-using-stm32-device-pwm-shutdown-features-for-motor-control-and-digital-power-conversion-stmicroelectronics.pdf

Yes, we are using an H-bridge chip to control the motor.


the appnote explains the break input pins on the ST timers, it disables the timer output/sets them to safe state, all in hardware

That\'s a great feature. Sounds like someone was paying attention. So this would be triggered by an input from the over current logic? I think we are using the PWM to control the motor controller. There are two pins to set direction and a PWM pin to control the duty cycle. I\'ll pass on your info.. Maybe we will be happy with that. Right now they would be happy with the software detecting and stopping the motor, but the early boards they are using have no working current measurement.

SD ADCs take three I/Os. 2 for the LVDS input and one more for the data output to be filtered and used on the input. With multiple ADCs it adds up fast!

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

 

[Klaus Kragelund]

On Friday, August 28, 2020 at 4:50:09 AM UTC+2, Tim Williams wrote:

\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0bd36331-f550-4e8d-942d-db0c448c8274o@googlegroups.com...
No, this design was just started recently. Other designs aren\'t really
relevant.


Ah okay. It wasn\'t specified, so I was careful to accommodate the
possibility that this was updating an old design.


The fact that an MCU has an ADC doesn\'t mean it has to be used. There are
pros and cons to every design decision and they are too numerous to list
for this matter. Suffice to say the desire is to write less C code when
practical.


Oh, is it a small quantity thing? (Production was also unstated.) By that
I mean, I take it the development costs will not amortize effectively, which
might be a good reason to avoid software development.

And also that the client is very confident in their spec, so changes are not
expected -- programming \"in solder\" being a lot more expensive than
software.


The pass transistor can be whatever works best. Presently it is an AOD4185
used as an on/off switch. I was looking at adding more circuitry to make
it a 12 volt limiter to the motor with minimal drop out when the power
source drops below 12 volts. I realized with some elbow grease the whole
circuit could be done in the FPGA.


There are power management chips for that. Check hot-swap and wired-OR
controllers. Though if you need a few more features than they offer, it
might be best to integrate it by hand.

And again, (ab)using a switching reg (in this case, one that can deliver
100% duty cycle) looks attractive, offering a much longer overload period
(e.g., continuous vs. a few ms), might be useful.


Control loops are not my forte, so I would need to handle this carefully.
But that\'s true in analog and digital domains.

The analog version I\'m playing with in LTspice uses a voltage divider with
a small cap across the high side resistors to an op amp inverting input and
a feedback resistor. The non-inverting input is a fixed voltage reference.
This feeds an N-channel FET which pulls down on the P-channel pass FET, the
AOD4185 driving the load.


Eww, tons of excess loop gain! Try heavily degenerating the NFET, and
putting some kind of local feedback around the PFET (source degeneration is
best, but mind the voltage drop; a current-sense amp might be used here,
though costing phase margin).

A charge pump to create an over-the-top rail isn\'t a bad idea, but not
absolutely necessary. That allows a NFET follower (enh mode) -- much more
stable. Depl. mode also an option, but fewer FETs to choose from.

And look at using a higher voltage op-amp, all that extra level shifting is
a mess and why bother when you can do it straight away, y\'know? Then you
can direct drive the PFET /and/ sense its current (from a small shunt) to
get a fast and stable loop.

As for compensation, try R+Cs instead of R (completely wastes loop gain) or
C (wastes phase margin) across the op-amp (out to -in).


Using the rather slow op amp uses elsewhere in the circuit it
under-performs with large transients. Changing that to an AD744 (picked
semi-randomly from the LTspice model list) the circuit works ok but with
some over drive and transients on current changes.


A partial solution to that, is to use source degeneration (again, mind the
voltage drop, this isn\'t always viable) and a fairly tight gate voltage
clamp (maybe a 5V zener?). Yanking down on the drain pulls big current, and
gate capacitance pulls gate voltage down along with it. Zener yanks the
gate back, limiting current. You can go from, say, >100A transients (under
a momentary-shorting load condition), to only a modest factor above the
design current limit (say 2-10x, the ratio of course depending on how much
voltage drop you can afford on the shunt).


You are behind the times. FPGAs can be as little as $2 and can incorporate
functions that can\'t be handled as well in MCUs. In this case it is on the
board because of a perceived difference in approvals. It\'s odd that we are
using this justification because no one has actually said it will be easier
to get approved... odd, but I\'m not running things.


I was just browsing FPGAs the other day, actually; notice I didn\'t specify
what range of FPGAs. I meant FPGAs as a whole. Median parts seem to be in
the low $10s, with the smallest entry-level parts being $2.

MCUs start at a fraction of that, and median parts are a few bucks.

As for approval, some people consider FPGAs to be \"hardware\", but I don\'t
know of any standards about that (for or against). Good luck.

I guess the typical FPGA load configuration at boot with each block defined in SRAM like registers

For a Class B product, one would need to check all those registers at interval in run mode. 60730 defines all the modes that must be tested at interval and at boot

I do not think a typical FPGA has this feature, so it cannot be approved as a HW block

On top of that, the oscillator frequency needs to be checked along with other parameters


Cheers

Klaus

 

[Ricketty C]

On Friday, August 28, 2020 at 2:23:21 AM UTC-4, Klaus Kragelund wrote:

On Friday, August 28, 2020 at 4:50:09 AM UTC+2, Tim Williams wrote:
\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0bd36331-f550-4e8d-942d-db0c448c8274o@googlegroups.com...
No, this design was just started recently. Other designs aren\'t really
relevant.


Ah okay. It wasn\'t specified, so I was careful to accommodate the
possibility that this was updating an old design.


The fact that an MCU has an ADC doesn\'t mean it has to be used. There are
pros and cons to every design decision and they are too numerous to list
for this matter. Suffice to say the desire is to write less C code when
practical.


Oh, is it a small quantity thing? (Production was also unstated.) By that
I mean, I take it the development costs will not amortize effectively, which
might be a good reason to avoid software development.

And also that the client is very confident in their spec, so changes are not
expected -- programming \"in solder\" being a lot more expensive than
software.


The pass transistor can be whatever works best. Presently it is an AOD4185
used as an on/off switch. I was looking at adding more circuitry to make
it a 12 volt limiter to the motor with minimal drop out when the power
source drops below 12 volts. I realized with some elbow grease the whole
circuit could be done in the FPGA.


There are power management chips for that. Check hot-swap and wired-OR
controllers. Though if you need a few more features than they offer, it
might be best to integrate it by hand.

And again, (ab)using a switching reg (in this case, one that can deliver
100% duty cycle) looks attractive, offering a much longer overload period
(e.g., continuous vs. a few ms), might be useful.


Control loops are not my forte, so I would need to handle this carefully.
But that\'s true in analog and digital domains.

The analog version I\'m playing with in LTspice uses a voltage divider with
a small cap across the high side resistors to an op amp inverting input and
a feedback resistor. The non-inverting input is a fixed voltage reference.
This feeds an N-channel FET which pulls down on the P-channel pass FET, the
AOD4185 driving the load.


Eww, tons of excess loop gain! Try heavily degenerating the NFET, and
putting some kind of local feedback around the PFET (source degeneration is
best, but mind the voltage drop; a current-sense amp might be used here,
though costing phase margin).

A charge pump to create an over-the-top rail isn\'t a bad idea, but not
absolutely necessary. That allows a NFET follower (enh mode) -- much more
stable. Depl. mode also an option, but fewer FETs to choose from.

And look at using a higher voltage op-amp, all that extra level shifting is
a mess and why bother when you can do it straight away, y\'know? Then you
can direct drive the PFET /and/ sense its current (from a small shunt) to
get a fast and stable loop.

As for compensation, try R+Cs instead of R (completely wastes loop gain) or
C (wastes phase margin) across the op-amp (out to -in).


Using the rather slow op amp uses elsewhere in the circuit it
under-performs with large transients. Changing that to an AD744 (picked
semi-randomly from the LTspice model list) the circuit works ok but with
some over drive and transients on current changes.


A partial solution to that, is to use source degeneration (again, mind the
voltage drop, this isn\'t always viable) and a fairly tight gate voltage
clamp (maybe a 5V zener?). Yanking down on the drain pulls big current, and
gate capacitance pulls gate voltage down along with it. Zener yanks the
gate back, limiting current. You can go from, say, >100A transients (under
a momentary-shorting load condition), to only a modest factor above the
design current limit (say 2-10x, the ratio of course depending on how much
voltage drop you can afford on the shunt).


You are behind the times. FPGAs can be as little as $2 and can incorporate
functions that can\'t be handled as well in MCUs. In this case it is on the
board because of a perceived difference in approvals. It\'s odd that we are
using this justification because no one has actually said it will be easier
to get approved... odd, but I\'m not running things.


I was just browsing FPGAs the other day, actually; notice I didn\'t specify
what range of FPGAs. I meant FPGAs as a whole. Median parts seem to be in
the low $10s, with the smallest entry-level parts being $2.

MCUs start at a fraction of that, and median parts are a few bucks.

As for approval, some people consider FPGAs to be \"hardware\", but I don\'t
know of any standards about that (for or against). Good luck.



I guess the typical FPGA load configuration at boot with each block defined in SRAM like registers

For a Class B product, one would need to check all those registers at interval in run mode. 60730 defines all the modes that must be tested at interval and at boot

I can\'t view that spec, but it claims to only apply to \"household\" electronics.

I do not think a typical FPGA has this feature, so it cannot be approved as a HW block

On top of that, the oscillator frequency needs to be checked along with other parameters

I don\'t know anything that does meet that requirement. I recall NASA gear that would reboot periodically to deal with soft radiation induced errors. Is that the sort of thing you are talking about?

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

 

[legg]

On Wed, 26 Aug 2020 22:57:58 -0700 (PDT), Ricketty C
<gnuarm.deletethisbit@gmail.com> wrote:

I have been working on some circuitry to pull the plug on a motor on reaching an overload condition before it can tear up the gears or break the shaft (which the others on the project have done several times). This shut down was measuring the motor current and pulling the plug, then allowing the MCU to restart it when needed.

Later it was realized a new motor should not be run over 12 volts, so we need something to limit the voltage. A regulator often requires significant head room to work, so I used the same pass transistor to add a voltage output limit.

Now it looks like the entire circuit can be done in an FPGA along with a bunch of other stuff, and not cost any more. The design time will be a lot less as well although the analog circuit is already done in simulation.

Four transistors, two comparators and a pocket full of passives replaced by a few FF and gates inside a chip where they will never be seen, just chug along.

I\'m sorry Dave, I can\'t do that.

Normally, \'protection\' functions don\'t use the same
hardware (or board tracks/power sources/fusibles) as
the control circuit, never mind the same firmware
or software.

RL

 

[Ricketty C]

On Friday, August 28, 2020 at 9:28:36 AM UTC-4, legg wrote:

On Wed, 26 Aug 2020 22:57:58 -0700 (PDT), Ricketty C
gnuarm.deletethisbit@gmail.com> wrote:

I have been working on some circuitry to pull the plug on a motor on reaching an overload condition before it can tear up the gears or break the shaft (which the others on the project have done several times). This shut down was measuring the motor current and pulling the plug, then allowing the MCU to restart it when needed.

Later it was realized a new motor should not be run over 12 volts, so we need something to limit the voltage. A regulator often requires significant head room to work, so I used the same pass transistor to add a voltage output limit.

Now it looks like the entire circuit can be done in an FPGA along with a bunch of other stuff, and not cost any more. The design time will be a lot less as well although the analog circuit is already done in simulation.

Four transistors, two comparators and a pocket full of passives replaced by a few FF and gates inside a chip where they will never be seen, just chug along.

I\'m sorry Dave, I can\'t do that.

Normally, \'protection\' functions don\'t use the same
hardware (or board tracks/power sources/fusibles) as
the control circuit, never mind the same firmware
or software.

RL

What is the advantage of using a different circuit for the control function from the protection function? The purpose of the protection function is in case the software fails... that is a very different circuit although the same power. If the power goes nothing works. No, we don\'t have a battery backup on the alarm, but I have seen that on another vent. One company provides the plans for a vent they no longer make. It has a LOT of stuff. The alarm sounder has a battery backup, two sounders and a current sensor to know the sounders are getting current.

Damn! That\'s another input!!! I wonder if there is a creative way to use the output as an input at the same time??? Yeah, I bet I can.

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

 

[legg]

On Fri, 28 Aug 2020 08:41:25 -0700 (PDT), Ricketty C
<gnuarm.deletethisbit@gmail.com> wrote:

On Friday, August 28, 2020 at 9:28:36 AM UTC-4, legg wrote:
On Wed, 26 Aug 2020 22:57:58 -0700 (PDT), Ricketty C
gnuarm.deletethisbit@gmail.com> wrote:

I have been working on some circuitry to pull the plug on a motor on reaching an overload condition before it can tear up the gears or break the shaft (which the others on the project have done several times). This shut down was measuring the motor current and pulling the plug, then allowing the MCU to restart it when needed.

Later it was realized a new motor should not be run over 12 volts, so we need something to limit the voltage. A regulator often requires significant head room to work, so I used the same pass transistor to add a voltage output limit.

Now it looks like the entire circuit can be done in an FPGA along with a bunch of other stuff, and not cost any more. The design time will be a lot less as well although the analog circuit is already done in simulation.

Four transistors, two comparators and a pocket full of passives replaced by a few FF and gates inside a chip where they will never be seen, just chug along.

I\'m sorry Dave, I can\'t do that.

Normally, \'protection\' functions don\'t use the same
hardware (or board tracks/power sources/fusibles) as
the control circuit, never mind the same firmware
or software.

RL

What is the advantage of using a different circuit for the control function from the protection function? The purpose of the protection function is in case the software fails... that is a very different circuit although the same power. If the power goes nothing works. No, we don\'t have a battery backup on the alarm, but I have seen that on another vent. One company provides the plans for a vent they no longer make. It has a LOT of stuff. The alarm sounder has a battery backup, two sounders and a current sensor to know the sounders are getting current.

Damn! That\'s another input!!! I wonder if there is a creative way to use the output as an input at the same time??? Yeah, I bet I can.

Takes some thought and care to make protection circuitry
that always does its job, without degrading performance.

It\'s not fool-proof. A protection function should perform,
regardless of the failure mechanism, assuming single fault.

No point in getting more elaborate, unless it\'s uninsurable,
or ~ nuclear.

RL

 

[Klaus Kragelund]

On Friday, August 28, 2020 at 10:07:35 AM UTC+2, Ricketty C wrote:

On Friday, August 28, 2020 at 2:23:21 AM UTC-4, Klaus Kragelund wrote:
On Friday, August 28, 2020 at 4:50:09 AM UTC+2, Tim Williams wrote:
\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0bd36331-f550-4e8d-942d-db0c448c8274o@googlegroups.com...
No, this design was just started recently. Other designs aren\'t really
relevant.


Ah okay. It wasn\'t specified, so I was careful to accommodate the
possibility that this was updating an old design.


The fact that an MCU has an ADC doesn\'t mean it has to be used. There are
pros and cons to every design decision and they are too numerous to list
for this matter. Suffice to say the desire is to write less C code when
practical.


Oh, is it a small quantity thing? (Production was also unstated.) By that
I mean, I take it the development costs will not amortize effectively, which
might be a good reason to avoid software development.

And also that the client is very confident in their spec, so changes are not
expected -- programming \"in solder\" being a lot more expensive than
software.


The pass transistor can be whatever works best. Presently it is an AOD4185
used as an on/off switch. I was looking at adding more circuitry to make
it a 12 volt limiter to the motor with minimal drop out when the power
source drops below 12 volts. I realized with some elbow grease the whole
circuit could be done in the FPGA.


There are power management chips for that. Check hot-swap and wired-OR
controllers. Though if you need a few more features than they offer, it
might be best to integrate it by hand.

And again, (ab)using a switching reg (in this case, one that can deliver
100% duty cycle) looks attractive, offering a much longer overload period
(e.g., continuous vs. a few ms), might be useful.


Control loops are not my forte, so I would need to handle this carefully.
But that\'s true in analog and digital domains.

The analog version I\'m playing with in LTspice uses a voltage divider with
a small cap across the high side resistors to an op amp inverting input and
a feedback resistor. The non-inverting input is a fixed voltage reference.
This feeds an N-channel FET which pulls down on the P-channel pass FET, the
AOD4185 driving the load.


Eww, tons of excess loop gain! Try heavily degenerating the NFET, and
putting some kind of local feedback around the PFET (source degeneration is
best, but mind the voltage drop; a current-sense amp might be used here,
though costing phase margin).

A charge pump to create an over-the-top rail isn\'t a bad idea, but not
absolutely necessary. That allows a NFET follower (enh mode) -- much more
stable. Depl. mode also an option, but fewer FETs to choose from.

And look at using a higher voltage op-amp, all that extra level shifting is
a mess and why bother when you can do it straight away, y\'know? Then you
can direct drive the PFET /and/ sense its current (from a small shunt) to
get a fast and stable loop.

As for compensation, try R+Cs instead of R (completely wastes loop gain) or
C (wastes phase margin) across the op-amp (out to -in).


Using the rather slow op amp uses elsewhere in the circuit it
under-performs with large transients. Changing that to an AD744 (picked
semi-randomly from the LTspice model list) the circuit works ok but with
some over drive and transients on current changes.


A partial solution to that, is to use source degeneration (again, mind the
voltage drop, this isn\'t always viable) and a fairly tight gate voltage
clamp (maybe a 5V zener?). Yanking down on the drain pulls big current, and
gate capacitance pulls gate voltage down along with it. Zener yanks the
gate back, limiting current. You can go from, say, >100A transients (under
a momentary-shorting load condition), to only a modest factor above the
design current limit (say 2-10x, the ratio of course depending on how much
voltage drop you can afford on the shunt).


You are behind the times. FPGAs can be as little as $2 and can incorporate
functions that can\'t be handled as well in MCUs. In this case it is on the
board because of a perceived difference in approvals. It\'s odd that we are
using this justification because no one has actually said it will be easier
to get approved... odd, but I\'m not running things.


I was just browsing FPGAs the other day, actually; notice I didn\'t specify
what range of FPGAs. I meant FPGAs as a whole. Median parts seem to be in
the low $10s, with the smallest entry-level parts being $2.

MCUs start at a fraction of that, and median parts are a few bucks.

As for approval, some people consider FPGAs to be \"hardware\", but I don\'t
know of any standards about that (for or against). Good luck.



I guess the typical FPGA load configuration at boot with each block defined in SRAM like registers

For a Class B product, one would need to check all those registers at interval in run mode. 60730 defines all the modes that must be tested at interval and at boot

I can\'t view that spec, but it claims to only apply to \"household\" electronics.

Yes, and that covers pretty much any electronics in your home or office

I do not think a typical FPGA has this feature, so it cannot be approved as a HW block

On top of that, the oscillator frequency needs to be checked along with other parameters

I don\'t know anything that does meet that requirement. I recall NASA gear that would reboot periodically to deal with soft radiation induced errors. Is that the sort of thing you are talking about?

This is a requirement for any equipment with SW that control an element that can potentially heat up to unsafe levels. So in this case, a motor for a household gadget. In our case, it\'s a circulation pump

So, nothing to do with NASA, this is for \"standard\" electronics

About the oscillator check, that can be done quite simple inside the controller. You feed the main clock to a timer, and you then compare the main clock with say the watchdog clock/timer. They must not differ much, if they do, you pull the reset flag

Same for code check. During compile time, you calculate the code checksum. During runtime, the code checksum is calculated every 10 seconds. If it differs, you pull reset

 

[Klaus Kragelund]

On Friday, August 28, 2020 at 5:41:33 PM UTC+2, Ricketty C wrote:

On Friday, August 28, 2020 at 9:28:36 AM UTC-4, legg wrote:
On Wed, 26 Aug 2020 22:57:58 -0700 (PDT), Ricketty C
gnuarm.deletethisbit@gmail.com> wrote:

I have been working on some circuitry to pull the plug on a motor on reaching an overload condition before it can tear up the gears or break the shaft (which the others on the project have done several times). This shut down was measuring the motor current and pulling the plug, then allowing the MCU to restart it when needed.

Later it was realized a new motor should not be run over 12 volts, so we need something to limit the voltage. A regulator often requires significant head room to work, so I used the same pass transistor to add a voltage output limit.

Now it looks like the entire circuit can be done in an FPGA along with a bunch of other stuff, and not cost any more. The design time will be a lot less as well although the analog circuit is already done in simulation.

Four transistors, two comparators and a pocket full of passives replaced by a few FF and gates inside a chip where they will never be seen, just chug along.

I\'m sorry Dave, I can\'t do that.

Normally, \'protection\' functions don\'t use the same
hardware (or board tracks/power sources/fusibles) as
the control circuit, never mind the same firmware
or software.

RL

What is the advantage of using a different circuit for the control function from the protection function? The purpose of the protection function is in case the software fails... that is a very different circuit although the same power.

You want different function paths. So that a fault in a system in a circuit is more likely to occur if the same circuit is duplicated in another path. They are then not separated and the probability of hazard is higher

 

[Ricketty C]

On Friday, August 28, 2020 at 7:08:41 PM UTC-4, Klaus Kragelund wrote:

On Friday, August 28, 2020 at 10:07:35 AM UTC+2, Ricketty C wrote:
On Friday, August 28, 2020 at 2:23:21 AM UTC-4, Klaus Kragelund wrote:
On Friday, August 28, 2020 at 4:50:09 AM UTC+2, Tim Williams wrote:
\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0bd36331-f550-4e8d-942d-db0c448c8274o@googlegroups.com...
No, this design was just started recently. Other designs aren\'t really
relevant.


Ah okay. It wasn\'t specified, so I was careful to accommodate the
possibility that this was updating an old design.


The fact that an MCU has an ADC doesn\'t mean it has to be used. There are
pros and cons to every design decision and they are too numerous to list
for this matter. Suffice to say the desire is to write less C code when
practical.


Oh, is it a small quantity thing? (Production was also unstated.) By that
I mean, I take it the development costs will not amortize effectively, which
might be a good reason to avoid software development.

And also that the client is very confident in their spec, so changes are not
expected -- programming \"in solder\" being a lot more expensive than
software.


The pass transistor can be whatever works best. Presently it is an AOD4185
used as an on/off switch. I was looking at adding more circuitry to make
it a 12 volt limiter to the motor with minimal drop out when the power
source drops below 12 volts. I realized with some elbow grease the whole
circuit could be done in the FPGA.


There are power management chips for that. Check hot-swap and wired-OR
controllers. Though if you need a few more features than they offer, it
might be best to integrate it by hand.

And again, (ab)using a switching reg (in this case, one that can deliver
100% duty cycle) looks attractive, offering a much longer overload period
(e.g., continuous vs. a few ms), might be useful.


Control loops are not my forte, so I would need to handle this carefully.
But that\'s true in analog and digital domains.

The analog version I\'m playing with in LTspice uses a voltage divider with
a small cap across the high side resistors to an op amp inverting input and
a feedback resistor. The non-inverting input is a fixed voltage reference.
This feeds an N-channel FET which pulls down on the P-channel pass FET, the
AOD4185 driving the load.


Eww, tons of excess loop gain! Try heavily degenerating the NFET, and
putting some kind of local feedback around the PFET (source degeneration is
best, but mind the voltage drop; a current-sense amp might be used here,
though costing phase margin).

A charge pump to create an over-the-top rail isn\'t a bad idea, but not
absolutely necessary. That allows a NFET follower (enh mode) -- much more
stable. Depl. mode also an option, but fewer FETs to choose from.

And look at using a higher voltage op-amp, all that extra level shifting is
a mess and why bother when you can do it straight away, y\'know? Then you
can direct drive the PFET /and/ sense its current (from a small shunt) to
get a fast and stable loop.

As for compensation, try R+Cs instead of R (completely wastes loop gain) or
C (wastes phase margin) across the op-amp (out to -in).


Using the rather slow op amp uses elsewhere in the circuit it
under-performs with large transients. Changing that to an AD744 (picked
semi-randomly from the LTspice model list) the circuit works ok but with
some over drive and transients on current changes.


A partial solution to that, is to use source degeneration (again, mind the
voltage drop, this isn\'t always viable) and a fairly tight gate voltage
clamp (maybe a 5V zener?). Yanking down on the drain pulls big current, and
gate capacitance pulls gate voltage down along with it. Zener yanks the
gate back, limiting current. You can go from, say, >100A transients (under
a momentary-shorting load condition), to only a modest factor above the
design current limit (say 2-10x, the ratio of course depending on how much
voltage drop you can afford on the shunt).


You are behind the times. FPGAs can be as little as $2 and can incorporate
functions that can\'t be handled as well in MCUs. In this case it is on the
board because of a perceived difference in approvals. It\'s odd that we are
using this justification because no one has actually said it will be easier
to get approved... odd, but I\'m not running things.


I was just browsing FPGAs the other day, actually; notice I didn\'t specify
what range of FPGAs. I meant FPGAs as a whole. Median parts seem to be in
the low $10s, with the smallest entry-level parts being $2.

MCUs start at a fraction of that, and median parts are a few bucks.

As for approval, some people consider FPGAs to be \"hardware\", but I don\'t
know of any standards about that (for or against). Good luck.



I guess the typical FPGA load configuration at boot with each block defined in SRAM like registers

For a Class B product, one would need to check all those registers at interval in run mode. 60730 defines all the modes that must be tested at interval and at boot

I can\'t view that spec, but it claims to only apply to \"household\" electronics.

Yes, and that covers pretty much any electronics in your home or office

Which has nothing to do with ventilators.

In 60730 what exactly is a class B product?

I do not think a typical FPGA has this feature, so it cannot be approved as a HW block

On top of that, the oscillator frequency needs to be checked along with other parameters

I don\'t know anything that does meet that requirement. I recall NASA gear that would reboot periodically to deal with soft radiation induced errors. Is that the sort of thing you are talking about?


This is a requirement for any equipment with SW that control an element that can potentially heat up to unsafe levels. So in this case, a motor for a household gadget. In our case, it\'s a circulation pump

So, nothing to do with NASA, this is for \"standard\" electronics

Fine, but what electronics with digital \"stuff\" meets this requirement? How do they meet it other than just not using digital \"stuff\"?


> About the oscillator check, that can be done quite simple inside the controller. You feed the main clock to a timer, and you then compare the main clock with say the watchdog clock/timer. They must not differ much, if they do, you pull the reset flag

Who defines \"not much\"???


> Same for code check. During compile time, you calculate the code checksum.. During runtime, the code checksum is calculated every 10 seconds. If it differs, you pull reset

Ok then, reloading the config would meet that requirement. So the NASA approach for FPGAs works well.

In this case I know of no such requirement. I think people accept that such errors are sufficiently rare. In our case the software and firmware can keep an eye on one another. If either sees something wonky the entire unit gets rebooted. The MCU can reboot the FPGA after the FPGA has rebooted the MCU.

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

 

[whit3rd]

On Friday, August 28, 2020 at 8:41:33 AM UTC-7, Ricketty C wrote:

> What is the advantage of using a different circuit for the control function from the protection function? The purpose of the protection function is in case the software fails...

That\'s not the end of the story, though; safety-related functions really should be tested,
and software testing is... a poorly characterized process. It costs a LOT of money, brains,
and time. WOMBAT is the applicable acronym.

 

[Tabby]

On Friday, 28 August 2020 03:49:38 UTC+1, Tim Williams wrote:

\"Tabby\" <tabbypurr> wrote in message
news:9e465888-fc9b-4001-99fb-6be7e5d7887do@googlegroups.com...
On Thursday, 27 August 2020 14:46:27 UTC+1, Tim Williams wrote:

Replac...ing? You\'re a couple decades late to the party there...

Digital has been gradually partly replacing analogue since the 1960s. It
will never wipe analogue out though.


Well, by definition. Digital is a subset of analog.

Most EEs don\'t understand that

Long, long gone are the days of big boards stuffed with op-amps (or with
discrete logic, for that matter). More and more is integrated into MCUs,
SoCs and such. They often still need op-amps for AFE, power amps for
output, power switches, glue logic -- you\'re never going to eliminate all of
those, in all situations. 2N3904 and CD4011 will never die, among many
others. That\'s not the point, the point is everything inbetween.

Tim

I can see the 4011 etc being replaced by a multi-function logic IC. As transistors shink & si area cost falls it makes more sense at some point to throw a handful of logic in 1 IC & shrink the range.


NT

 

[Bill Sloman]

On Saturday, August 29, 2020 at 1:08:33 PM UTC+10, Tabby wrote:

On Friday, 28 August 2020 03:49:38 UTC+1, Tim Williams wrote:
\"Tabby\" <tabbypurr> wrote in message
news:9e465888-fc9b-4001...@googlegroups.com...
On Thursday, 27 August 2020 14:46:27 UTC+1, Tim Williams wrote:

<snip>

Long, long gone are the days of big boards stuffed with op-amps (or with
discrete logic, for that matter). More and more is integrated into MCUs,
SoCs and such. They often still need op-amps for AFE, power amps for
output, power switches, glue logic -- you\'re never going to eliminate all of
those, in all situations. 2N3904 and CD4011 will never die, among many
others. That\'s not the point, the point is everything in between.

I can see the 4011 etc being replaced by a multi-function logic IC. As transistors shink & si area cost falls it makes more sense at some point to throw a handful of logic in 1 IC & shrink the range.

NT can see that because he\'s forgotten that the CD4011 can handled rail voltages up to 18V. Getting a programmable logic chip that cope with that kind of voltage isn\'t easy.

--
Bill Sloman, Sydney

 

[Tim Williams]

\"Bill Sloman\" <bill.sloman@ieee.org> wrote in message
news:a6c8031e-bb57-41bf-adfb-1a482bc94b7en@googlegroups.com...

NT can see that because he\'s forgotten that the CD4011 can handled rail
voltages up to 18V. Getting a programmable logic chip that cope with that
kind of voltage isn\'t easy.

Although, didn\'t the earliest EPROMs (and PLDs) need something absurd like
27.5V for programming?

Not that general logic functions might continue working that high.

Hm, never did read up on how that was possible; surely they weren\'t fabbing
different voltage domains back then? That, or most EPROMs (or the older
ones, at least) could actually withstand ludicrous voltages, just not meet
spec (or function at all) up there? Hmm, never did test one for VDD
breakdown voltage...

Tim

--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Design
Website: https://www.seventransistorlabs.com/

 

[Ricketty C]

On Saturday, August 29, 2020 at 12:07:36 PM UTC-4, Tim Williams wrote:

\"Bill Sloman\" <bill.sloman@ieee.org> wrote in message
news:a6c8031e-bb57-41bf-adfb-1a482bc94b7en@googlegroups.com...

NT can see that because he\'s forgotten that the CD4011 can handled rail
voltages up to 18V. Getting a programmable logic chip that cope with that
kind of voltage isn\'t easy.


Although, didn\'t the earliest EPROMs (and PLDs) need something absurd like
27.5V for programming?

Not that general logic functions might continue working that high.

Hm, never did read up on how that was possible; surely they weren\'t fabbing
different voltage domains back then? That, or most EPROMs (or the older
ones, at least) could actually withstand ludicrous voltages, just not meet
spec (or function at all) up there? Hmm, never did test one for VDD
breakdown voltage...

I believe EPROM always required a high voltage, they just made in on chip after the 1702A. The programmer for those things were atrocious. You had to pull the data and address lines to high voltages.

Hey, that\'s not a word you get to use every day, \"atrocious\" indeed!

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

 

[Klaus Kragelund]

On Saturday, August 29, 2020 at 3:32:52 AM UTC+2, Ricketty C wrote:

On Friday, August 28, 2020 at 7:08:41 PM UTC-4, Klaus Kragelund wrote:
On Friday, August 28, 2020 at 10:07:35 AM UTC+2, Ricketty C wrote:
On Friday, August 28, 2020 at 2:23:21 AM UTC-4, Klaus Kragelund wrote:
On Friday, August 28, 2020 at 4:50:09 AM UTC+2, Tim Williams wrote:
\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0bd36331-f550-4e8d-942d-db0c448c8274o@googlegroups.com...
No, this design was just started recently. Other designs aren\'t really
relevant.


Ah okay. It wasn\'t specified, so I was careful to accommodate the
possibility that this was updating an old design.


The fact that an MCU has an ADC doesn\'t mean it has to be used. There are
pros and cons to every design decision and they are too numerous to list
for this matter. Suffice to say the desire is to write less C code when
practical.


Oh, is it a small quantity thing? (Production was also unstated.) By that
I mean, I take it the development costs will not amortize effectively, which
might be a good reason to avoid software development.

And also that the client is very confident in their spec, so changes are not
expected -- programming \"in solder\" being a lot more expensive than
software.


The pass transistor can be whatever works best. Presently it is an AOD4185
used as an on/off switch. I was looking at adding more circuitry to make
it a 12 volt limiter to the motor with minimal drop out when the power
source drops below 12 volts. I realized with some elbow grease the whole
circuit could be done in the FPGA.


There are power management chips for that. Check hot-swap and wired-OR
controllers. Though if you need a few more features than they offer, it
might be best to integrate it by hand.

And again, (ab)using a switching reg (in this case, one that can deliver
100% duty cycle) looks attractive, offering a much longer overload period
(e.g., continuous vs. a few ms), might be useful.


Control loops are not my forte, so I would need to handle this carefully.
But that\'s true in analog and digital domains.

The analog version I\'m playing with in LTspice uses a voltage divider with
a small cap across the high side resistors to an op amp inverting input and
a feedback resistor. The non-inverting input is a fixed voltage reference.
This feeds an N-channel FET which pulls down on the P-channel pass FET, the
AOD4185 driving the load.


Eww, tons of excess loop gain! Try heavily degenerating the NFET, and
putting some kind of local feedback around the PFET (source degeneration is
best, but mind the voltage drop; a current-sense amp might be used here,
though costing phase margin).

A charge pump to create an over-the-top rail isn\'t a bad idea, but not
absolutely necessary. That allows a NFET follower (enh mode) -- much more
stable. Depl. mode also an option, but fewer FETs to choose from..

And look at using a higher voltage op-amp, all that extra level shifting is
a mess and why bother when you can do it straight away, y\'know? Then you
can direct drive the PFET /and/ sense its current (from a small shunt) to
get a fast and stable loop.

As for compensation, try R+Cs instead of R (completely wastes loop gain) or
C (wastes phase margin) across the op-amp (out to -in).


Using the rather slow op amp uses elsewhere in the circuit it
under-performs with large transients. Changing that to an AD744 (picked
semi-randomly from the LTspice model list) the circuit works ok but with
some over drive and transients on current changes.


A partial solution to that, is to use source degeneration (again, mind the
voltage drop, this isn\'t always viable) and a fairly tight gate voltage
clamp (maybe a 5V zener?). Yanking down on the drain pulls big current, and
gate capacitance pulls gate voltage down along with it. Zener yanks the
gate back, limiting current. You can go from, say, >100A transients (under
a momentary-shorting load condition), to only a modest factor above the
design current limit (say 2-10x, the ratio of course depending on how much
voltage drop you can afford on the shunt).


You are behind the times. FPGAs can be as little as $2 and can incorporate
functions that can\'t be handled as well in MCUs. In this case it is on the
board because of a perceived difference in approvals. It\'s odd that we are
using this justification because no one has actually said it will be easier
to get approved... odd, but I\'m not running things.


I was just browsing FPGAs the other day, actually; notice I didn\'t specify
what range of FPGAs. I meant FPGAs as a whole. Median parts seem to be in
the low $10s, with the smallest entry-level parts being $2.

MCUs start at a fraction of that, and median parts are a few bucks.

As for approval, some people consider FPGAs to be \"hardware\", but I don\'t
know of any standards about that (for or against). Good luck.



I guess the typical FPGA load configuration at boot with each block defined in SRAM like registers

For a Class B product, one would need to check all those registers at interval in run mode. 60730 defines all the modes that must be tested at interval and at boot

I can\'t view that spec, but it claims to only apply to \"household\" electronics.

Yes, and that covers pretty much any electronics in your home or office

Which has nothing to do with ventilators.

Sure it has. A ventilator, a pump, an air condition. Anything with a motor in it, or any product that has a power level that in case of a fault could heat a component up and exceed insulation specs or outright burst into flames is covered.

Say one of your FETs that controls the motor shorts or operates in linear mode that would not trigger a safety function will heat the motor up to above 150 degrees for Class F wire, would then fail the UL/IEC test

In case of a motor controlled with SW, there needs to be safeguards that makes sure the SW behaves correctly, even when you introduce errors into the microcontroller. Bit flip, timer going berserk, oscillator outside ranges etc

We spend a LOT of time on these faults, component breakdown tests, to be sure the product is safe

In 60730 what exactly is a class B product?

Any household product. What standard have the approval body told you that you should comply to?

I do not think a typical FPGA has this feature, so it cannot be approved as a HW block

On top of that, the oscillator frequency needs to be checked along with other parameters

I don\'t know anything that does meet that requirement. I recall NASA gear that would reboot periodically to deal with soft radiation induced errors. Is that the sort of thing you are talking about?


This is a requirement for any equipment with SW that control an element that can potentially heat up to unsafe levels. So in this case, a motor for a household gadget. In our case, it\'s a circulation pump

So, nothing to do with NASA, this is for \"standard\" electronics

Fine, but what electronics with digital \"stuff\" meets this requirement? How do they meet it other than just not using digital \"stuff\"?

Using Class B SW techniques. Like those described in this document from ST:

https://www.st.com/resource/en/application_note/dm00105610-guidelines-for-obtaining-ulcsaiec-607301603351-class-b-certification-in-any-stm32-application-stmicroelectronics.pdf

About the oscillator check, that can be done quite simple inside the controller. You feed the main clock to a timer, and you then compare the main clock with say the watchdog clock/timer. They must not differ much, if they do, you pull the reset flag

Who defines \"not much\"???

You do. You check that at the maximum range that the product is still safe. So if your clock will impact your product to have double heat consumption at half clock frequency and that is a problem, then that is your limit

Same for code check. During compile time, you calculate the code checksum. During runtime, the code checksum is calculated every 10 seconds. If it differs, you pull reset

Ok then, reloading the config would meet that requirement. So the NASA approach for FPGAs works well.

Yes

In this case I know of no such requirement. I think people accept that such errors are sufficiently rare. In our case the software and firmware can keep an eye on one another. If either sees something wonky the entire unit gets rebooted. The MCU can reboot the FPGA after the FPGA has rebooted the MCU.

That does not cut it. The approval body needs to approve your SW. If you do not have approved Class B SW, then your micro is considered to be one big fault generator. If you have your checks in place, then you can get it approved. The advantage of using the libraries from ST or Microchip and others is that they are preapproved, so you only need to argue about the application layer when you talk to the approval body

Don\'t you do component breakdown tests and evaluation of Critical Components (those that need UL/IEC approval, since they are connected to the line, Y caps, X caps, varistors etc)

Cheers

Klaus

 

[Ricketty C]

On Saturday, August 29, 2020 at 6:20:30 PM UTC-4, Klaus Kragelund wrote:

On Saturday, August 29, 2020 at 3:32:52 AM UTC+2, Ricketty C wrote:
On Friday, August 28, 2020 at 7:08:41 PM UTC-4, Klaus Kragelund wrote:
On Friday, August 28, 2020 at 10:07:35 AM UTC+2, Ricketty C wrote:
On Friday, August 28, 2020 at 2:23:21 AM UTC-4, Klaus Kragelund wrote:
On Friday, August 28, 2020 at 4:50:09 AM UTC+2, Tim Williams wrote:
\"Ricketty C\" <gnuarm.deletethisbit@gmail.com> wrote in message
news:0bd36331-f550-4e8d-942d-db0c448c8274o@googlegroups.com...
No, this design was just started recently. Other designs aren\'t really
relevant.


Ah okay. It wasn\'t specified, so I was careful to accommodate the
possibility that this was updating an old design.


The fact that an MCU has an ADC doesn\'t mean it has to be used.. There are
pros and cons to every design decision and they are too numerous to list
for this matter. Suffice to say the desire is to write less C code when
practical.


Oh, is it a small quantity thing? (Production was also unstated.) By that
I mean, I take it the development costs will not amortize effectively, which
might be a good reason to avoid software development.

And also that the client is very confident in their spec, so changes are not
expected -- programming \"in solder\" being a lot more expensive than
software.


The pass transistor can be whatever works best. Presently it is an AOD4185
used as an on/off switch. I was looking at adding more circuitry to make
it a 12 volt limiter to the motor with minimal drop out when the power
source drops below 12 volts. I realized with some elbow grease the whole
circuit could be done in the FPGA.


There are power management chips for that. Check hot-swap and wired-OR
controllers. Though if you need a few more features than they offer, it
might be best to integrate it by hand.

And again, (ab)using a switching reg (in this case, one that can deliver
100% duty cycle) looks attractive, offering a much longer overload period
(e.g., continuous vs. a few ms), might be useful.


Control loops are not my forte, so I would need to handle this carefully.
But that\'s true in analog and digital domains.

The analog version I\'m playing with in LTspice uses a voltage divider with
a small cap across the high side resistors to an op amp inverting input and
a feedback resistor. The non-inverting input is a fixed voltage reference.
This feeds an N-channel FET which pulls down on the P-channel pass FET, the
AOD4185 driving the load.


Eww, tons of excess loop gain! Try heavily degenerating the NFET, and
putting some kind of local feedback around the PFET (source degeneration is
best, but mind the voltage drop; a current-sense amp might be used here,
though costing phase margin).

A charge pump to create an over-the-top rail isn\'t a bad idea, but not
absolutely necessary. That allows a NFET follower (enh mode) -- much more
stable. Depl. mode also an option, but fewer FETs to choose from.

And look at using a higher voltage op-amp, all that extra level shifting is
a mess and why bother when you can do it straight away, y\'know? Then you
can direct drive the PFET /and/ sense its current (from a small shunt) to
get a fast and stable loop.

As for compensation, try R+Cs instead of R (completely wastes loop gain) or
C (wastes phase margin) across the op-amp (out to -in).


Using the rather slow op amp uses elsewhere in the circuit it
under-performs with large transients. Changing that to an AD744 (picked
semi-randomly from the LTspice model list) the circuit works ok but with
some over drive and transients on current changes.


A partial solution to that, is to use source degeneration (again, mind the
voltage drop, this isn\'t always viable) and a fairly tight gate voltage
clamp (maybe a 5V zener?). Yanking down on the drain pulls big current, and
gate capacitance pulls gate voltage down along with it. Zener yanks the
gate back, limiting current. You can go from, say, >100A transients (under
a momentary-shorting load condition), to only a modest factor above the
design current limit (say 2-10x, the ratio of course depending on how much
voltage drop you can afford on the shunt).


You are behind the times. FPGAs can be as little as $2 and can incorporate
functions that can\'t be handled as well in MCUs. In this case it is on the
board because of a perceived difference in approvals. It\'s odd that we are
using this justification because no one has actually said it will be easier
to get approved... odd, but I\'m not running things.


I was just browsing FPGAs the other day, actually; notice I didn\'t specify
what range of FPGAs. I meant FPGAs as a whole. Median parts seem to be in
the low $10s, with the smallest entry-level parts being $2.

MCUs start at a fraction of that, and median parts are a few bucks.

As for approval, some people consider FPGAs to be \"hardware\", but I don\'t
know of any standards about that (for or against). Good luck.



I guess the typical FPGA load configuration at boot with each block defined in SRAM like registers

For a Class B product, one would need to check all those registers at interval in run mode. 60730 defines all the modes that must be tested at interval and at boot

I can\'t view that spec, but it claims to only apply to \"household\" electronics.

Yes, and that covers pretty much any electronics in your home or office

Which has nothing to do with ventilators.


Sure it has. A ventilator, a pump, an air condition. Anything with a motor in it, or any product that has a power level that in case of a fault could heat a component up and exceed insulation specs or outright burst into flames is covered.

Say one of your FETs that controls the motor shorts or operates in linear mode that would not trigger a safety function will heat the motor up to above 150 degrees for Class F wire, would then fail the UL/IEC test

In case of a motor controlled with SW, there needs to be safeguards that makes sure the SW behaves correctly, even when you introduce errors into the microcontroller. Bit flip, timer going berserk, oscillator outside ranges etc

We spend a LOT of time on these faults, component breakdown tests, to be sure the product is safe

In 60730 what exactly is a class B product?


Any household product. What standard have the approval body told you that you should comply to?


I do not think a typical FPGA has this feature, so it cannot be approved as a HW block

On top of that, the oscillator frequency needs to be checked along with other parameters

I don\'t know anything that does meet that requirement. I recall NASA gear that would reboot periodically to deal with soft radiation induced errors. Is that the sort of thing you are talking about?


This is a requirement for any equipment with SW that control an element that can potentially heat up to unsafe levels. So in this case, a motor for a household gadget. In our case, it\'s a circulation pump

So, nothing to do with NASA, this is for \"standard\" electronics

Fine, but what electronics with digital \"stuff\" meets this requirement? How do they meet it other than just not using digital \"stuff\"?



Using Class B SW techniques. Like those described in this document from ST:

https://www.st.com/resource/en/application_note/dm00105610-guidelines-for-obtaining-ulcsaiec-607301603351-class-b-certification-in-any-stm32-application-stmicroelectronics.pdf


About the oscillator check, that can be done quite simple inside the controller. You feed the main clock to a timer, and you then compare the main clock with say the watchdog clock/timer. They must not differ much, if they do, you pull the reset flag

Who defines \"not much\"???


You do. You check that at the maximum range that the product is still safe. So if your clock will impact your product to have double heat consumption at half clock frequency and that is a problem, then that is your limit


Same for code check. During compile time, you calculate the code checksum. During runtime, the code checksum is calculated every 10 seconds. If it differs, you pull reset

Ok then, reloading the config would meet that requirement. So the NASA approach for FPGAs works well.


Yes

In this case I know of no such requirement. I think people accept that such errors are sufficiently rare. In our case the software and firmware can keep an eye on one another. If either sees something wonky the entire unit gets rebooted. The MCU can reboot the FPGA after the FPGA has rebooted the MCU.


That does not cut it. The approval body needs to approve your SW. If you do not have approved Class B SW, then your micro is considered to be one big fault generator. If you have your checks in place, then you can get it approved. The advantage of using the libraries from ST or Microchip and others is that they are preapproved, so you only need to argue about the application layer when you talk to the approval body

Don\'t you do component breakdown tests and evaluation of Critical Components (those that need UL/IEC approval, since they are connected to the line, Y caps, X caps, varistors etc)

Cheers

Klaus

Normally I would welcome such a discussion, but you are not getting it. The standard you are referring to does not apply to medical equipment. The medical standard may require something similar, but that will be the medical standard requirement, not the standard you are referring to which may be very different. The software hazards are not relevant if they are prevented from materializing because the hardware prevents them.

I\'m not interested in going round and round about this. You need to understand what I\'m saying and you don\'t seem to.

--

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209

 

[Tabby]

\"Bill Sloman\" <bill.sloman@ieee.org> wrote in message
news:a6c8031e-bb57-41bf-adfb-1a482bc94b7en@googlegroups.com...

NT can see that because he\'s forgotten that the CD4011 can handled rail
voltages up to 18V. Getting a programmable logic chip that cope with that
kind of voltage isn\'t easy.

whoosh as usual