Searching \ for '[PIC] Transients when setting an output port to it' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=output
Search entire site for: 'Transients when setting an output port to it'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Transients when setting an output port to it'
2008\11\02@150550 by Rodent of Unusual Size

flavicon
face
Once again, the noob into the breach..

Does setting an output port low or high again -- whatever it's
current value is -- introduce any sort of tranient?  Will there
be a blip on the output port from this?  (example)

       BSF        PORTB, 2
       NOP
       NOP
       NOP
       NOP
       NOP
       BSF        PORTB, 2

I expect not, but I'm having trouble with my Velleman HPS40
and I'm not positive.  (I think I'm going to trade it in on
a *real* 'scope..)

I'm trying to avoid the extra cycles of a check (e.g.,

       BTFSS        PORTB, 2
       BSF        PORTB, 2

Thanks!

(BTW, my PICkit 2 should arrive tomorrow; thanks for the
advice, all!)
--
#ken        P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"

2008\11\02@163821 by Josh Koffman

face picon face
On Sun, Nov 2, 2008 at 3:05 PM, Rodent of Unusual Size
<spam_OUTRoUSTakeThisOuTspamsourcery.org> wrote:
> Does setting an output port low or high again -- whatever it's
> current value is -- introduce any sort of tranient?  Will there
> be a blip on the output port from this?  (example)
>
>        BSF     PORTB, 2
>        NOP
>        NOP
>        NOP
>        NOP
>        NOP
>        BSF     PORTB, 2


In theory, no, it doesn't.

HOWEVER, the oft disregarded RMW problem can rear its ugly head. See
here for more info: http://www.piclist.org/techref/readmodwrite.htm

The gist of it is that when you perform a pin specific operation, the
PIC will read the port into a buffer, do the operation, then write it
back to the port. Normally not a problem. But if something is pulling
that pin in a direction you aren't expecting, that unexpected value
might actually get written back to the port as a proper value. The
link above gives a much better explanation with examples!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2008\11\02@165822 by Jan-Erik Soderholm

face picon face


Josh Koffman wrote:
{Quote hidden}

RMW should not play a role when changing *the same* pin
two times in a row, as in the code example.

Question is, why asking ? What is it that he's seeing ?

Jan-Erik.

2008\11\02@170336 by Dr Skip

picon face
That would make sense, but for sake of argument, and to more thoroughly
understand any issues involved, let me ask essentially the same question
another way:

Assume the outputs are all driving transistor bases with a pullup on each base.
 One then wants to toggle every other bit _except_ bits 3 and 4 (arbitrary
selection), including setting these others to inputs, outputs, high, low, but
from the beginning of the program, 3 and 4 were initially set as outputs and to
a value (one high and one low) and monitored.

Is there any operation that doesn't directly alter bits 3 and 4 (like clearing
the whole byte) yet would cause any pulse or change of state for even a minimal
amount of time?

If the pullups cause a problem in this scenario, use another output
arrangement, but please specify. They should be fine though IMHO.

That should about cover it. ;)

[can you tell I'm interested in the answer too?] ;)

-Skip



Josh Koffman wrote:
{Quote hidden}

2008\11\02@174643 by Jinx

face picon face

> Does setting an output port low or high again -- whatever it's
> current value is -- introduce any sort of tranient?

You may see electrical transients and have read-modify-write issues

http://www.piclist.com/techref/scenix/sxrmw.htm

2008\11\02@190323 by Isaac Marino Bavaresco

flavicon
face
Perhaps not related to your problem, but once I had problems with I/O pins:

I was driving two high-impedance inputs with two PIC pins, but the
values I was writing were not appearing at the pins.

Then I made a test loop, writing the values over and over, very rapidly
and I could see on the scope that the pins glitched very shortly (less
than a microsecond) after each write.

After that I realized that I forgot to set the pins as outputs. When I
corrected this all worked OK.

The only thing that seems strange is that with the pins as inputs, the
internal latch state should never affect the outside pin state, but it did.

Best regards,

Isaac


Rodent of Unusual Size escreveu:
{Quote hidden}

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\11\02@215046 by Sean Breheny

face picon face
Which pic was used in this example? Could it be that the output latch
on some PICs controls whether a pull-up is applied to the pin when it
is set as an input?

Sean


On Sun, Nov 2, 2008 at 8:01 PM, Isaac Marino Bavaresco
<.....isaacbavarescoKILLspamspam.....yahoo.com.br> wrote:
{Quote hidden}

>

2008\11\02@232900 by Rodent of Unusual Size

flavicon
face
Josh Koffman wrote:
>>
>>        BSF     PORTB, 2
>>        NOP
>>        NOP
>>        NOP
>>        NOP
>>        NOP
>>        BSF     PORTB, 2
>
>
> In theory, no, it doesn't.
>
> HOWEVER, the oft disregarded RMW problem can rear its ugly head. See
> here for more info: http://www.piclist.org/techref/readmodwrite.htm

So the following is safe and will never introduce a transient?

       MOVLW        B'100'
       IORWF        PORTB,F

And in answer to the question about 'what have I seen'.. I don't
know if I'm seeing anything or not.  I'm having trouble getting
readings with my HPS40.  No problem with the crystal waveform,
but I can't get a reliable squarewave off the outputs (they're
working correctly according to the Mark I eyeball and a LED).
So I don't know if there's anything there or not; anomalous
results.  Probably doing something wrong with the 'scope..
--
#ken        P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"

