Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #454355 > unrolled thread

Identification of modules

Back to article view | Back to sci.electronics.design

Contents

  Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 09:21 +0200
    Re: Identification of modules Don Y <blockedofcourse@foo.invalid> - 2017-03-31 01:31 -0700
      Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 10:36 +0200
        Re: Identification of modules Don Y <blockedofcourse@foo.invalid> - 2017-03-31 02:16 -0700
          Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 11:39 +0200
            Re: Identification of modules Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-31 11:32 +0100
              Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 12:59 +0200
            Re: Identification of modules Don Y <blockedofcourse@foo.invalid> - 2017-03-31 11:55 -0700
      Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 11:30 +0200
    Re: Identification of modules rickman <gnuarm@gmail.com> - 2017-03-31 05:20 -0400
      Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 11:53 +0200
        Re: Identification of modules rickman <gnuarm@gmail.com> - 2017-03-31 06:16 -0400
          Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 12:39 +0200
            Re: Identification of modules rickman <gnuarm@gmail.com> - 2017-03-31 13:27 -0400
              Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 22:14 +0200
                Re: Identification of modules rickman <gnuarm@gmail.com> - 2017-03-31 17:48 -0400
                  Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-04-03 10:57 +0200
      Re: Identification of modules John Devereux <john@devereux.me.uk> - 2017-03-31 11:39 +0100
        Re: Identification of modules rickman <gnuarm@gmail.com> - 2017-03-31 13:38 -0400
          Re: Identification of modules Piotr Wyderski <peter.pan@neverland.mil> - 2017-03-31 22:21 +0200
    Re: Identification of modules Joe Chisolm <jchisolm6@earthlink.net> - 2017-03-31 13:02 -0500
    Re: Identification of modules Tim Wescott <seemywebsite@myfooter.really> - 2017-03-31 16:18 -0500

Page 1 of 2  [1] 2  Next page →

#454355 — Identification of modules

My system will be composed of a number of free slots
which can be populated with some modules (mostly
containing power electronics). The simplest the module
is, the better, don't want to use a micro to do the
job because of its limited FLASH/EEPROM retention time.

The module must be able to report its identity to the
main controller (one from the closed universe of, say,
32 possibilities known in advance) and which slot it
occupies. A very useful feature would be to have
a temperature sensor of some kind for moderate overload
detection.

I cannot afford many pins to do that, so the simplest
5+5 pin solution of binary encoding the relevant
information is not an option.

I came up with the idea to (ab)use the Maxim's DS2438
battery monitor and use its voltage/current sensor A/D
channels to fetch the value encoded by a resistive divider.
The temperature sensor is there for free and the cost is
below a buck for 20 pieces in China. It supports the 1-wire
bus.

Do you know anything simpler/better or is there
anything to worry about that Maxim part?

BTW, why are the Maxim parts so insanely expensive?
I could find many applications for the 1-wire DS2450
A/D converter, but the cost makes it pointless -- one
can emulate it with any SO8 micro for 1/4 of its price.

	Best regards, Piotr

[toc] | [next] | [standalone]

#454369

On 3/31/2017 12:21 AM, Piotr Wyderski wrote:
> My system will be composed of a number of free slots
> which can be populated with some modules (mostly
> containing power electronics). The simplest the module
> is, the better, don't want to use a micro to do the
> job because of its limited FLASH/EEPROM retention time.

Retention *time*?  What sort of product lifespan are you
assuming?

> The module must be able to report its identity to the
> main controller (one from the closed universe of, say,
> 32 possibilities known in advance) and which slot it
> occupies. A very useful feature would be to have
> a temperature sensor of some kind for moderate overload
> detection.

Do you want slots to be wired (nearly) identical?  Or,
are you willing to have a "controller slot", etc.?

> I cannot afford many pins to do that, so the simplest
> 5+5 pin solution of binary encoding the relevant
> information is not an option.
>
> I came up with the idea to (ab)use the Maxim's DS2438
> battery monitor and use its voltage/current sensor A/D
> channels to fetch the value encoded by a resistive divider.
> The temperature sensor is there for free and the cost is
> below a buck for 20 pieces in China. It supports the 1-wire
> bus.
>
> Do you know anything simpler/better or is there
> anything to worry about that Maxim part?

