Minimum slew rate = ?

[Odessa]

This question is perhaps better addressed to Microchip tech. support, but I thought there might be someone here that knows the answer through experience, so here goes:

When using the pulsin command on the 08M powered at Vdd=5V, what is the minimum slew rate allowable for logic level signals so that the device can accurately detect high-to-low or low-to-high transitions?

I checked the 12F683 data sheet and did not find anything on this particular parameter. It does state that the inputs are TTL compatible when operating as GPI, and standard logic series data sheets for HC equivalent devices (high speed CMOS) show minimum slew rate = 0.

Of course, there is a timeout of just over 1 minute for this command, so that would set the minimum operational slew rate, but my signals are much, much faster than that. I expect 5 msec. or so transitions, and don't want any nasty surprises if those signals are too slow to detect.

There are some pins with schmitt trigger inputs, but not when operating as GPI. Of course, if that were available here, this issue would be a don't-care....

Additionally, I could turn the pin into an A/D and detect pulses that way, but that takes LOTS more code, so I am trying to stay away from that....

Thanks, Odessa.

 

[Technical]

This command is actually level based, not rising/falling edge based, and so the speed of rise/fall is not so relevant. Any logic level transition should be fast enough.

Basically a 10us (at 4MHz) loop reads the input logic level. When the pin goes high timing starts, when it goes low, timing stops (or vice versa). Therefore the pin is effectively tested for a high/low status once every 10us loop.

 

[womai]

The problem with too low a slew rate is that it can cause double triggering whenever there is just a tiny amount of noise on the input, so you'd measure a very short pulse width because the input goes high, then immediately low again, then high, ...., until it finally settles for high. Not an issue if your input is a Schmitt trigger (this is what they are made for).

If the input gets checked every 10us, then the edge should move through the uncertainty region in less than that time, in other words, if your noise (input signal noise + input receiver noise) is e.g. 10mV for a 5V swing, then the transition should change by >10mV in less than 10us; this works out to a required slew rate of 10E-3/10E-6 = 1000V/sec, or a rise time of smaller than approx. 5V/1000V/s=5msec. Note that 10mV noise is rather small, so your mileage may vary.

Wolfgang

 

[Odessa]

"Any logic level transition should be fast enough."

Ok, guys, thanks for those initial responses.