2008\11\03@002252 by Jinx

face picon face
> So the following is safe and will never introduce a transient?
>
> MOVLW B'100'
> IORWF PORTB,F

I have a feeling that operations like IOR/AND/ADD/XOR etc would
read the register first, leading to a possible r-m-w

You should be safe with BSF and MOVWF though. Particularly if the
port contents are read into a buffer or shadow register, modified, and
then written back with MOVWF

eg

MOVF PORTB,W
MOVWF SHADOWB
MOVLW B'100'
IORWF SHADOWB,W
MOVWF PORTB

The problem with PICs < 18 is that i/p and o/p share some pin logic. PICs > 16
have separate outputs (LAT) and inputs (PORT) and r-m-w is not an issue

2008\11\03@022201 by Ruben Jönsson

flavicon
face
> You should be safe with BSF and MOVWF though. Particularly if the
> port contents are read into a buffer or shadow register, modified, and
> then written back with MOVWF
>
> eg
>
> MOVF PORTB,W
> MOVWF SHADOWB
> MOVLW B'100'
> IORWF SHADOWB,W
> MOVWF PORTB
>

One thing to watch out for here is interrupts. If you write to another pin in
port B in the interrupt routine, a bit banged serial output for example, you
have to make sure that the interrupt routine isn't executed between when you
read the content of the port to the shadow register until you write it back.
Otherwise the change made by the interrupt routine will be undone when you
write back the shadow register.

One way to solve this is to never read the the value from the port to the
shadow register but keep the shadow register as a global variable and only
manipulate it with atomic operations (single instructions that can't be
interrupted or where an ongoing change in non interrupt code can't be undone by
interrupt code or vice versa) like IORWF, BSF, BCF and so on. Then just write
the entire shadow register to the port when you have changed it. This would
have the same effect as using the LAT registers in higher end pics.

Note that using the LAT register handles classic rmw issues with ouput port
pins but it doesn't automatically solve problems where main code and interrupt
code uses the same port (or any register) unless changing of individual bits is
done with care (changed in what I call atomic, uninterruptable steps).

Another way to put it is that interrupt routines can introduce rmw problems
where you normally wouldn't see it (or think about it). And this goes for any
shared register, not just IO ports.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
EraseMErubenspam_OUTspamTakeThisOuTpp.sbbs.se
==============================

2008\11\03@024109 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jinx wrote:
{Quote hidden}

With respect to read-modify-write, BSF is not safe. BSF/BCF operate by
reading the port, altering the relevant bit, and writing the port. An
operation that definitively sets the value of every single bit (e.g.
movwf) is the *only* completely safe way to deal with RMW.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkOqvsACgkQiD2svb/jCb6ixgCfWWtfTwAiKS1dh2M573SUbv20
VQ0AnRoDqr6tEBt1SCV9DoZ5jF8z+KXl
=CpLH
-----END PGP SIGNATURE-----

2008\11\03@025302 by Jinx

face picon face
> With respect to read-modify-write, BSF is not safe. BSF/BCF
> operate by reading the port, altering the relevant bit, and writing
> the port. An operation that definitively sets the value of every
> single bit (e.g. movwf) is the *only* completely safe way to deal
> with RMW.

Yes, good point, my bad. Other ways except MOVWF do depend
on the user knowing what conditions (can) exist on the pins

2008\11\03@025619 by Wouter van Ooijen

