pin control of resistance

Status
Not open for further replies.
...

But how does this work if the GPIO is connected to both gates?

By biasing the gates correctly - in experimentation I would not be surprised to find that I can never quite keep M3 off while trying to turn M1 all the way on but trying would be fun and perhaps just one more resistor in a surprise location would do it.

My lunch break ends in 3 minutes, I try to make some sense of it with text...


Code:
MCU_PIN------
            |
           (10K)
            |
            ------- Gate_M1
            |
           (10K)
            |
            ------- Gate_M3
            |
           (10K)
            |
           GND
Unlikely imho to turn out to be matching 10K resistors but a little tweaking of values (actually choosing which fet(s) and reading their data and a little math would mean being able to calculate the most viable values.)
 
You can't do it using just one GPIO (without using many additional external components).
 
What about using the internal Teensy fet idea, I thought this might actually work. Toggling to switch the GPIO from LOW to off or high impedance ought to work for choosing between two different resistances. It is a little more complicated for the unsophisticated user than a solder jumper, but technically I don't see a problem with it. Or?
 
That is pretty much what my idea is relying on, I don't think it can work the way you seem to want it to but we've all heard about me being wrong before - pull up resistance in MK20.... is around 30K accord suggestions I have seen around here, if it has 'pulldown' then it is probably the same and simply not enough to use by a factor of about 10.

You can't do it using just one GPIO (without using many additional external components).

A mosfet we use a fair bit at my work is a 2N7002, N Channel tho probably not ideal - EE tells me they start coming on around 0.8V and are 'hard on' by around 2V for sure; DS may say 0.7V and 1.1V or something (probably with ranges) but measuring many units our EE has confidence in his figures.

If you choose such resistor values that bias Gate_M1 above ~1.5V and keep Gate_M3 below ~0.7 when "INPUT_PULLUP" is used to energise the GPIO pin then when you energise the pin as "OUTPUT" the bias for Gate_M1 will easily be above 'hard on' voltage, resistor values need tweaking till Gate_M3 is 'on enough' so to speak.

You/I/they/she/he/we all could do it with no more than 2 mosfets and 7 resistors if we selected the right mosfets and got our resistors right for desired bias of gates in given circumstances.
 
Yes, I still do believe that switching a Teensy pin between high-Z or LOW will work.
Although I cannot verify, I assume that an output pin of a Teensy has a totem-pole configuration, in which case it should work.

Perhaps Paul Stoffregen knows more details about the I/O pins?

Paul
 
