Ok, stupid question time.. Could someone please define for me once and for
all the meaning of the "Schmitt Trigger" and how it differs from TTL? Also
the Schottkey, but I think this is just a low power TTL...
Shawn Ellis wrote:
>
> Ok, stupid question time.. Could someone please define for me once and for
> all the meaning of the "Schmitt Trigger" and how it differs from TTL? Also
> the Schottkey, but I think this is just a low power TTL...
The schmitt trigger is simply a buffer or an inverter with hysteresis
at the input.A rising signal will trigger a change in output when the
voltage reaches say 66% but if the voltage then starts to decrease the
output will not change state until the voltage drops to say 33% this
difference in trigger levels is the hysteresis and is useful for
squaring
slowly rising signals and removing noise from signal lines which is why
it
is used for the data & clock pins on the 16c84 in programming mode for
instance.
regards Tony M.
just this guy ya know
Hi All
>
> Shawn Ellis wrote:
> >
> > Ok, stupid question time.. Could someone please define for me once and for
> > all the meaning of the "Schmitt Trigger" and how it differs from TTL? Also
> > the Schottkey, but I think this is just a low power TTL...
> The schmitt trigger is simply a buffer or an inverter with hysteresis
> at the input.A rising signal will trigger a change in output when the
> voltage reaches say 66% but if the voltage then starts to decrease the
> output will not change state until the voltage drops to say 33% this
> difference in trigger levels is the hysteresis and is useful for
> squaring
> slowly rising signals and removing noise from signal lines which is why
> it
> is used for the data & clock pins on the 16c84 in programming mode for
> instance.
> regards Tony M.
I think following figure will make whole thing clear.
It is a characteristic of Scmitt trigger.
(plot of Output voltage versus Input voltage.)
figures are arbitrary and not to scale.)
Arrows indicate travel of plot. When Input increases till 2.5V
Output remains at logic "0" then goes to logic "1".
When input decreases below 2.5 V it won't come to logic "0"
(unlike comparator) It will come to "0" only when input
reaches 1.5V.
Shawn Ellis wrote:
>
> Ok, stupid question time.. Could someone please define for me once and for
> all the meaning of the "Schmitt Trigger" and how it differs from TTL? Also
> the Schottkey, but I think this is just a low power TTL...
Schmitt trigger circuits are designed to convert slowly varying analog
inputs into fast switching digital outputs that can be fed into standard
logic gates. Digital gates want their inputs to switch instantly from
low to high and vice versa. They tend to do strange and nasty things,
such as oscillate or burn up, when their input voltages rise to the
point where the output starts to switch and stay there.
Typically, the output of a schmitt trigger stays low as it's input rises
above zero until the input reaches a threshold voltage that is usually
somewhere around half of the power supply voltage. At this point, the
output instantly (a few nanoseconds) changes from low to high. The
output then stays high until the input voltage goes a bit lower than the
original threshold voltage.
The difference between the input voltage that switches the output high
and the lower voltage that switches it low again is called hysteresis.
It keeps the schmitt trigger's output from switching rapidly up and down
due to noise and ripple on the input.
Schmitt triggers with inverting outputs are also available, of course.
So, I put complex triggers on each of the panic gotos, so I can trigger my
scope when they occur.
That worked just fine.
However, later, I commented out panic_a and panic_c.
When I breakpoint, and pull up the trace memory, it shows that I came
through panic_a, which now looks like this:
(some code)
;btfss port,bit
;goto panic_a
I did re-assemble, reset, and run, and I even tried closing the entire
project and coming back in.
Still, according to the trace, it's getting to the panic code, via panic_a.
It's difficult to debug, when you get things like this.
On Fri, 11 May 2001, David VanHorn wrote:
> I'm getting some anomalous behaviour.
<SNIP>
> However, later, I commented out panic_a and panic_c.
> When I breakpoint, and pull up the trace memory, it shows that I came
> through panic_a, which now looks like this:
>
> (some code)
> ;btfss port,bit
> ;goto panic_a
>
> I did re-assemble, reset, and run, and I even tried closing the entire
> project and coming back in.
> Still, according to the trace, it's getting to the panic code, via panic_a.
Just a random thought, but did you comment out the panic_a label?
At 11:29 AM 5/11/01 -0700, David W. Gulley wrote:
>On Fri, 11 May 2001, David VanHorn wrote:
> > I'm getting some anomalous behaviour.
><SNIP>
> > However, later, I commented out panic_a and panic_c.
> > When I breakpoint, and pull up the trace memory, it shows that I came
> > through panic_a, which now looks like this:
> >
> > (some code)
> > ;btfss port,bit
> > ;goto panic_a
> >
> > I did re-assemble, reset, and run, and I even tried closing the entire
> > project and coming back in.
> > Still, according to the trace, it's getting to the panic code, via panic_a.
>
>Just a random thought, but did you comment out the panic_a label?
David VanHorn <EraseMEdvanhornspam_OUTTakeThisOuTCEDAR.NET> on 2001-05-11 11:11:29 AM
> When I breakpoint, and pull up the trace memory, it shows that I came
> through panic_a, which now looks like this:
>
> (some code)
> ;btfss port,bit
> ;goto panic_a
>
> I did re-assemble, reset, and run, and I even tried closing the entire
> project and coming back in.
> Still, according to the trace, it's getting to the panic code, via panic_a.
In MPLAB, when I see things like this, I do
Ctrl+F10
(re-build every file -- when I modify an include file the normal "build"
doesn't catch it)
Program
Reset
Run
It sounds like it hasn't been programmed with your latest version.
Can you read-out the ROM and see that it really has what you think it does ?
>
>In MPLAB, when I see things like this, I do
> Ctrl+F10
> (re-build every file -- when I modify an include file the normal "build"
>doesn't catch it)
> Program
> Reset
> Run
That's what I do every time.
Building less than all never made sense to me. Takes all of about 5 sec to
assemble.
>It sounds like it hasn't been programmed with your latest version.
>Can you read-out the ROM and see that it really has what you think it does ?
> no, but according to the trace, it's executing the commented
> line "goto
> panic_a"
I'm not too familiar with MPLAB, but perhaps it is because the assembler or
debugger only "remembers" the first label for a location it finds.. panaic_a
is the first one, the rest also happen to point to the same location, but it
probably looks that location up in a table and finds "panic_a" when it comes
to the goto statement in the debugger.
Try separating the labels with NOPs to force different location:
At 08:14 PM 5/11/01 -0400, Bob Ammerman wrote:
>David:
>
>I am pretty sure the history buffer is displayed using disassembly, as
>opposed to grabbing lines from the source code. Is this right?
>
>If that is the case then, given that 'panic_a', 'panic_b', 'panic_c' and
>'panic_d' all label the same location, the dissambly can't tell them apart.
Yeabut.
I thought of that, so I made the target like this:
Panic_a: movlw 1
Panic_b: movlw 2
etc.
The thing is, I'll end up somewhere in the middle of that, but in the
trace, is the "goto Panic_a" instruction, which has a semicolon in front of it!
The key seems to be, that I made the triggers, then commented them out.
Apparently, if it's a complex breakpoint, it can't be commented out ..
At least that's how it seems to me.
>
> At 11:29 AM 5/11/01 -0700, David W. Gulley wrote:
> >On Fri, 11 May 2001, David VanHorn wrote:
> > > I'm getting some anomalous behaviour.
> ><SNIP>
> > > However, later, I commented out panic_a and panic_c.
> > > When I breakpoint, and pull up the trace memory, it shows that I came
> > > through panic_a, which now looks like this:
> > >
> > > (some code)
> > > ;btfss port,bit
> > > ;goto panic_a
> > >
> > > I did re-assemble, reset, and run, and I even tried closing the entire
> > > project and coming back in.
> > > Still, according to the trace, it's getting to the panic code, via panic_a.
> >
> >Just a random thought, but did you comment out the panic_a label?
>
> no, but according to the trace, it's executing the commented line "goto
> panic_a"
David, the IDE doesn't handle stacked (overloaded)
goto labels very well. If you have two labels with
one line of code, (like if you comment-out the code
but leave a label) the MPLAB IDE will decide which
label it will accept for debugging etc.
Have a look at the code in the ROM window, then top
left button of it to select "dissassembly display"
then you can see which of the labels the debugger
has used. I imagine it always uses the first (or last)
label if they are stacked. I don't know which because
I try to avoid stacking labels for exactly the reason
you have now! :o)
-Roman
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
At 04:52 PM 5/12/01 +1000, Roman Black wrote: {Quote hidden}
>David VanHorn wrote:
> >
> > At 11:29 AM 5/11/01 -0700, David W. Gulley wrote:
> > >On Fri, 11 May 2001, David VanHorn wrote:
> > > > I'm getting some anomalous behaviour.
> > ><SNIP>
> > > > However, later, I commented out panic_a and panic_c.
> > > > When I breakpoint, and pull up the trace memory, it shows that I came
> > > > through panic_a, which now looks like this:
> > > >
> > > > (some code)
> > > > ;btfss port,bit
> > > > ;goto panic_a
> > > >
> > > > I did re-assemble, reset, and run, and I even tried closing the entire
> > > > project and coming back in.
> > > > Still, according to the trace, it's getting to the panic code, via
> panic_a.
> > >
> > >Just a random thought, but did you comment out the panic_a label?
> >
> > no, but according to the trace, it's executing the commented line "goto
> > panic_a"
>
>
>David, the IDE doesn't handle stacked (overloaded)
>goto labels very well. If you have two labels with
>one line of code, (like if you comment-out the code
>but leave a label) the MPLAB IDE will decide which
>label it will accept for debugging etc.
OK, but the problem isn't there.
When the only line of source in the project that reads:
"goto panic_a" has a semicolon in front of it, then it had better not show
up in a trace.
The problem appears to be that I had a complex trigger defined on this
line, and then commented it out (and rebuilt the entire project) It seems
that the complex trigger somehow overrides the commenting.
>Have a look at the code in the ROM window, then top
>left button of it to select "dissassembly display"
>then you can see which of the labels the debugger
>has used. I imagine it always uses the first (or last)
>label if they are stacked. I don't know which because
>I try to avoid stacking labels for exactly the reason
>you have now! :o)
> The key seems to be, that I made the triggers, then commented them out.
> Apparently, if it's a complex breakpoint, it can't be commented out ..
> At least that's how it seems to me.
Geesh, Dave. And you still expect it give you the right trace after that!?
That's asking an awful lot.
> When the only line of source in the project that reads:
> "goto panic_a" has a semicolon in front of it, then it had better not
show
> up in a trace.
Not so. It could show up if you have GOTO PANIC_B, and PANIC_B = PANIC_A.
At 05:40 PM 5/12/01 -0400, Olin Lathrop wrote:
> > The key seems to be, that I made the triggers, then commented them out.
> > Apparently, if it's a complex breakpoint, it can't be commented out ..
> > At least that's how it seems to me.
>
>Geesh, Dave. And you still expect it give you the right trace after that!?
>That's asking an awful lot.
I'm a picky bastard, for some reason, I expect it to execute the code I
wrote, with no additions or deletions. :)
I want to use a comparator in an F628 in mode 6 with comparator outputs
available off-chip. I intend to use the usual resistor network to add
hysteresis to the comparator and use it as a schmitt trigger.
Has anyone done this?
Any problems in using the on-chip comparators in this mode?
Will the PIC I/O on the comparator affect the calculations for hysteresis?
Regards
Andrew Crosland
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
I think that using hysteresis on any comparator is almost every time
necessary. Comparator have a large offset, about 20mV, is a pour one.
I dont see any reason to not work. Internal port resistence can't affect
too much the hysteresis computation. Large hysteresis, small errors.
> Hi,
>
> I want to use a comparator in an F628 in mode 6 with comparator outputs
> available off-chip. I intend to use the usual resistor network to add
> hysteresis to the comparator and use it as a schmitt trigger.
>
> Has anyone done this?
>
> Any problems in using the on-chip comparators in this mode?
>
> Will the PIC I/O on the comparator affect the calculations for hysteresis?
>
> Regards
>
> Andrew Crosland
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
>
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, John Kauffman wrote:
I am trying to figure out the time resolution for resolving two near-simultaneous triggers on two pins of an SX. As I understand a B pin trigger, the following sequence occurs: Pin has WKEN=0 set at start Pin is triggered SX changes its WKPND to 1 SX immediately shuts off any other pin from being set to WKPND=1 SX begins ISR I am wondering about the timing of "immediately" in the above sequence. Does that shut-off occur on the very next clock cycle? If yes, when using the internal 4Mhz clock that would mean a second trigger would be locked out provided it was at later by at least 1 / 4,000,000 seconds = 250 nanoSeconds? Thanks. ---------- End of Message ----------
You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=154791 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:
John, I'm pretty sure the SX does not disable the other pins after one pin has WKPND set to 1. In the interrupt routine you can check for what bit of WKPND is set and only clear that one pin (here is where an interrupt can be missed, if it occurs right at the instruction where you are writing back to the WKPND register.
Bean.
---------- End of Message ----------
You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=154791#m154924 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)
I can't find this info in the datasheet. I measured (on a 3.3Vdd) 1.30V and 1.64V,
but I'd like to know if there are any official infos about these values.
Also, by making the (digital) input deliberately "float", I measured no anomaly in
the current drawn by the MPU. Perhaps the schmitt trigger prevents this to happen?
>Howdy,
>
>I can't find this info in the datasheet. I measured (on a 3.3Vdd)
>1.30V and 1.64V,
>but I'd like to know if there are any official infos about these values.
The data sheet gives no minimum or maximum (except the maximum implied
by the difference between the max and min thresholds). Even the thresholds
are "characterized but not tested". No guarantees. If you need guarantees,
you can use something external.
Much earlier chips gave a typical value of 0.15*Vdd, which is about 50%
more than you measured. Depending on your analog skills it could be a bit
tricky to make this measurement, and errors will tend to cause it to
read a lower value for the hysteresis (iow, it will trigger on noise).
I would power the chip on a proper PCB with ground plane, using an internal
clock and with good bypassing on the power. Put maybe 100 ohms in series with
the input being tested, then 1uF film to the common ground point, and
100K to the voltage source (measure across the capacitor). Presumably
you're driving an output with a program that reads the pin- use another
port and don't draw significant current (eg. drive the gate of a 2N7000
driving a separately (maybe battery) powered LED).
>Also, by making the (digital) input deliberately "float", I measured
>no anomaly in
>the current drawn by the MPU. Perhaps the schmitt trigger prevents
>this to happen?
The current will vary with the input state, but it should not get
very high. Have a look at the NXP datasheet for the 74HC14 to get an idea
of how it will likely behave wrt Vdd and input voltage (the numbers may not be
the same, of course).
comit.com)