face picon face
>> MOVF PORTB,W
>> MOVWF SHADOWB
>> MOVLW B'100'
>> IORWF SHADOWB,W
>> MOVWF PORTB
>>
>
> One thing to watch out for here is interrupts. If you write to another pin in
> port B in the interrupt routine, a bit banged serial output for example, you
> have to make sure that the interrupt routine isn't executed between when you
> read the content of the port to the shadow register until you write it back.
> Otherwise the change made by the interrupt routine will be undone when you
> write back the shadow register.

Good programming practice would dictate that the interrupt routine also
uses the shadow, so there would be no problem.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\11\03@033550 by Jinx

face picon face
> One way to solve this is to never read the the value from the port to
> the shadow register but keep the shadow register as a global variable

That would be impractical if you have to monitor inputs. I'm sure that
eg btfss pin / btfsc pin reads the port

2008\11\03@042013 by Ruben Jönsson

flavicon
face
> >> MOVF PORTB,W
> >> MOVWF SHADOWB
> >> MOVLW B'100'
> >> IORWF SHADOWB,W
> >> MOVWF PORTB
> >>
> >
> > One thing to watch out for here is interrupts. If you write to another pin in
> > port B in the interrupt routine, a bit banged serial output for example, you
> > have to make sure that the interrupt routine isn't executed between when you
> > read the content of the port to the shadow register until you write it back.
> > Otherwise the change made by the interrupt routine will be undone when you
> > write back the shadow register.
>
> Good programming practice would dictate that the interrupt routine also
> uses the shadow, so there would be no problem.
>

Yes, there still could be problems if the interrupt is just after IORWF
SHADOWB,W. Then changes done in the interrupt routine will be undone when the
non interrupt code does MOVWF PORTB. The key is, appart from using a shadow
register, is to never read back from the port to the shadow register.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
rubenspamspam_OUTpp.sbbs.se
==============================

2008\11\03@042035 by Ruben Jönsson

flavicon
face
Inputs don't use the shadow register. Just read the port directly.

btfss/btfsc does ofcourse read the port but they don't write anything back so
there is no rmw issue here and it doesn't involve the shadow register at all.

You can even read the outputs and verify that they are the same as the shadow
register. Only the output bits then ofcourse. If they are not the same, it
could be because an output is shorted or overloaded.

/Ruben

> > One way to solve this is to never read the the value from the port to
> > the shadow register but keep the shadow register as a global variable
>
> That would be impractical if you have to monitor inputs. I'm sure that
> eg btfss pin / btfsc pin reads the port
>
> -

2008\11\03@042522 by Jan-Erik Soderholm

face picon face


Christopher Head wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jinx wrote:
>>> So the following is safe and will never introduce a transient?
>>>
>>> MOVLW B'100'
>>> IORWF PORTB,F
>> I have a feeling that operations like IOR/AND/ADD/XOR etc would
>> read the register first, leading to a possible r-m-w
>>
>> You should be safe with BSF and MOVWF though. Particularly if the
>> port contents are read into a buffer or shadow register, modified, and
>> then written back with MOVWF
>
> With respect to read-modify-write, BSF is not safe. BSF/BCF operate by
> reading the port, altering the relevant bit, and writing the port.

But what Jinx talked about was to execute the BSF/BCF against
*another* register, not the PORTx register. And in that case it's
"safe", of course. And "IORWF PORTx,F" isn't better than BSF/BCF
in this regard.

And, remember also that *no* operation that reads the PORTx register
is safe. Remember that it is in the *read* phase the RMW is
introduced. So this code (from another post) :

> MOVF PORTB,W
> MOVWF SHADOWB
> MOVLW B'100'
> IORWF SHADOWB,W
> MOVWF PORTB

isn't a single bit (!) better then a simple BCF/BSF, since it's
in the "MOVF PORTB, W" that the error is introduced. The rest
of the code can't do much about it after that, the SHADOWB
register already has the error...


> An
> operation that definitively sets the value of every single bit (e.g.
> movwf) is the *only* completely safe way to deal with RMW.

Or that you has concideded the potential RMW issues and designed
against it. That's isn't *that* hard either.

Finaly, since the O.P said he might be using an I/O pin
directly against the base of a standard transistor with
no current limiting resitor, he might have problems, some
which might look like the RMW problem.

Jan-Erik.

{Quote hidden}

2008\11\03@043917 by Ruben Jönsson

flavicon
face
{Quote hidden}

Also remember to not store any intermediate results in another register (even
W) and then write it back to the shadow register. Only use atomic, non
interruptable methods (single instructions or disable interrupts) when
manipulating the bits in the (global) shadow register.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
@spam@rubenKILLspamspampp.sbbs.se
==============================