Sole source?

> BTW, why are the Maxim parts so insanely expensive?
> I could find many applications for the 1-wire DS2450
> A/D converter, but the cost makes it pointless -- one
> can emulate it with any SO8 micro for 1/4 of its price.

What's wrong with using a tiny MCU to determine which
slot *it* resides in and then convey its slot number and
"module type" to the controller, regardless of where the
controller happens to be located?

Apply Vref to the "slotID" pin of the leftmost slot
and GND to the same pin on the rightmost slot.  Put
a fixed resistance between the slotID pin on each slot
and the slot to its right.  MCU on the card *in* the
slot can then read the voltage on the slotID pin to
identify itself.

Alternately, put a unique R value between Vref and
each slot's slotID pin then sense this (with a current
sink, RC oscillator, etc.).

[You can also do this with actives -- at a higher cost]

Another pin can act as a bidirectional bus that the
controller assumes ownership of and polls the individual
MCU's on each slot.

Of course, this assumes you are taking precautions to
protect all inputs that are "exposed" on the backplane...

[toc] | [prev] | [next] | [standalone]

#454370

Don Y wrote:

> Retention *time*?  What sort of product lifespan are you
> assuming?

40y+, at least in terms of storage time.

> Do you want slots to be wired (nearly) identical?  Or,
> are you willing to have a "controller slot", etc.?

Mostly identical.

> Sole source?

Not a problem, can buy more in advance.

	Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

#454377

On 3/31/2017 1:36 AM, Piotr Wyderski wrote:
> Don Y wrote:
>
>> Retention *time*?  What sort of product lifespan are you
>> assuming?
>
> 40y+, at least in terms of storage time.

So, you're planning on discarding the EEPROM in the DS2438?
I.e., you can't rely on any "persistent" features in your
design that can't be reloaded at POST.  (Make sure the
configuration isn't implemented in EEPROM if you mistrust it!)

Why not just opt for a one-wire ADC?  Pair?  Addressable
switch?

Or, some discrete logic that you clock, remotely?

(presumably, you have some time to query the system's
configuration -- you're not trying to hot swap cards
and bring them on-line "instantly"?)

>> Do you want slots to be wired (nearly) identical?  Or,
>> are you willing to have a "controller slot", etc.?
>
> Mostly identical.
>
>> Sole source?
>
> Not a problem, can buy more in advance.

So, you're prepared to do an end-of-life buy as you head
into initial production?

What about masked parts?

[toc] | [prev] | [next] | [standalone]

#454383

Don Y wrote:

> So, you're planning on discarding the EEPROM in the DS2438?

Yes, not going to use it at all.

