Supervisory circuit...

D

Don Y

Guest
I need to monitor/control several analog signals. I have
very little board space to do so and, hopefully, monies.

For a variety of reasons, an MCU will at least need to be
part of the solution (as there needs to be sequencing,
communication and other conditional logic). But, the
\"processing\" needs are tiny enough that a dog of an MCU
could likely be coerced into functioning.

[The downside is the addition of a \"programming\" step
at manufacture]

I was hoping to use single pins for measurement and control.
E.g., drive pin low to disable a poser supply; let it float to
the voltage of the monitored supply to measure the actual
supply voltage. Repeat for each controlled supply, etc.
(obviously, no need to \"disable\" a temperature input)

But, this seems to add a fair number of passives that might
eat up more real estate than the pin\'s saving gains!

And, ensuring that the \"output\" is driven low during power
sequencing of the \"supervisor\" presents another opportunity
for component creep.

Any other potential downsides to this sort of hack?
 
On Sunday, November 8, 2020 at 5:24:54 PM UTC-5, Don Y wrote:
I need to monitor/control several analog signals. I have
very little board space to do so and, hopefully, monies.

For a variety of reasons, an MCU will at least need to be
part of the solution (as there needs to be sequencing,
communication and other conditional logic). But, the
\"processing\" needs are tiny enough that a dog of an MCU
could likely be coerced into functioning.

[The downside is the addition of a \"programming\" step
at manufacture]

I was hoping to use single pins for measurement and control.
E.g., drive pin low to disable a poser supply; let it float to
the voltage of the monitored supply to measure the actual
supply voltage. Repeat for each controlled supply, etc.
(obviously, no need to \"disable\" a temperature input)

But, this seems to add a fair number of passives that might
eat up more real estate than the pin\'s saving gains!

And, ensuring that the \"output\" is driven low during power
sequencing of the \"supervisor\" presents another opportunity
for component creep.

Any other potential downsides to this sort of hack?

Not completely sure what you are describing, but it sounds like you are pulling up a control signal for the PSU and also using it to measure the PSU output on that same pin. But I don\'t understand how this is not saving real estate. If you provide these function on separate pins, don\'t you still require a pullup on the control pins as well as voltage dividers on the sense pins? Why is combining these two not a savings in real estate? Are the PSU voltages all low enough they can be measured directly?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
 
On 09-Nov-20 9:24 am, Don Y wrote:
I need to monitor/control several analog signals.  I have
very little board space to do so and, hopefully, monies.

For a variety of reasons, an MCU will at least need to be
part of the solution (as there needs to be sequencing,
communication and other conditional logic).  But, the
\"processing\" needs are tiny enough that a dog of an MCU
could likely be coerced into functioning.

[The downside is the addition of a \"programming\" step
at manufacture]

I was hoping to use single pins for measurement and control.
E.g., drive pin low to disable a poser supply; let it float to
the voltage of the monitored supply to measure the actual
supply voltage.  Repeat for each controlled supply, etc.
(obviously, no need to \"disable\" a temperature input)

But, this seems to add a fair number of passives that might
eat up more real estate than the pin\'s saving gains!

And, ensuring that the \"output\" is driven low during power
sequencing of the \"supervisor\" presents another opportunity
for component creep.

Any other potential downsides to this sort of hack?

Having the power supply disable linked to the output voltage sense seems
like it\'s asking for trouble during startup.

Once the need for an MCU is determined, I\'d be wondering what else it
could do so as to save board space.

Sylvia.
 
On 11/8/2020 6:35 PM, Sylvia Else wrote:
On 09-Nov-20 9:24 am, Don Y wrote:
I need to monitor/control several analog signals. I have
very little board space to do so and, hopefully, monies.

For a variety of reasons, an MCU will at least need to be
part of the solution (as there needs to be sequencing,
communication and other conditional logic). But, the
\"processing\" needs are tiny enough that a dog of an MCU
could likely be coerced into functioning.

[The downside is the addition of a \"programming\" step
at manufacture]

I was hoping to use single pins for measurement and control.
E.g., drive pin low to disable a poser supply; let it float to
the voltage of the monitored supply to measure the actual
supply voltage. Repeat for each controlled supply, etc.
(obviously, no need to \"disable\" a temperature input)

But, this seems to add a fair number of passives that might
eat up more real estate than the pin\'s saving gains!

And, ensuring that the \"output\" is driven low during power
sequencing of the \"supervisor\" presents another opportunity
for component creep.

Any other potential downsides to this sort of hack?

Having the power supply disable linked to the output voltage sense seems like
it\'s asking for trouble during startup.

That\'s where the need for external components comes into the mix.

I.e., you want a low impedance link between the MCU pin (acting as an
output) and the \"enable\" pin on the power supply (or, controlled circuit).

You want to be able to drive that pin HIGH to turn on the supply.
But, at the same time, be able to sense the output of that circuit/supply
on this same MCU pin as a (high impedance) INPUT. You want to be able
to bias the signal seen at the \"enable\" pin high enough to turn the
circuit on; yet don\'t want this bias to meaningfully affect the
voltage sensed on that MCU pin.

Of course, this assumes you can find an MCU that powers up with those
pins in the \"disable\" state -- or, add components to effectively make that
the case!

Once the need for an MCU is determined, I\'d be wondering what else it could do
so as to save board space.

This is a peripheral. There\'s another \"real\" CPU, elsewhere. It talks
with this device -- to sense voltages/temperatures/currents/etc. that
are monitored by that MCU, to indirectly control circuits directly under
the control of the MCU, etc.

Having smarts in the MCU lets the MCU bring the controlled circuits to
a safe configuration in the event that communication with the main CPU
is interrupted. And, to do so in a manner that the main CPU dictates
(prior to communications being lost; if communications are NEVER
established, then the controlled circuits would never have been commanded
to leave their safe configuration!)

It also lets the CPU verify that the controlled circuits are in a state
from which they can successfully be brought back on-line (imagine a
supply taking a long time to collapse).

There can be multiple instances of these MCUs and controlled circuits
on a single CPU -- think of it as a legacy system where there is a
\"CPU card\" and individual \"I/O\" cards, each of which can have their
power needs controlled and monitored by the CPU. This is the case
even if all of the \"modules\" co-reside with the CPU core on a single
PCB.

A consequence of this is the MCUs must be able to share a communication
link with each other -- so the CPU doesn\'t need an unknown number of
links to support an unknown number of \"modules\". And, to reduce pin
count, you\'d prefer a one-wire bus.

[The CPU may be called on for its compute resources while the I/Os
that are associated with are not needed. Or, that some subset of
those I/Os may be needed at one time or another. Or, that there
may be a need to economize on power consumption (how do you know
how much power your I/Os are actually consuming?). The point is to
be able to dynamically manage resources and those demands on other
resources (e.g., power)]

But, I\'m really strapped on real estate to do this. Piecing together
a solution using COTS \"supervisory chips\" *AND* an MCU is too expensive
and too bulky.
 

Welcome to EDABoard.com

Sponsor

Back
Top