2008\11\03@045804 by Ruben Jönsson

flavicon
face
> Ruben Jönsson wrote:
> > Inputs don't use the shadow register. Just read the port directly.
> >
> > btfss/btfsc does ofcourse read the port but they don't write anything back so
> > there is no rmw issue here and it doesn't involve the shadow register at all.
> >
> > You can even read the outputs and verify that they are the same as the shadow
> > register.
>
> But why doing that ?
>
> If you *are* using a shadow register it's becuse they are
> *not* (or might not be) the same becuse of RMW issues. If
> they are always the same you don't have any RMW issue
> and you do not need the shadow register in the first place.
>
> Jan-Erik.
>

I mean that you could do it to verify that the outputs are as expected - not
for bit manipulations while setting the indiviual bits as part of the normal
operation. That would, as you say, defeat the whole meaning of using the shadow
register.

The port bits might not be the same as the shadow register bits if the output
is shorted or overloaded and you might want to take some action then. This
check could be done periodically while not doing something else.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
KILLspamrubenKILLspamspampp.sbbs.se
==============================

2008\11\03@083222 by olin piclist

face picon face
Ruben Jönsson wrote:
> I mean that you could do it to verify that the outputs are as
> expected ...

You should understand the read-modify-write issue and ways to deal with it,
but geesh folks, get some perspective.

I've done somewhere around 100 PIC projects and have used shadow registers
maybe two or three times.  Yes, you should always be aware of the issue, but
most of the time it's not a problem.

PIC port pins are rated at 25mA and are implemented as FETs, so they look
mostly like resistors to Vdd or Vss.  Let's say a pin is allowed to droop
1.5V at 25mA (too lazy to look it up right now).  That implies a resistance
of 60 ohms.  Let's add a little margin and say a PIC output pin looks like a
Vdd or Vss voltage source with 100 ohms in series.  Even with a large
capacitive load of 1nF, that comes out to a time constant of only 100nS.
Two time constants gets you safely within the guaranteed logic one or zero
input levels.

PIC 16 (others have LAT registers) usually max out at 20MHz oscillator,
which means 5MHz instruction rate, which means 200nS instruction period.  So
unless you've got a really messed up external circuit, R-M-W only matters
within one instruction.  There is one Q cycle between the write of one
instruction and the read of the next.  That's only 50nS and could be a
problem.  Two instructions later (a single NOP between write and read for
example) gives you 250nS, which is going to be fine the vast majority of the
time.

So yes, keep R-M-W in mind, but it's a small niche problem and not something
you need to hit with a sledge hammer like "always use shadow registers"
which I hear way too often.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\03@094005 by Wouter van Ooijen

face picon face
Ruben Jönsson wrote:
>>>> MOVF PORTB,W
>>>> MOVWF SHADOWB
>>>> MOVLW B'100'
>>>> IORWF SHADOWB,W
>>>> MOVWF PORTB

>
> Yes, there still could be problems if the interrupt is just after IORWF
> SHADOWB,W. Then changes done in the interrupt routine will be undone when the
> non interrupt code does MOVWF PORTB. The key is, appart from using a shadow
> register, is to never read back from the port to the shadow register.

Hmmm you are right. But I don't understand your solution?

   BSF shadow, 0
   MOVFW shadow
   ===> interrupt here
   MOWF port

This sequence does not read the port, but changes made by the interrupt
would still be lost.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\11\03@114222 by Rodent of Unusual Size

flavicon
face
Ruben Jönsson wrote:
>
> Also remember to not store any intermediate results in another register (even
> W) and then write it back to the shadow register. Only use atomic, non
> interruptable methods (single instructions or disable interrupts) when
> manipulating the bits in the (global) shadow register.

Another part of this low end with which I'm not familiar..
If interrupts are disabled when one *would have* been delivered,
is it lost?  Or delivered if/when interrupts are re-enabled
(to some stack-limited number, no doubt)?
--
#ken        P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"

2008\11\03@124053 by Robert Young

picon face


>
> This HPS40 is pissing me off..  Half of the rare times when I
> can get a semi-reasonable square wave on it, it shows
> +/- pulses at the edges.
>
> Maybe I'll start a new thread about recommendations for
> 'scopes..

By +/- pulses do you mean you see ADDITIONAL pulses in the train with positive and negative going directions?  Or do you mean combinations of overshoot, undershoot and ringing in the leading and falling edges of the pulse?