There are two considerations here (outside the noise issues Wolfgang mentions): the actual functionality of the Pulsin command is one of them, and you have clarified that, Technical. The other consideration is potential input-stage output oscillations (internal to the Pic's gen. purp. input) that occasionally can occur due to parasitic capacitance forming an undesired feedback loop with the input impedance when an indeterminate state is present at the input, i.e. the input voltage is between valid logic high and logic low signal levels. On some devices if the transition is too slow and the input spends too much time between allowable logic levels, very high frequency oscillations can occur at the output of that input stage. My remaining question is whether anyone knows if the 08M exhibits any anomalies of this variety?

Odessa

PS Regarding the manual, for the Pulsin command, it states: "If state = 1 then a low to high transition starts
the timing, if state = 0 a high to low transition starts the timing." This makes it seem like this command is edge driven, and not level driven. I suggest changing the text to indicate that logic-level-state-changes (and not the actual transitions) initiate the timing.

 

[jglenn]

Some logic inputs will oscillate if the input is around 2.5V, clock inputs in particular are sensitive to slow rate of rise, so they usually have schmitt triggers built into the inputs. This is the solution if you are worried, add a 4584 or eq. The chance that the command will be looking at the input right when it changes is pretty small. But putting potentially "analog" signals into a digital input can cause problems, it is up to you to condition it before feeding in. I used to deal with very fast TTL circuits, even propagation time mattered in some cases. I think it was about 10nS per gate..

 

[Odessa]

"...schmitt triggers built into the inputs. This is the solution if you are worried..."

Yes, I mentioned schmitt triggers in my initial post, however, due to cost considerations, I don't want to introduce this unless absolutely necessary; THAT is why I am asking this question here on this forum, to see if anyone might have already done something like this and can report one way or the other, if they encountered problems or not...

It is possible, as is the case on standard HC5400 series devices, that there is no restriction on minimum slew rate, in which case I will be quite happy to not buffer the signal in any way....that would be the least expensive solution, but only if it is absolutely reliable.

Thanks, Odessa

 

[jglenn]

I suggest you try it without any buffering, look at the signals on a scope.

If it goes crazy, add the schmitts. A 4584 is about 80 cents, you get 6 gates, that is......HELP I CAN'T DO MATH IN MY HEAD ANYMORE......per gate.

 

[hippy]

PS Regarding the manual, for the Pulsin command, it states: "If state = 1 then a low to high transition starts the timing, if state = 0 a high to low transition starts the timing." This makes it seem like this command is edge driven, and not level driven. I suggest changing the text to indicate that logic-level-state-changes (and not the actual transitions) initiate the timing.

I think it's a case of what one understands by "transition" or reads into that. PULSIN starts and stops timing on having detected a change from low to high or vice-versa, and such a change of state is by dictionary definition a transition. "Transition" or "change of state" will likely both have people reading one as the other.

I guess it's further complicated that, although not truly edge triggered, there is usually an implicit rising or falling edge in any such change of state or transition and it's easy to think of PULSIN being edge triggered.

I'm not personally convinced that any change of terminology will make the explanation of PULSIN any clearer and not make it more complicated or difficult to understand but I am sure we will consider the issue further.

 

[BeanieBots]

I don't think there is any confusion over how the pulsin command works but more to do with how an 08M input behaves with an analogue level around the switching threshold.
Without having an internal circuit diagram I can't say for sure but I have used "slow" transistion voltages (potentiometer) without any noticeable issues except for a marked increase in supply current.

Hence, it is not advised to have voltages "hang around" the threshold for long periods of time (several seconds) but I cannot see any issues arising from using slow (10's of mS) transistions.

EDIT: Naturally, good decoupling will eleviate any issues arising from varying threshold points which might arise from supply noise caused by internal switching transients on the supply.

 

[Odessa]

I will run tests on this application and post my results here for anyone interested.

The definitive test would be to input a low frequency triangle wave and test over temperature. My test will not be that extensive, but I will have a data point for a slowly moving input signal....

Odessa.

 

[eclectic]

I have probably missed something,
in the postings on this thread, but,

might it also depend on whether input 2 (ST) is used?

See post #1 in
http://www.picaxeforum.co.uk/showthread.php?t=8609

Otherwise, I'll go back to sleep.

e

 

[Odessa]

Eclectic, you are absolutely correct, and I had missed that in the 12F683 data sheet for input 2 when configured as a general purpose input. As it turns out, my slowly moving signal is on input2 according to my schematic, so I think we can predict the outcome of my test on that one......

I may run a separate test on an 08M with the triangle wave, at room temp, just to see what happens on the other inputs, and report that back here.

Thanks for noticing ST on pin2!

Odessa.

 

[hippy]

I'm a bit confused; are we talking about digital input signals or analogue signals into a digital pin ?

Admittedly all digital signals are analogue on a small enough timescale, hence the matter of slew rate.

A signal hanging around for too long in the indeterminate voltage level of a TTL input is really the issue; at one time that may be read as zero on another as one then back to zero, all randomly. Electrical noise can also push the signal across switching points.

Because PULSIN is level-sampling, a signal in the indeterminate region could cause it to mis-read its level on consecutive samples, so the slew rate for PULSIN becomes its minimum sampling period ( 10us at 4MHz ).

Schmitt inputs should not generally suffer any problems providing there is little electrical noise and the input voltage is not swinging erratically between the two high and low switching points.

 

[Odessa]

"I'm a bit confused; are we talking about digital input signals or analogue signals into a digital pin ?"

If the consideration were strictly digital input signals, there would be no reason to have this thread. The input signal is a relatively slowly changing analog signal (5 msec transitions, or so), between expected and allowable logic levels, i.e. in this case, 0V & 5V.

In general, there are many applications, when interfacing real-world signals to a uC where these input considerations are applicable. The Schmitt Triggers nearly universally solve any minimum slew rate problems (as long as the input signal is monotonic, or its lack of monotonicty about the switching threshold is less than the hysteresis) because they have built in hysteresis.

Odessa.