|
|
View previous topic :: View next topic |
Author |
Message |
RoGuE_StreaK
Joined: 02 Feb 2010 Posts: 73
|
Controlling a pulled-up device? |
Posted: Wed Feb 01, 2012 11:47 pm |
|
|
May seem like a dumb question, but I'm used to turning somthing on by feeding a positive to it, and can't wrap my head around the implications of this in a powered-down state etc...
I've got an LED driver that is enabled when it's OE (output enable) pin is pulled to ground. It has an inbuilt pull-up resistor. From a physical and coding perspective for the PIC, how do I go about connecting it to the PIC, and controlling it, so when for example the PIC is in sleep mode the OE is allowed to pull back up to disable it? And so on startup it doesn't enable until I specifically tell it to?
I mean, normally (I assume, still unclear on this stuff) when the PIC starts up the pins are in a Low state, but wouldn't this enable my LED driver?
Do I need a small transistor in here so a High output connects OE to ground, and the "default"(?) Low means it's disconnected, thus being pulled high by it's internal resistor? Doesn't seem right that an additional component is required to achieve this, but I can't figure out the logic of it.
Any solution? Is it something to do with using the PIC's internal pullups, if so do these persist when in sleep, etc., etc |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19540
|
|
Posted: Thu Feb 02, 2012 2:39 am |
|
|
PIC pins wake up as _inputs_. They are undriven, until you drive them.
This is why it is always 'vital' to ensure connected circuitry defaults to a 'safe' state when pins are not driven.
To leave the pin floating, use 'output_float'. To pull it down use 'output_low'.
So before you sleep use the 'float' instruction, and when you want to control the device use the output_low.
PIC pins basically have 3 states:
1) Input, or floating.
2) Driven low.
3) Driven high.
Best Wishes |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
Re: Controlling a pulled-up device? |
Posted: Thu Feb 02, 2012 2:58 am |
|
|
RoGuE_StreaK wrote: |
I mean, normally (I assume, still unclear on this stuff) when the PIC starts up the pins are in a Low state, but wouldn't this enable my LED driver?
|
No, when the PIC starts up all its I/O pins are inputs, and so they will float to whatever the external circuitry pulls it to. I/O pins remain as inputs until you either output to them in standard I/O mode, or set the TRIS to output in fast I/O mode.
You can happily drive a pulled up signal as normal, indeed very often the pull up is purely there to ensure a known state during reset/startup. You can also drive in a psuedo-open drain way by outputting and leaving the pin to low and using TRIS to enable the output - to drive low - or disable to allow to float high. I2C uses this form of driving SCL and SDA.
Quote: |
Do I need a small transistor in here so a High output connects OE to ground, and the "default"(?) Low means it's disconnected, thus being pulled high by it's internal resistor? Doesn't seem right that an additional component is required to achieve this, but I can't figure out the logic of it.
|
No external component is needed. You can acheive the same result by using TRIS as I described above. Note "disconnected" means hi impedance (hi-z), which in PIC terms means an input, which of course you don't need to actually read, though you can if you like.
I/O pin states persist during PIC sleep: the I/O drive circuitry remains on and at whatever state they were in when the PIC went to sleep. For minimum power consumption you should arrange all your output to be in their inactive (i.e. pulled up) state during sleep. I.e. try not to need to hold a pulled-up signal low during sleep.
RF Developer |
|
|
RoGuE_StreaK
Joined: 02 Feb 2010 Posts: 73
|
|
Posted: Thu Feb 02, 2012 4:03 pm |
|
|
Thanks for that guys, I think that's cleared up a lot of things for me, and given me a lot better understanding of the PIC pin behaviours.
This might be a solution to my previous soft-PWM query, as I'd only really be needing to change the driver's settings once via SPI when the user goes through a specific "mode change" routine, so could just enable/disable the driver with a vastly simplified soft PWM of low/float, rather than trying to send SPI enable/disable bytes each PWM cycle. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|