If you mean the latter, I suggest you study the following from Tektronix.  It is among the best application for learning how to use and set up an oscilloscope: http://www.tek.com/Measurement/App_Notes/XYZs/  Translate controls and methods as necessary for your Vellman.

Some important points to remember about a scope (even the cheapo Vellman stuff):
1) If using a x10 or x100 probe (x10 is much more common) learn to compensate the probe so that you get the best impedance match and good looking edges.  I can't think of any x1 probes I've ever seen that had compensation that worked for a damn if at all.  They just have too much capacitance.  There are times when 50 Ohm or 500 Ohm direct connect cables and probes are nice and other times when you have to build your own too.

2) If you could have just one probe on your bench, use an x10 probe to minimize the loading of your signal.  You can get active probes that have even less capacitive loading and all kinds of special probing jigs and connectors but a nice x10 gets you a long, long way.  My personal preference is for fixed x10 probes, not the switchable kind.  And many Tek and HP scopes have a little ring and pin setup that can automatically tell the oscilloscope what kind of probe is attached.  A very nice feature to look for.

3) Don't use the 6" ground clip for anything except quick probing.  It is useless for looking at fast edges.  Do this instead:
http://www.pericom.com/pdf/applications/AN021.pdf  There are other descriptions of the technique out there but the picture in this app note is pretty clear.  Its all about the ground loop...

4) Use a probe with at least twice the bandwidth advertised for your oscilloscope.  To a first approximation, the risetime of your scope and the rise time of your probe combine as RMS and you will end up with LESS bandwidth than you started with.  I think your Vellman is something like 20MHz so a 100MHz bandwidth probe would be OK.

But at least read the Tek app note, that answes loads and loads of questions about good scope-ing.


2008\11\03@140145 by Ruben Jönsson

flavicon
face
{Quote hidden}

Yes, you are right. I only thought about manipulating the shadow register
itself. Not actually copying it out to the port. The copying will require that
interrupts are disabled if the copying can be done from both non isr and isr
code.

It will work if you don't need to copy, that is if you don't need a shadow
register. But then you have to be aware of the rmw issue. Unless you have a
latch register in the hardware, that is.

However, the initial point was that even with a latch register (or shadow
register) you have to be aware of interrupts if some bits in the register can
be manipulated by the isr code while other bits are manipulated by non isr code
at the same time.

/Ruben

==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenTakeThisOuTspampp.sbbs.se
==============================

2008\11\03@144710 by Jan-Erik Soderholm

face picon face


Ruben Jönsson wrote:
{Quote hidden}

A nice way to solve this (and if the I/O pins do not have to
e switched fast, such as e.g. indicator LEDs), is to only
BSF/BCF the "shadow" bits in the main code, and only copy
to the port in the ISR. That way you can manipulate the
indicator-LED bits wherever there is a need, and have a
safe update of the PORTx register in a single place in the
ISR.

Jan-Erik.


> ==============================
> Ruben Jönsson
> AB Liros Electronic
> Box 9124, 200 39 Malmö, Sweden
> TEL INT +46 40142078
> FAX INT +46 40947388
> spamBeGonerubenspamBeGonespampp.sbbs.se
> ==============================

2008\11\03@163303 by Ruben Jönsson

flavicon
face

>
> A nice way to solve this (and if the I/O pins do not have to
> e switched fast, such as e.g. indicator LEDs), is to only
> BSF/BCF the "shadow" bits in the main code, and only copy
> to the port in the ISR. That way you can manipulate the
> indicator-LED bits wherever there is a need, and have a
> safe update of the PORTx register in a single place in the
> ISR.
>
> Jan-Erik.
>
>

Yes, and to make things even easier in the code and not need to bother about
atomic operations there could be several shadow registers which each holds just
a group of bits or even single bits (flags) where each shadow register is
manipulated by different parts of the code, both isr and non isr code. The
(timer-) isr then combines all shadow registers to one single byte and writes
them all at once to the port.

/Ruben

==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
TakeThisOuTrubenEraseMEspamspam_OUTpp.sbbs.se
==============================

2008\11\03@175103 by Sean Breheny

face picon face
Those are some very good suggestions, Robert. Just a few clarifications:

On Mon, Nov 3, 2008 at 12:40 PM, Robert Young <RemoveMErwybeakerspamTakeThisOuThotmail.com> wrote:
> Some important points to remember about a scope (even the cheapo Vellman stuff):
> 1) If using a x10 or x100 probe (x10 is much more common) learn to compensate the probe so that you get the best impedance match and good looking edges.  I can't think of any x1 probes I've ever seen that had compensation that worked for a damn if at all.  They just have too much capacitance.  There are times when 50 Ohm or 500 Ohm direct connect cables and probes are nice and other times when you have to build your own too.

As far as I know, compensation wouldn't mean anything for a 1X probe.
What compensation is doing is matching the capacitance across the
attenuation resistor (which doesn't exist in a 1X probe) to the load
capacitance (cable plus scope). This makes the attenuation flat across
frequency.

>
> 2) If you could have just one probe on your bench, use an x10 probe to minimize the loading of your signal.  You can get active probes that have even less capacitive loading and all kinds of special probing jigs and connectors but a nice x10 gets you a long, long way.  My personal preference is for fixed x10 probes, not the switchable kind.  And many Tek and HP scopes have a little ring and pin setup that can automatically tell the oscilloscope what kind of probe is attached.  A very nice feature to look for.
>

This only works if you have a probe which is equipped to report its
type to the scope.

> 3) Don't use the 6" ground clip for anything except quick probing.  It is useless for looking at fast edges.  Do this instead:
> http://www.pericom.com/pdf/applications/AN021.pdf  There are other descriptions of the technique out there but the picture in this app note is pretty clear.  Its all about the ground loop...

This advice about the clip is absolutely right, BUT, the term "ground
loop" refers to something completely different. "Ground loop" means
treating a ground wire or trace as having no voltage drop across it
when in fact it does because it is carrying significant current or has
a high impedance. In this case, what is happening is that the clip
acts like an inductor or an antenna, causing ringing or bandwidth
reduction or pickup of stray signals.

2008\11\03@215543 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan-Erik Soderholm wrote:
[snip]
{Quote hidden}

Whoops, looks like I took the wrong one of the two possible meanings of
Jinx's post: I took it to mean "You should be safe with BSF, and you
should be safe with MOVWF" (not true) when what was actually meant was
"You should be safe with BSF to a shadow **followed by** MOVWF to the
port" (true). But your other points still stand, though: you do NOT want
to "read [the port] into a buffer... modif[y] it, and then [write] it
back"; rather, you want to NOT do the first of those operations - you
only ever want to modify the shadow and copy it to the port. If you ever
read the port into the shadow, you've just spaced out the problem, not
solved it.

Chris


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkPuaYACgkQiD2svb/jCb6UvgCgpeUEBY8bz3PDxEvzNexp9IGx
HD0Ani/S7O0XV8EFx8GGA64bV/kg0IGM
=mJfi
-----END PGP SIGNATURE-----

2008\11\03@220254 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olin Lathrop wrote:
[snip]
> You should understand the read-modify-write issue and ways to deal with it,
> but geesh folks, get some perspective.
>
> I've done somewhere around 100 PIC projects and have used shadow registers
> maybe two or three times.  Yes, you should always be aware of the issue, but
> most of the time it's not a problem.
[snip]

Oh, I quite agree. I don't advocate always using shadow regs; rather, I
advocate knowing what the problem is so you can quickly recognize it
should it occur (and, of course, knowing how to solve it *correctly* in
those cases).

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkPu0IACgkQiD2svb/jCb5TpQCfSr05iswxq/4LjxAj/qXEsasQ
JecAoJtUzQSy9elnug8lBOeeF3ZiFFEk
=5rum
-----END PGP SIGNATURE-----

2008\11\04@013316 by Wouter van Ooijen

face picon face
> Oh, I quite agree. I don't advocate always using shadow regs; rather, I
> advocate knowing what the problem is so you can quickly recognize it
> should it occur (and, of course, knowing how to solve it *correctly* in
> those cases).

I definitely do advocate using shadow registers. In nearly all cases the
added time and code is not a problem. A 100nF capacitor across the power
pins is not always needed either...

The problem with the correct-when-trouble-is-found is that whether
trouble occurs can be very dependent on variable factors: temperature,
tolerances, power supply voltage, chip revision, etc. So there might be
no trouble on your table, but lots of trouble in the field.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\11\04@114257 by Dr Skip

picon face
Microchip seems to agree. From their support:

-------------
Read-modify-write can cause that.  I strongly recommend never bit setting or
clearing a port.  You should always read the port, copy it to ram, modify the
bit, then write that back out to the whole port.  Since the PIC is trying to
change all 8 bits (even if some are the same), this prevents it from reading
the other bits and changing them.  You can learn more about read-modify-write
by searching our knowledge base.

