Forums

PIC daughterboard detection

Started by Randy Day May 18, 2015
I'm wanting to have a PIC detect whether a 
daughterboard is present, so it can activate
I2C comm. My thought is to activate the weak 
pull-down on the input, to detect whether an 
I2C pull-up resistor (10k) is present on the 
line, before turning on I2C.

Is this an acceptable use of the weak 
pull-down features of the PIC? I'm a bit 
unclear on the do's and don'ts of WPU/WPD.

(terrible ASCII art follows)

		     |-/\/\/\- pullup to +v
		     |
   |-/\/\/\--o o---+-- I2C on dboard
uC |
   |-- +v ---o o-- dboard +v
   |-- gnd --o o-- dboard gnd
		^
	   connector
On 5/18/2015 5:14 PM, Randy Day wrote:
> > I'm wanting to have a PIC detect whether a > daughterboard is present, so it can activate > I2C comm. My thought is to activate the weak > pull-down on the input, to detect whether an > I2C pull-up resistor (10k) is present on the > line, before turning on I2C. > > Is this an acceptable use of the weak > pull-down features of the PIC? I'm a bit > unclear on the do's and don'ts of WPU/WPD. > > (terrible ASCII art follows) > > |-/\/\/\- pullup to +v > | > |-/\/\/\--o o---+-- I2C on dboard > uC | > |-- +v ---o o-- dboard +v > |-- gnd --o o-- dboard gnd > ^ > connector
What *else* is on the (daughter) board? Could you, for example, detect a *signal* that would only be present (sourced) if the daughterboard was installed? Are there any (even INDIRECT) paths from your MCU through the daughterboard and back that you could detect? E.g., I designed a detector array in a product many years ago that was intended to be removable. I used a (programmable) output from the processor to drive a set of pullups -- each connected to one of the "outputs" from the array (assuming the array was present; if not, the pullups were effectively tied to undriven inputs on the control board). To detect the presence of the array, I would toggle this output and watch the corresponding inputs. If *all* toggled in sync with my actions, then I knew the array was disconnected (or, had failed in a catastrophic manner). If *none* toggled, I knew the array was present (or the outputs were "failed short" -- and I could sense whether they were shorted HI or LO!) If just *some* toggled, then I knew I had a "can't happen" situation -- the array (or some conductors in the signal cable, etc.) wasn't behaving as expected. [This mechanism also allowed me to perform more extensive self-tests: "Please unplug the sensor array. Now testing sensor data channels...". So, you get something for nothing.]
On Mon, 18 May 2015 18:23:26 -0700, Don Y <this@is.not.me.com> wrote:

>On 5/18/2015 5:14 PM, Randy Day wrote: >> >> I'm wanting to have a PIC detect whether a >> daughterboard is present, so it can activate >> I2C comm. My thought is to activate the weak >> pull-down on the input, to detect whether an >> I2C pull-up resistor (10k) is present on the >> line, before turning on I2C. >> >> Is this an acceptable use of the weak >> pull-down features of the PIC? I'm a bit >> unclear on the do's and don'ts of WPU/WPD. >> >> (terrible ASCII art follows) >> >> |-/\/\/\- pullup to +v >> | >> |-/\/\/\--o o---+-- I2C on dboard >> uC | >> |-- +v ---o o-- dboard +v >> |-- gnd --o o-- dboard gnd >> ^ >> connector > >What *else* is on the (daughter) board? Could you, for >example, detect a *signal* that would only be present (sourced) >if the daughterboard was installed? Are there any (even >INDIRECT) paths from your MCU through the daughterboard and >back that you could detect? > >E.g., I designed a detector array in a product many years ago that >was intended to be removable. I used a (programmable) output from >the processor to drive a set of pullups -- each connected to one of >the "outputs" from the array (assuming the array was present; if >not, the pullups were effectively tied to undriven inputs on the >control board). > >To detect the presence of the array, I would toggle this output and >watch the corresponding inputs. If *all* toggled in sync with my >actions, then I knew the array was disconnected (or, had failed >in a catastrophic manner). If *none* toggled, I knew the array was >present (or the outputs were "failed short" -- and I could sense whether >they were shorted HI or LO!) If just *some* toggled, then I knew I >had a "can't happen" situation -- the array (or some conductors in >the signal cable, etc.) wasn't behaving as expected. > >[This mechanism also allowed me to perform more extensive self-tests: >"Please unplug the sensor array. Now testing sensor data channels...". >So, you get something for nothing.]
It's a bit easier with I2C, there is always a ACK reply. Send a command , wait for the ACK. No ACK, no device, Cheers
On 5/18/2015 8:37 PM, Martin Riddle wrote:
> On Mon, 18 May 2015 18:23:26 -0700, Don Y <this@is.not.me.com> wrote: > >> On 5/18/2015 5:14 PM, Randy Day wrote: >>> >>> I'm wanting to have a PIC detect whether a >>> daughterboard is present, so it can activate >>> I2C comm. My thought is to activate the weak >>> pull-down on the input, to detect whether an >>> I2C pull-up resistor (10k) is present on the >>> line, before turning on I2C.
> It's a bit easier with I2C, there is always a ACK reply. > Send a command , wait for the ACK. No ACK, no device,
The OP (apparently) wanted to *conditionally* "activate I2C comm". I have no idea why there's a condition, there, but assume the OP "has his reasons..."
In article <vnbllatrcu7m6h0k6snukr914usapgdsml@4ax.com>, 
martin_ridd@verizon.net says...