FETs don't turn on precisely at some threshold voltage -- it's more like they begin to turn on at the gate voltage exceeds a threshold. As the gate voltage rises further, the on-resistance of the device decreases (it's basically inversely proportional to the amount the gate voltage exceeds the threshold). However, even at voltages below the threshold, the device is not completely 'off' -- it will leak some small current which could be significant in this (relatively) high resistance application. The amount of leakage depends exponentially on the gate voltage -- it falls by about 10x for each 100 mV drop in gate voltage below the threshold.

Different FET samples (even of the same part number) could have thresholds differing by 100's of mV. in addition, the actual threshold voltage changes with temperature (decreases by about 200 mV in 100 deg. C), so a circuit based on turning on & off the devices from a resistor divider can often be unreliable as the FETs (mis)behave differently.

Just to be clear -- in my previous drawing, M1, and M3 are the internal FETs in the Teensy's GPIO pin. They are turned off/on by switching the pin between off (INPUT; high Z), or ON & LOW. As the data sheet implies, the GPIO pins are push-pull --basically NMOS to GND and PMOS to V3.3. In this circuit, you are just using the NMOS portion.
 
Last edited:
Easy enough to try JP3141, it will take a few weeks to get a redesigned board back from OSH Park but it is worth an experiment I think.

How to turn the GPIO completely off? Must be simple but I don't know the syntax.

I mean how to do this:

If you try this, the transistor should be turned off by disabling the pin (write zero to the config register), not just by making it an input.
 
...

Just to be clear -- in my previous drawing, M1, and M3 are the internal FETs
So, this must mean that you propose two IO pins be used for onehorse's purpose? My 'bleating' has been based on an idea that onehorse did not want to give up more than one io pin.

I know that mosfets are notorious for not matching much in batch let alone outside of batch but onehorse's requirement does not necessarily need perfection and I think values can be found for the resistors in the scheme I propose that will make the majority of units built behave more than adequately - whether either mosfet reaches a full 'on' or 'off' condition isn't as important as the overall resistance shown to the sensor's sensor (pardon pun) being within a few hundred ohms of the target.
 
I am warming to the idea of having the resistors in series to ground with the Teensy GPIO dividing them, which I think was your original idea robsoles. The attraction is only the second resistor need be added and the resistance control is through software; easy enough. The downside is the user has to use a ready made code (which they will likely do anyway since I will provide a Teensiduino sketch) and give up one of the GPIO pins. This last isn't really so bad since the breakout board already has one orphan pin out that, while it could be used for another purpose, is really just begging for a purpose on the sensor breakout board. So all in all, I might give this idea a go. One last detail though. What is the best way to turn off the GPIO when I want the full series resistance. pinMode(x, INPUT)? How to turn the GPIO off in the configuration register of the MK20 as Paul Stoffregen suggested?
 
I cannot see it needing more than 'pinMode(x,INPUT);' to disengage enough to let the entire resistance be seen and 'pinMode(x,OUTPUT); digitalWrite(x,LOW);' (LOW probably already asserted on pinMode(n,OUTPUT) command but no harm in being explicit) should be all that is required to 'hide' the other resistor from the Sensor.

I had a quick flick through K20P64M72SF1RM.pdf and I saw where to start digging for what Paul was talking about regarding pin control, pretty sure; start on page 221 in section 11.1.4 - I will not be surprised to learn that it takes referring to more than 15 pages, coming from both before and after that page, to become sure of how to drive it properly.
 
I've done various versions of switched resistors including faking the input to A/C controller expecting a thermistor by going pinMode(X,INPUT) on the resistor(s) I wanted removed from the circuit. As noted above using say four pins doesn't get you 16 values (well it does, but many of them are to close to be useful) and part tolerance is critical for vaguely linear output (my 16 R version had areas of reverse slope). For single pin purposes if you wanted to get really tricky activating the pullup will also give you a third sensor value that is higher than the base R, but this starts depending a great deal on the exact design of your component and it's internal resistances.

Abusing ohms law with active components is always interesting and often counter intuitive.

Just be careful that your application doesn't put more than 3.3V on your high Z pins since then the clamping diodes start to come into play for yet another R value.

For over engineering and not applicable to this use case you can also use a basic transistor and adjust it's base voltage via filtered PWM or true Analog out to achieve variable R, but of course the result is highly non linear and very temperature sensitive (so to be useful needs bias networks plus A/D -> feedback loop which starts getting silly). Also possible where the target circuit is using an A/D to read a variable resistance sensor is to use a fixed resistor to the T3.1 Analog out, basically giving you an adjustable ground potential. Do take note of the analog out current limits when trying this.
 
hardware/teensy/avr/cores/teensy3/pins_teensy.c said:
Code:
void pinMode(uint8_t pin, uint8_t mode)
{
	volatile uint32_t *config;

	if (pin >= CORE_NUM_DIGITAL) return;
	config = portConfigRegister(pin);

	if (mode == OUTPUT) {
#ifdef KINETISK
		*portModeRegister(pin) = 1;
#else
		*portModeRegister(pin) |= digitalPinToBitMask(pin); // TODO: atomic
#endif
		*config = PORT_PCR_SRE | PORT_PCR_DSE | PORT_PCR_MUX(1);
	} else {
#ifdef KINETISK
		*portModeRegister(pin) = 0;
#else
		*portModeRegister(pin) &= ~digitalPinToBitMask(pin);
#endif
		if (mode == INPUT) {
			*config = PORT_PCR_MUX(1);
		} else {
			*config = PORT_PCR_MUX(1) | PORT_PCR_PE | PORT_PCR_PS; // pullup
		}
	}
}
I just added *portConfigRegister(15)=0; to some code I've been working on lately - didn't break my compilation, I think it does the job Paul was suggesting to do.
 
Ironic that after all this fine discussion I was just informed by Vishay that they are working on a successor to the VEML6070 that 1) is much smaller, 2) has only four pins 3) has an internal register for setting integration time so no set resistor to have to choose and vary, 4) detects both UVb and UVa spectra independently, 5) has no interrupt so is much easier to integrate into an appallingly small board. Just don't know about the relative cost of the soon-to-be-released VEML6075 versus the current VEML6070. I asked for samples and will switch to the VEML6075 when they become available for my application so I won't be needing all the fancy pin-controlled resistance after all!

Still very useful education for me.

Thanks everyone who contributed!
 
Not to extend the conversation unnecessarily, but I have an idea on how how use 1 pin to control multiple resistances.

It may not work -- it depends on how the VEML6070 uses the resistor. Basically, you PWM the additional resistor. Whether or not this works depends on how the VEML6070 uses the resistance internally. If it uses it to adjust the frequency of the internal timer, it might work.

Basically, to change from (say) 270 k to 540k and 1 M, put a 270 k between the VEML6070's resistor pin and the Teensy's GPIO. Then put a 730k (or close) from that pin to GND. Now PWM the GPIO pin. At 0 % duty cycle, you'll have 1 M, at 100 %, you'll have 270k; in between you'll have a combination (basically, its 270k*D + 1M*(1-D) == 1M - D*720k). If you PWM fast enough (and this depends on how the VEML6070 uses the value at the pin), it will probably work. I'd guess that 100's of kHz should work; depending on the internal architecture, perhaps 1 kHz would work.

I don't know if it is possible to directly PWM a Teensy pin from input (high Z) to output LOW mode; alternatively using delay() and code could be used; perhaps with timer-driven interrupts.
 
I think I could make that idea work with pwm (at least as well as it could) if I add a cap and (unfortunately) a mosfet - oh, another resistor from node of 270K and 730K (and new cap) to the mosfet might help the resultant 'resistance' appear smoother.

@onehorse: It is typical, while designing electronic assemblies, to put bunches of effort into figuring out stuff that gets ruled out of need before the designs are finalised - with a bit of luck someone will want something similar and find this thread.
 
Last edited:
Status
Not open for further replies.
Back
Top