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.
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.]
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..."
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.
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?
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.
Do you really *need* that "speed"? I.e., you are (probably) performing this test exactly *once*?
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)?
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.
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?
No. Yes.
The I/O's are designated for off-board comms already, but your point is valid.
As long as I avoid the I2C start condition, my understanding is pulses on the lines are ignored.
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.
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!" :>
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.