[snip]

> It's a bit easier with I2C, there is always a ACK reply. > Send a command , wait for the ACK. No ACK, no device,
That is plan B; I just wondered if I could conserve a bit of power and some clock cycles by not turning on and configuring the I2C if I didn't have to. That, and I've never used the WPU's before, so I wondered if doing it like this was considered bad design for any reason.
In article <mje39s$bp9$1@speranza.aioe.org>, this@is.not.me.com says...

[snip]

> > |-/\/\/\- pullup to +v > > | > > |-/\/\/\--o o---+-- I2C on dboard > > uC | > > |-- +v ---o o-- dboard +v > > |-- gnd --o o-- dboard gnd > > ^ > > connector > > What *else* is on the (daughter) board? Could you, for > example, detect a *signal* that would only be present (sourced) > if the daughterboard was installed? Are there any (even > INDIRECT) paths from your MCU through the daughterboard and > back that you could detect?
Not really; the connector has +v, Gnd, SDA/SCL for commands and an SPI port for data transfer. As Martin mentioned, I can test for I2C ACK/NAK, but I thought it might be quicker and simpler to test for a pullup resistor. It would have the added benefit of not needing either board to be ready for comms at any particular moment during the startup phase. Testing for pullups allows speed and economy, but are there any design considerations that would argue AGAINST doing it this way?
On 5/18/2015 10:34 PM, Randy Day wrote:
> In article <mje39s$bp9$1@speranza.aioe.org>, this@is.not.me.com says... > > [snip] > >>> |-/\/\/\- pullup to +v >>> | >>> |-/\/\/\--o o---+-- I2C on dboard >>> uC | >>> |-- +v ---o o-- dboard +v >>> |-- gnd --o o-- dboard gnd >>> ^ >>> connector >> >> What *else* is on the (daughter) board? Could you, for >> example, detect a *signal* that would only be present (sourced) >> if the daughterboard was installed? Are there any (even >> INDIRECT) paths from your MCU through the daughterboard and >> back that you could detect? > > Not really; the connector has +v, > Gnd, SDA/SCL for commands and > an SPI port for data transfer. > > As Martin mentioned, I can test for > I2C ACK/NAK, but I thought it might > be quicker and simpler to test for > a pullup resistor. It would have the > added benefit of not needing either > board to be ready for comms at any > particular moment during the > startup phase.
The latter is a concern. You can work around that with a suitable delay. Or, with a "retry" protocol. I.e., don't base you FINAL decision on your initial attempt, etc. You can also look at the DC load that is present on the pin you choose when the board is present (but not yet "ready for comms") vs. absent.
> Testing for pullups allows speed
Do you really *need* that "speed"? I.e., you are (probably) performing this test exactly *once*?
> and economy, but are there any > design considerations that would > argue AGAINST doing it this way?
It costs a pin and *only* gives you that functionality. In many cases, you are hard pressed for I/O's so want to find a way of getting that functionality "for free" (or, as part of some other function) Regardless, make sure you consider the impact any bit twiddling might have on anything connected to it. E.g., if you try to send a command and come to the conclusion that there is no board present -- but, you are WRONG -- have you left that other board in some wonky state (because it saw only part of a transmission)?
In article <mjeiju$61l$1@speranza.aioe.org>, this@is.not.me.com says...