The PIC18 gets around this by having an output "LAT"ch register.  If you bit
set LATB,3 for example, then only that pins output register is set, the others
are not read from the outside world or modified.

Finally, watch out for capacitive loading on pins.  If a pin is strongly
capacitive, it could be read incorrectly due to the capacitance holding the pin
state.  When read incorrectly, it is also written incorrectly.  Again, using
the method mentioned above should assist with this issue as well.
--------------


Wouter van Ooijen wrote:
>
> I definitely do advocate using shadow registers.

2008\11\04@130022 by olin piclist

face picon face
Dr Skip wrote:
> Microchip seems to agree.

No, this is someone that doesn't quite know what they're doing trying to
cover their butt.

> I strongly recommend never bit
> setting or clearing a port.  You should always read the port, copy it
> to ram, modify the bit, then write that back out to the whole port.

But this suffers from the same read-modify-write issue and is actually worse
than BCF/BSF on a port pin because it's not atomic.  Looks like you got the
B team.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\04@131550 by Jan-Erik Soderholm

face picon face
Dr Skip wrote:
> Microchip seems to agree. From their support:

Do they ?

>
> -------------
> Read-modify-write can cause that.  I strongly recommend never bit setting or
> clearing a port.  You should always read the port,...

I thought we agreed on that it is the *reading* of the
port that is the potential source of RMW problems...

Jan-Erik.


 copy it to ram, modify the
{Quote hidden}

correctly.  Again, using
> the method mentioned above should assist with this issue as well.
> --------------
>
>
> Wouter van Ooijen wrote:
>> I definitely do advocate using shadow registers.

2008\11\04@141854 by Dr Skip

picon face
I think my impediment is that in my thinking, I would always manipulate the
byte somewhere besides the port itself, then write it to the port. Maybe I got
burned somewhere in my past and all I now remember is "do it this way and
you'll be fine"... Likewise, if the port has some bits as inputs, I would read
the port into memory and use a mask and go from there. Perhaps an extra cycle
or two over what _could_ be, but my thinking would be to use the port reg as
port driver (or input buffer), not a register to be directly manipulated in
calculations. <I probably should duck and hide about now ;) >

RMW (or any reading of an output) doesn't seem to come into thinking unless
checking to see if the output is really at what I think it should be, which
would also need the data stored somewhere else to check against anyway. If it's
an output, I certainly wouldn't plan on reading it and depending on it. Being
able to check it at the pin seems an architectural luxury.

So the simpler question is, if the output bit is a 1 and you write a 1 to that
bit again, or a 0 and you write a 0, is there any transient on that bit? And
would it matter if done bit wise or as a byte?

-Skip

Jan-Erik Soderholm wrote:
>
> Do they ?
>
>
> I thought we agreed on that it is the *reading* of the
> port that is the potential source of RMW problems...
>
> Jan-Erik.

2008\11\04@181402 by Jan-Erik Soderholm

face picon face
Dr Skip wrote:

[Skipping RMW for the moment... :-) ]


> So the simpler question is, if the output bit is a 1 and you write a 1 to that
> bit again, or a 0 and you write a 0, is there any transient on that bit?

Simple answer, no, there *should* not be.

> And
> would it matter if done bit wise or as a byte?

Simple answer, no. Since the PIC can not write
a single pin! All writes to the port is byte wise,
even when using BCF/BSF. That is what many gets
bite by...

Jan-Erik.

2008\11\05@065940 by olin piclist

face picon face
Dr Skip wrote:
> Maybe I got burned somewhere in my past and all I now
> remember is "do it this way and you'll be fine".

Remembering a rule without the conditions when it applies is a bad idea.  It
is much better to understand the issue.  Then you can derive your own rules
for whatever situation on hand whenever you need them.  Fortunately, the
read-modify-write port issue is easy to understand, so blanket statements
like "always do ..." are bad engineering.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\05@072839 by apptech

face
flavicon
face
>> Maybe I got burned somewhere in my past and all I now
>> remember is "do it this way and you'll be fine".

> Remembering a rule without the conditions when it applies is a bad idea.
> It
> is much better to understand the issue.  ...

However, not remembering a crucial rule AND not remembering the conditions
is more often worse than just rote following :-).
Certainly, rote rule following may lead to disaster, but rote non rule
following ... .
" Don't run on the road ..."
" ... stick things in the power point ..."
" ... drink grapefruit juice when taking medication ..."
"  ... walk under ladders ... "
" ... walk around things widdershins ..."
...