> (Make sure the configuration isn't implemented in EEPROM if you mistrust it!)

The problem is not in EEPROM, but the lack of power
supply/communitation in the case of spare modules.
The powered ones can be automatically reprogrammed
once a year, just in case.

> Why not just opt for a one-wire ADC?

Where, on the module? It's exactly how 2438 is going to be used.

> Or, some discrete logic that you clock, remotely?

Too big.

> (presumably, you have some time to query the system's
> configuration -- you're not trying to hot swap cards
> and bring them on-line "instantly"?)

Yes, no hot-swap capability required.

> So, you're prepared to do an end-of-life buy as you head
> into initial production?

I can add a spare DS2438 in a bag for every produced module.

> What about masked parts?

The scale is far to small, can't afford.

	Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

#454387

So, small scale, can't trust stored charge over decades.

Consider manually set switches or manually inserted zero
ohm resistors, and a shift register.


On 31/03/17 10:39, Piotr Wyderski wrote:
> Don Y wrote:
>
>> So, you're planning on discarding the EEPROM in the DS2438?
>
> Yes, not going to use it at all.
>
>> (Make sure the configuration isn't implemented in EEPROM if you mistrust it!)
>
> The problem is not in EEPROM, but the lack of power
> supply/communitation in the case of spare modules.
> The powered ones can be automatically reprogrammed
> once a year, just in case.
>
>> Why not just opt for a one-wire ADC?
>
> Where, on the module? It's exactly how 2438 is going to be used.
>
>> Or, some discrete logic that you clock, remotely?
>
> Too big.
>
>> (presumably, you have some time to query the system's
>> configuration -- you're not trying to hot swap cards
>> and bring them on-line "instantly"?)
>
> Yes, no hot-swap capability required.
>
>> So, you're prepared to do an end-of-life buy as you head
>> into initial production?
>
> I can add a spare DS2438 in a bag for every produced module.
>
>> What about masked parts?
>
> The scale is far to small, can't afford.
>
>     Best regards, Piotr
>

[toc] | [prev] | [next] | [standalone]

#454391

Tom Gardner wrote:

> Consider manually set switches or manually inserted zero
> ohm resistors, and a shift register.

The configurability isn't required, each slot "knows"
its number and each module knows it type, which is
determined by its physical construction, so the config
can be etched on the PCB.

I also thought about CD40103, with the count inputs
preset to encode 8-bit information and count how many
times do I need to pulse it till it blinks, but it would
use many slot pins and is bigger than the SO8 Maxim
parts.

But you pointed out an interresting solution, each
module contains a shift register (it is the way the
desired content is presented to the power devices,
but from the controller's POV it is write-only).
I can skip the generation of the latching pulse and
abuse the value of the shift-out chaining pin in
a filthy way.

Since each module is either in normal operation or
identification mode, this idea can lead somewhere...

	Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

#454447

On 3/31/2017 2:39 AM, Piotr Wyderski wrote:
> Don Y wrote:
>
>> So, you're planning on discarding the EEPROM in the DS2438?
>
> Yes, not going to use it at all.
>
>> (Make sure the configuration isn't implemented in EEPROM if you mistrust it!)
>
> The problem is not in EEPROM, but the lack of power
> supply/communitation in the case of spare modules.
> The powered ones can be automatically reprogrammed
> once a year, just in case.

So, you're assuming the EEPROM contents will remain intact
between times that you get a chance to "examine" it.  Note
that there are no CRC's on the configuration so if a bit
toggles, you'll have no way of knowing that the configuration
has changed and will gleefully "refresh" it to its erroneous
state.

[Unless you leverage the discarded EEPROM store to keep
a highly redundant copy of that information]

>> Why not just opt for a one-wire ADC?
>
> Where, on the module? It's exactly how 2438 is going to be used.

Same way as yours is used.  I'm just eliding the "charge accumulator",
voltage/current monitoring, etc. that makes the 2438 so "special".

>> Or, some discrete logic that you clock, remotely?
>
> Too big.

Masked FPGA/PAL/etc.?

>> (presumably, you have some time to query the system's
>> configuration -- you're not trying to hot swap cards
>> and bring them on-line "instantly"?)
>
> Yes, no hot-swap capability required.
>
>> So, you're prepared to do an end-of-life buy as you head
>> into initial production?
>
> I can add a spare DS2438 in a bag for every produced module.

That seems like you're planning for failure -- instead of planning
for *success*!

>> What about masked parts?
>
> The scale is far to small, can't afford.

Can't argue with that!  :>

[toc] | [prev] | [next] | [standalone]

#454381

Don Y wrote:

> Do you want slots to be wired (nearly) identical?

Oh, I misunderstood you. Yes, the wiring will be
composed of 18 parallel, identical lines + 2
dedicated per-slot (already used) pins on the edges
of the connector. All single-sided and reinforced
with wire, I don't trust vias that much.

> What's wrong with using a tiny MCU to determine which
> slot *it* resides in and then convey its slot number and
> "module type" to the controller, regardless of where the
> controller happens to be located?

A fair chance for the MCU to develop Alzheimer's disease
after 30 years of being kept on the shelf with other spare modules. :-)
No stored charge devices here. Which brings the question about
DS2438 internals. I've read somewhere that some voltage reference chips
are based on a cap holding some charge injected in the factory, which
will make them drift due to leakage in the larger time scales. Will need
to ask Maxim about that, perhaps.

> Of course, this assumes you are taking precautions to
> protect all inputs that are "exposed" on the backplane...

That's another story, but yes, of course.

	Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

#454378

On 3/31/2017 3:21 AM, Piotr Wyderski wrote:
> My system will be composed of a number of free slots
> which can be populated with some modules (mostly
> containing power electronics). The simplest the module
> is, the better, don't want to use a micro to do the
> job because of its limited FLASH/EEPROM retention time.
>
> The module must be able to report its identity to the
> main controller (one from the closed universe of, say,
> 32 possibilities known in advance) and which slot it
> occupies. A very useful feature would be to have
> a temperature sensor of some kind for moderate overload
> detection.
>
> I cannot afford many pins to do that, so the simplest
> 5+5 pin solution of binary encoding the relevant
> information is not an option.
>
> I came up with the idea to (ab)use the Maxim's DS2438
> battery monitor and use its voltage/current sensor A/D
> channels to fetch the value encoded by a resistive divider.
> The temperature sensor is there for free and the cost is
> below a buck for 20 pieces in China. It supports the 1-wire
> bus.
>
> Do you know anything simpler/better or is there
> anything to worry about that Maxim part?
>
> BTW, why are the Maxim parts so insanely expensive?
> I could find many applications for the 1-wire DS2450
> A/D converter, but the cost makes it pointless -- one
> can emulate it with any SO8 micro for 1/4 of its price.

I'm not clear on what you are using the resistive divider for.  Is that 
to identify the module type or the slot?

The lowest priced 1 wire part I found on Mouser is the DS28E05P+T.  It 
combines the unique 64 bit serial number each 1 wire device has with 112 
bytes of user EEPROM for under $0.50 in quantity.  The EEPROM can be 
programmed in manufacturing to provide a module type identification 
number.

I'm not clear on what your limitations are for identifying the slot 
number.  The easy way is to isolate the 1 wire buses to each slot so you 
are only talking to one at a time.  If you don't want to use that many 
pins on your MCU, an analog switch multiplexer will allow the MCU to 
talk to one slot at a time and only need log2(N) I/Os.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#454384

rickman wrote:

> I'm not clear on what you are using the resistive divider for.  Is that
> to identify the module type or the slot?

There are two pieces of information the controller needs
to know, both safely in the range of 5 bits:

1. Where the module is (in which slot).

2. What type of module it is, which says what waveforming
is required to drive it. Say, "I am a 230V module stuffed
with TRIACS" or "the switches are MOSFETs, so use reverse
phase control to decrease the level of EMI" or "mechanical
relays, avoid fidgeting", etc.

The more advanced modules, e.g. carrying an MCU, may want
to use the location info to configure their I2C/CAN address etc.

> The lowest priced 1 wire part I found on Mouser is the DS28E05P+T.  It
> combines the unique 64 bit serial number each 1 wire device has with 112
> bytes of user EEPROM for under $0.50 in quantity.  The EEPROM can be
> programmed in manufacturing to provide a module type identification number.

Just 10 years of retention time, far to small.

> I'm not clear on what your limitations are for identifying the slot
> number.  The easy way is to isolate the 1 wire buses to each slot so you
> are only talking to one at a time.

Would require a complex backplane routing.

> If you don't want to use that many
> pins on your MCU, an analog switch multiplexer will allow the MCU to
> talk to one slot at a time and only need log2(N) I/Os.

Would need to be located on the backplane, which is hard to replace.

	Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

#454386

On 3/31/2017 5:53 AM, Piotr Wyderski wrote:
> rickman wrote:
>
>> I'm not clear on what you are using the resistive divider for.  Is that
>> to identify the module type or the slot?
>
> There are two pieces of information the controller needs
> to know, both safely in the range of 5 bits:

Is that five bits each or five bits total?  Why do I need to know how 
many bits this uses?  I need to know how you plan to distinguish the 
board slots.


> 1. Where the module is (in which slot).
>
> 2. What type of module it is, which says what waveforming
> is required to drive it. Say, "I am a 230V module stuffed
> with TRIACS" or "the switches are MOSFETs, so use reverse
> phase control to decrease the level of EMI" or "mechanical
> relays, avoid fidgeting", etc.
>
> The more advanced modules, e.g. carrying an MCU, may want
> to use the location info to configure their I2C/CAN address etc.

You didn't answer my question.


>> The lowest priced 1 wire part I found on Mouser is the DS28E05P+T.  It
>> combines the unique 64 bit serial number each 1 wire device has with 112
>> bytes of user EEPROM for under $0.50 in quantity.  The EEPROM can be
>> programmed in manufacturing to provide a module type identification
>> number.
>
> Just 10 years of retention time, far to small.
>
>> I'm not clear on what your limitations are for identifying the slot
>> number.  The easy way is to isolate the 1 wire buses to each slot so you
>> are only talking to one at a time.
>
> Would require a complex backplane routing.

"Complex"?  How do you define "complex"?


>> If you don't want to use that many
>> pins on your MCU, an analog switch multiplexer will allow the MCU to
>> talk to one slot at a time and only need log2(N) I/Os.
>
> Would need to be located on the backplane, which is hard to replace.

I guess I still don't understand your system.  I don't see why any parts 
would need to be on the backplane.

Where are all the pieces?  Where is the CPU?  You still have not 
explained the limitations of your slot identification.  How will the 
board know which slot it is in?  Are you trying to identify the boards 
and positions to a central CPU or to the MCUs on each board?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#454388

rickman wrote:

> Is that five bits each or five bits total?

Five bits each.

> Why do I need to know how many bits this uses?

Because that determines the space of possible solutions.
One bit would could be solved purely by digital means,
16 bits is beyond the capabilities of certain analog techniques.

 > I need to know how you plan to distinguish the board slots.

One option is that a designated pin carries a different voltage
level. The level is generated by an appropriate resistor divider
on the backplane, based on 1% parts.

The type of the board is identified exactly the same way, but
the divider is on the board.

>> Would require a complex backplane routing.
>
> "Complex"?  How do you define "complex"?

Anything that wouldn't fit on a board without vias
and the traces cannot be reinforced with wire.

A board composed of 18 parallel wide traces + 2 per-slot
dedicated lines is considered to be simple.

> I guess I still don't understand your system.  I don't see why any parts
> would need to be on the backplane.

Then how?

> Where are all the pieces?  Where is the CPU?  You still have not
> explained the limitations of your slot identification.  How will the
> board know which slot it is in?

 > Are you trying to identify the boards and positions to a central CPU 
or to the MCUs on each board?

To a central controller composed of 2 redundant CPUs. An MCU on board is 
optional and preferably avoided if possible.

	Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

#454435

On 3/31/2017 6:39 AM, Piotr Wyderski wrote:
> rickman wrote:
>
>> Is that five bits each or five bits total?
>
> Five bits each.
>
>> Why do I need to know how many bits this uses?
>
> Because that determines the space of possible solutions.
> One bit would could be solved purely by digital means,
> 16 bits is beyond the capabilities of certain analog techniques.
>
>> I need to know how you plan to distinguish the board slots.
>
> One option is that a designated pin carries a different voltage
> level. The level is generated by an appropriate resistor divider
> on the backplane, based on 1% parts.
>
> The type of the board is identified exactly the same way, but
> the divider is on the board.
>
>>> Would require a complex backplane routing.
>>
>> "Complex"?  How do you define "complex"?
>
> Anything that wouldn't fit on a board without vias
> and the traces cannot be reinforced with wire.
>
> A board composed of 18 parallel wide traces + 2 per-slot
> dedicated lines is considered to be simple.

2 dedicated signals per slot is simple but 3 isn't?  I believe you said 
somewhere else that the 2 are already used for other functions.  How 
will the analog voltage get into the card?


>> I guess I still don't understand your system.  I don't see why any parts
>> would need to be on the backplane.
>
> Then how?

You haven't explained your system.


>> Where are all the pieces?  Where is the CPU?  You still have not
>> explained the limitations of your slot identification.  How will the
>> board know which slot it is in?
>
>> Are you trying to identify the boards and positions to a central CPU
> or to the MCUs on each board?
>
> To a central controller composed of 2 redundant CPUs. An MCU on board is
> optional and preferably avoided if possible.

You haven't said *where* the CPUs are.  Are they on two of the 322 
plugin cards?  There are lots of things you haven't explained about your 
system.  It's hard to suggest solutions when the system is not defined 
fully.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#454464

rickman wrote:

> 2 dedicated signals per slot is simple but 3 isn't?

3 signals from each slot will need to be interleaved
on the PCB, while 2 make non-interleaved busses.

 > I believe you said somewhere else that the 2 are already used
 > for other functions.  How will the analog voltage get into the card?

 From above, through holes drilled in an appropriate place
to connect two THT resistors.

https://postimg.org/image/ligbk01nl/

This is what I consider simple. 2 busses on the edges
of the connectors, common signals in the middle, the
slot ID resistor dividers connected to pins 5.

> You haven't said *where* the CPUs are.

Technically, on a special module, they have their dedicated
connectors on the backplane and drive the lines from the image above.

>  There are lots of things you haven't explained about your
> system.  It's hard to suggest solutions when the system is not defined
> fully.

What would you like to be better defined, Rick?
The backplane is a row of straight 20-gold pin connectors,
the modules are to be installed vertically.

	Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

#454484

On 3/31/2017 4:14 PM, Piotr Wyderski wrote:
> rickman wrote:
>
>> 2 dedicated signals per slot is simple but 3 isn't?
>
> 3 signals from each slot will need to be interleaved
> on the PCB, while 2 make non-interleaved busses.
>
>> I believe you said somewhere else that the 2 are already used
>> for other functions.  How will the analog voltage get into the card?
>
> From above, through holes drilled in an appropriate place
> to connect two THT resistors.
>
> https://postimg.org/image/ligbk01nl/
>
> This is what I consider simple. 2 busses on the edges
> of the connectors, common signals in the middle, the
> slot ID resistor dividers connected to pins 5.

It's not important that I understand all the details, but I don't see 
how it would be any worse to have a third or fourth independent signal 
to/from each board.  You say they would be "interleaved" with the 
others, but you don't explain why that would be a problem.

You actually have 3 independent, non-bused signals to each board now.


>> You haven't said *where* the CPUs are.
>
> Technically, on a special module, they have their dedicated
> connectors on the backplane and drive the lines from the image above.

Ok, that's what I would have expected.  Are these modules pin out 
limited?  How many of the general modules will the backplane have?


>>  There are lots of things you haven't explained about your
>> system.  It's hard to suggest solutions when the system is not defined
>> fully.
>
> What would you like to be better defined, Rick?
> The backplane is a row of straight 20-gold pin connectors,
> the modules are to be installed vertically.

This problem is every time something is suggested, another requirement 
shows up, too "complex", no active circuitry on the back plane, too many 
pins on the CPU modules...

If I knew more about what you were already doing, I could know more 
about what you would find acceptable.

You are not happy with the ADC approach because the part is a couple of 
dollars.  You might be able to use a similar, but less costly approach. 
Maxim makes a 1 wire device with two PIOs (programmable input/output) 
for slightly over a dollar.  One bus line would be used to communicate 
with these devices.  A second bus line would be used to sense the slot 
and board type.

Each sense line would have a resistor in series with the output on the 
backplane.  The value of this resistor would correspond to the slot. 
This resistor value would be sensed by the CPU board by measuring the 
current when the plugin board pulls the card end of the sense resistor 
to ground with one of the PIOs.  The resistor values would need to be 
small allowing a relatively large current to flow.

To determine plugin card type, the other PIO would be activated to pull 
the sense pin low through a larger value resistor.  The CPU board would 
need to measure a much smaller current to distinguish the plugin card 
type.  If the steps in resistance values of the two functions are 
distinct enough, nothing special would need to be done to make all 
measurements.  But this would require very high precision devices.  It 
would be better to allow the two ranges to overlap and do the math to 
isolate the slot from the plugin card type.

Or... the slot can be detected by measuring the current when the sense 
pin is grounded by the plugin card.  The plugin card type can be 
detected by measuring the voltage on the sense bus when a voltage 
divider is enabled and the voltage source on the bus is disabled.

This may take a little circuitry on the CPU card, but it should be 
pretty minimal.

                R1                      Sense Bus
Vcc  -->>----/\/\/----+                   ^
                       |                   |
           +------+    |  Sense Pin        |
           |  SWa |----+------>>----/\/\/--+-----> to CPU
1 Wire    |      |    |            RslotN |    sense circuit
Comms ->>-|      |    <                   |
           |      |    > R2                |
           |      |    <                   |
           |      |    >                   |
           |      |    |                   V
           |  SWb |----+                Sense Bus
           +------+
              |
              V

I can think of another approach that would dispense with the 1 wire 
device altogether, but it would be a bit more complex on the plugin cards.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#454879

rickman wrote:

> Ok, that's what I would have expected.  Are these modules pin out
> limited?

Yes, by the allowed width of the connector, i.e. by the PCB size.
20 pins is about as far as I can go without using crazy density connectors.

>  How many of the general modules will the backplane have?

Depends on the version, (1..4)x8.

> If I knew more about what you were already doing, I could know more
> about what you would find acceptable.

You all have made me rethink the problem and make use of the existing 
circuitry to piggyback the identification on the top of the existing 
protocol. The input of the module always looks like a shift register,
so I can simply shift in the module ID during a designated phase and
use the shift register output to drive an NMOS which connects an
appropriate resistor to the bus, forming a gated voltage divider.
Since the value shifted out will be exactly what was shifted in,
by appropriately forming the pattern I can make only the selected
module to respond. Plus a tiny bit of circuitry to protect the
protocol against always 0/always 1 shift register failures, which
brings a certain level of self-diagnostics. This is basically an
extension of the solution you proposed with the adressable switch.

Problem solved, thank you all very much!

    Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

#454389

rickman <gnuarm@gmail.com> writes:

> On 3/31/2017 3:21 AM, Piotr Wyderski wrote:
>> My system will be composed of a number of free slots
>> which can be populated with some modules (mostly
>> containing power electronics). The simplest the module
>> is, the better, don't want to use a micro to do the
>> job because of its limited FLASH/EEPROM retention time.
>>
>> The module must be able to report its identity to the
>> main controller (one from the closed universe of, say,
>> 32 possibilities known in advance) and which slot it
>> occupies. A very useful feature would be to have
>> a temperature sensor of some kind for moderate overload
>> detection.
>>
>> I cannot afford many pins to do that, so the simplest
>> 5+5 pin solution of binary encoding the relevant
>> information is not an option.
>>
>> I came up with the idea to (ab)use the Maxim's DS2438
>> battery monitor and use its voltage/current sensor A/D
>> channels to fetch the value encoded by a resistive divider.
>> The temperature sensor is there for free and the cost is
>> below a buck for 20 pieces in China. It supports the 1-wire
>> bus.
>>
>> Do you know anything simpler/better or is there
>> anything to worry about that Maxim part?
>>
>> BTW, why are the Maxim parts so insanely expensive?
>> I could find many applications for the 1-wire DS2450
>> A/D converter, but the cost makes it pointless -- one
>> can emulate it with any SO8 micro for 1/4 of its price.
>
> I'm not clear on what you are using the resistive divider for.  Is
> that to identify the module type or the slot?
>
> The lowest priced 1 wire part I found on Mouser is the DS28E05P+T.  It
> combines the unique 64 bit serial number each 1 wire device has with
> 112 bytes of user EEPROM for under $0.50 in quantity.  The EEPROM can
> be programmed in manufacturing to provide a module type identification
> number.

We use those (with trepidation, maxim etc). We use it to store the
serial number and calibration data on a tiny sensor module, to make them
interchangeable.


> I'm not clear on what your limitations are for identifying the slot
> number.  The easy way is to isolate the 1 wire buses to each slot so
> you are only talking to one at a time.  If you don't want to use that
> many pins on your MCU, an analog switch multiplexer will allow the MCU
> to talk to one slot at a time and only need log2(N) I/Os.

You don't need to do that AIUI, the one-wire bus has a discovery
algorithm you can use to address any device when all the "one-wires" are
connected together. Never had to use it but it's there.



-- 

John Devereux

[toc] | [prev] | [next] | [standalone]

#454437

On 3/31/2017 6:39 AM, John Devereux wrote:
> rickman <gnuarm@gmail.com> writes:
>
>> On 3/31/2017 3:21 AM, Piotr Wyderski wrote:
>>> My system will be composed of a number of free slots
>>> which can be populated with some modules (mostly
>>> containing power electronics). The simplest the module
>>> is, the better, don't want to use a micro to do the
>>> job because of its limited FLASH/EEPROM retention time.
>>>
>>> The module must be able to report its identity to the
>>> main controller (one from the closed universe of, say,
>>> 32 possibilities known in advance) and which slot it
>>> occupies. A very useful feature would be to have
>>> a temperature sensor of some kind for moderate overload
>>> detection.
>>>
>>> I cannot afford many pins to do that, so the simplest
>>> 5+5 pin solution of binary encoding the relevant
>>> information is not an option.
>>>
>>> I came up with the idea to (ab)use the Maxim's DS2438
>>> battery monitor and use its voltage/current sensor A/D
>>> channels to fetch the value encoded by a resistive divider.
>>> The temperature sensor is there for free and the cost is
>>> below a buck for 20 pieces in China. It supports the 1-wire
>>> bus.
>>>
>>> Do you know anything simpler/better or is there
>>> anything to worry about that Maxim part?
>>>
>>> BTW, why are the Maxim parts so insanely expensive?
>>> I could find many applications for the 1-wire DS2450
>>> A/D converter, but the cost makes it pointless -- one
>>> can emulate it with any SO8 micro for 1/4 of its price.
>>
>> I'm not clear on what you are using the resistive divider for.  Is
>> that to identify the module type or the slot?
>>
>> The lowest priced 1 wire part I found on Mouser is the DS28E05P+T.  It
>> combines the unique 64 bit serial number each 1 wire device has with
>> 112 bytes of user EEPROM for under $0.50 in quantity.  The EEPROM can
>> be programmed in manufacturing to provide a module type identification
>> number.
>
> We use those (with trepidation, maxim etc). We use it to store the
> serial number and calibration data on a tiny sensor module, to make them
> interchangeable.

That is pretty much exactly what they are intended for.  I see now that 
part is barking up the wrong tree.  He doesn't care about the serial 
number or the flash, he only cares about the ADC.


>> I'm not clear on what your limitations are for identifying the slot
>> number.  The easy way is to isolate the 1 wire buses to each slot so
>> you are only talking to one at a time.  If you don't want to use that
>> many pins on your MCU, an analog switch multiplexer will allow the MCU
>> to talk to one slot at a time and only need log2(N) I/Os.
>
> You don't need to do that AIUI, the one-wire bus has a discovery
> algorithm you can use to address any device when all the "one-wires" are
> connected together. Never had to use it but it's there.

I've used it before, how else do you learn what devices are on your bus? 
   Addressing the devices is not the same as knowing what slot they are 
in.  That is the purpose of the multiplexers, to isolate the ID pin on 
each card slot so the slot is known.  Instead he wants to supply to the 
slot an analog voltage through a resistive divider which is read by an 
ADC on the card.  Then he doesn't like the cost of the ADC.

There are other ways to get an ADC such as an MCU, but I can't think of 
any that won't use flash memory... except for the TI MSP430FR devices 
that use ferroelectric storage, FRAM.  But I doubt that has enough 
retention time for this requirement either.

The only other ADC that might suit him is one that works over SMBUS. 
That will use two pins, but it is all a bus.  The ADC needs two inputs, 
one for the slot voltage and one for the card type voltage.  Best would 
be one that can do ratiometric measurements to eliminate the effect of 
variations in Vcc.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#454465

rickman wrote:

> That is pretty much exactly what they are intended for.  I see now that
> part is barking up the wrong tree.  He doesn't care about the serial
> number or the flash, he only cares about the ADC.

And the integrated temperature sensor, which is there for free.

> Instead he wants to supply to the
> slot an analog voltage through a resistive divider which is read by an
> ADC on the card.  Then he doesn't like the cost of the ADC.

Exactly, and the reason to dislike the dedicated ADC (i.e. 2450)
is its 3x higher price and the lack of the thermometer.

> The only other ADC that might suit him is one that works over SMBUS.

"The devices are recognized automatically and assigned unique addresses."

Sounds good!

	Best regards, Piotr

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | sci.electronics.design

csiph-web