[snip]

> > As Martin mentioned, I can test for > > I2C ACK/NAK, but I thought it might > > be quicker and simpler to test for > > a pullup resistor. It would have the > > added benefit of not needing either > > board to be ready for comms at any > > particular moment during the > > startup phase. > > The latter is a concern. You can work > around that with a suitable delay. Or, > with a "retry" protocol. I.e., don't > base you FINAL decision on your initial > attempt, etc.
If I can avoid powering/polling the I2C, I'd prefer it. Instant-on is in the 'nice to have' category, not the 'must have' category.
> You can also look at the DC load that > is present on the pin you choose when > the board is present (but not yet "ready > for comms") vs. absent.
That was what I was aiming for by using the WPD; to test for an off-board I2C device holding the line high. When you mentioned 'DC load' were you thinking of a different method I hadn't considered?
> > Testing for pullups allows speed > > Do you really *need* that "speed"? > I.e., you are (probably) performing > this test exactly *once*?
No. Yes.
> > and economy, but are there any > > design considerations that would > > argue AGAINST doing it this way? > > It costs a pin and *only* gives you > that functionality. In many cases, > you are hard pressed for I/O's so > want to find a way of getting that > functionality "for free" (or, as > part of some other function)
The I/O's are designated for off-board comms already, but your point is valid.
> Regardless, make sure you consider the > impact any bit twiddling might have > on anything connected to it. E.g.,
As long as I avoid the I2C start condition, my understanding is pulses on the lines are ignored.
> if you try to send a command and > come to the conclusion that there is > no board present -- but, you are > WRONG -- have you left that other board > in some wonky state (because it saw only > part of a transmission)?
On 5/19/2015 10:32 AM, Randy Day wrote:

>> You can also look at the DC load that >> is present on the pin you choose when >> the board is present (but not yet "ready >> for comms") vs. absent. > > That was what I was aiming for by using > the WPD; to test for an off-board I2C > device holding the line high. When you > mentioned 'DC load' were you thinking > of a different method I hadn't considered?
If you can afford the pin (and the resistor), then by all means, do it. As I said, the problem is when you *can't* afford the pin -- on the connector or on the "motherboard", MCU, etc. Then, you have to *infer* this information from other means. Some devices have high enough input impedances that you can program what would nominally be an "input" to be an *output*, momentarily. Then, write a '1', switch the pin back to input mode and *read* the charge sitting on that input pin from the '1' you wrote previously. Ditto with '0'. OTOH, if there is something connected to the pin (i.e, the *real* signal) then you will end up reading whatever the output from the daughter card is driving that "input" to be, presently. [You have to look at the output impedance of the driving circuit to see if you need to add a series resistor to protect it or the output buffer in the MCU] You can switch *power* to the daughter card (esp if that adds some value to your design) and watch to see if certain signals from that card "go away" in response to your actions. Etc. What you do depends on what you have on the card and how much leeway you are willing to give your design (taking into account manufacturing variations). Regardless, *if* you opt for the pullup/down scheme, consider how you might *later* impose some other functionality on that pin -- if you decide you need an additional signal on some future version of your daughter card, etc. -- while still preserving the "daughtercard sense" functionality.
>>> Testing for pullups allows speed >> >> Do you really *need* that "speed"? >> I.e., you are (probably) performing >> this test exactly *once*? > > No. Yes. > >>> and economy, but are there any >>> design considerations that would >>> argue AGAINST doing it this way? >> >> It costs a pin and *only* gives you >> that functionality. In many cases, >> you are hard pressed for I/O's so >> want to find a way of getting that >> functionality "for free" (or, as >> part of some other function) > > The I/O's are designated for off-board > comms already, but your point is valid. > >> Regardless, make sure you consider the >> impact any bit twiddling might have >> on anything connected to it. E.g., > > As long as I avoid the I2C start > condition, my understanding is > pulses on the lines are ignored.
You just have to make sure the device that *might* be on the other end of the wire and *might* come out of reset (or whatever "known startup state" you've designed it to handle) will never be "confused" by what it *might* see happening on the line. E.g., if I was transmitting a the word "brASS", you might think it was ANOTHER word if you happened to "tune in a bit late!" :>