Yeah. Some of those are dumb and or obvious.
The grapefruit one SHOULD read "Don't drink grapefruit juice when taking
medication that grapefruit juice enhances the action of." (which happens to
be quite a few drugs)

Which brings me to the last rule of this post.

"Don't wax philosophical on subjects where you just KNOW that you are going
to regret doing so!".
Now, why would anyone have made that rule.
I can't imagaine.
Lets ignore it and see what happens :-).


   R


I have an adopted Nephew who has limited mental abilities in some areas but
great capabilities in others.
When younger he would sit strapped in a seat in a car and loudly proclaim
while touching the door pillar - "CAR, will kill you ...".
[He can play the piano by ear albeit not well. I can't do it at all. He can
remember and locate as desired the audio contents of every key on an umarked
32 key speaking keyboard after having had the contents of each played once.

 R2



2008\11\05@111305 by Dr Skip

picon face
The conditions are intuitively obvious. I didn't think I had to reiterate them...

- If your bits are subject to being read wrong, and these are important bits,
keep them in a safe place besides where they're being used (applies to PIC
ports and disk backups...)

- If someone can mess with your data (pulling the port out to a different
value), make a point to verify it, not depend on it at that location.

Some rules are so important and obvious that they don't need to be re-thought
all the time - like which end of a knife to hold or that steel, when glowing a
bright yellow or orange, shouldn't be held with your bare hand.... under _all_
conditions. ;)


apptech wrote:
>> Remembering a rule without the conditions when it applies is a bad idea.
>> It
>> is much better to understand the issue.  ...

2008\11\08@192246 by Rodent of Unusual Size

flavicon
face
One question just leads to another..

Okey, I've got the idea about not bitwise fiddling the
outputs directly, but loading them with a bytewise
MOV from a shadow register.

What I'm missing is how to handle changing state of
output bits when the port has mixed functions.  Suppose
the high four bits/pins are configured as input and
the low four are outputs.  Will a bytewise write to the
port have no effect on the inputs?  Or is that part
of the RMW aspect I'm not quite getting yet?
--
#ken        P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"

2008\11\08@194525 by Rodent of Unusual Size

flavicon
face
Robert Young wrote:
>
> By +/- pulses do you mean you see ADDITIONAL pulses in the train with
> positive and negative going directions?  Or do you mean combinations
> of overshoot, undershoot and ringing in the leading and falling edges
> of the pulse?

I'm not sure how to describe it, and I can't find a waveform
online that shows something similar.  I'll try to get a capture.

I haven't looked at it for a few days so trying to describe
it now would certainly be inaccurate.

The point about the short ground probe is an excellent one,
although I think it's going to be a bit of a pain juggling
things.

The outputs I'm trying to watch are less than 2kHz so I'm
not sure how much impact using the ground clip would have.
I get a clean signal from the 4MHz crystal when using the
clip.

I got the Velleman because of its size, portability, and
size (I'm very cramped for space).  Unfortunately, I'm
now suspicious of its quality (quite possibly due to my
loss of memory of 'scope technique ;-), and certainly
irritated by the way it slides around.  Of course, I'd
like a dual-trace display, too. :-)
--
#ken        P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"

2008\11\08@203726 by Jan-Erik Soderholm

face picon face
Rodent of Unusual Size wrote:
> One question just leads to another..
>
> Okey, I've got the idea about not bitwise fiddling the
> outputs directly, but loading them with a bytewise
> MOV from a shadow register.
>
> What I'm missing is how to handle changing state of
> output bits when the port has mixed functions.  Suppose
> the high four bits/pins are configured as input and
> the low four are outputs.  Will a bytewise write to the
> port have no effect on the inputs?

Correct. It will set something in the output latch
but it will neither be seen in the actual I/O pin, or
when reading from the PORT register.


> Or is that part
> of the RMW aspect I'm not quite getting yet?

Not realy.

2008\11\09@080958 by olin piclist

face picon face
Rodent of Unusual Size wrote:
> What I'm missing is how to handle changing state of
> output bits when the port has mixed functions.  Suppose
> the high four bits/pins are configured as input and
> the low four are outputs.  Will a bytewise write to the
> port have no effect on the inputs?

Yes.  The state of the output latches is irrelevant when the pin is a input.
If you ever switch some of these inputs to outputs, then you have to
consider that the latches might have been altered.  As long as they remain
inputs it doesn't matter what gets written to the latches.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...