Searching \ for '[SX]: Pin won't turn off properly' 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/ubicom/devices.htm?key=sx
Search entire site for: 'Pin won't turn off properly'.

Exact match. Not showing close matches.
PICList Thread
'[SX]: Pin won't turn off properly'
2003\01\30@064232 by Jinx

face picon face
part 1 3502 bytes content-type:text/plain; (decoded 7bit)

I've got a 50MHz SX18AC that's giving me the hump. Attached
are pics of the operation of the following SX code. The Scenix
waits for a handshake (r_ack) from a PIC and signals receipt of
r_ack by triggering a 74HC123 (set to 8us) with s_ack. The PIC
sees this 8us pulse and then carries on to other functions

The top frame is the first 1+ ms after the two micros are told to
start talking. The second frame is a magnification of the problem
area, and the third frame is how the sequence should be (and is
with the extra clrb)

The problem is that s_ack will not clear unless it is told to twice.
I've tried more NOPs, delays of ridiculous length (this is meant
to be a high speed transfer routine), but only an extra clrb will
do it. I've noticed this happen on another output pin that has
just a 10k pulldown connected, and it happens on other SX18s.

The circuit has been checked and checked but there's nothing
I can see that should make a_ack go low for just 1 cycle and
then go high again

Any ideas ?

Oh yes, another thing. The SX appears to take about 160ns (8 IC)
to respond to its r_ack pin going high (the yellow trace, frame 2,
sb r_ack = 2 IC) yet I'd have thought this is much too long before
s_ack goes high

;==================================================

        pulse   equ  ra.0     ;show activity
        r_ack   equ  ra.2     ;receive acknowledge
        s_ack   equ  ra.3     ;send acknowledge (via 74HC123)

;==================================================

        org $00

start    mov     ra,#%0000       ;initialise port lines
        mov     rb,#%00000000

        mode    $0c             ;PortB Schmitt Trigger on
        mov     !rb,#%00000000

        mode    $0d             ;PortB as TTL
        mov     !rb,#%11111111

        mode    $0e
        mov     !rb,#%00000000  ;PortB pull-ups on

        mode    $0f             ;Set Mode to Direction configuration

        mov    !ra,#%0100       ;ra.2 as "Data Ready" input

;                     0           74LS123 trigger
;                      1          data ready
;                       0         direction
;                        0        pulse

        mov    !rb,#%11111111   ;i/p to parallel load data

        mov     count,#250      ;init delay
pud      call    delay
        decsz   count
        jmp     pud
        jmp     pbon

;================================================
;        Approx 250us delay
;================================================

del250   mov     cu_hi,#-16

dloop15  mov     cu_lo,#-195

dloop25  incsz   cu_lo
        jmp     dloop25

        incsz   cu_hi
        jmp     dloop15

        ret

;================================================

;start-up synchronisation of PIC and SX
;PIC and SX are both stopped here

pbon     sb      r_ack         ;wait until push button starts PIC
        jmp     $-1           ;and it sends pulse

        setb    s_ack         ;send acknowledge
        nop
        nop
        clrb    s_ack

tend     setb    pulse      ;loop here
        call    del250
        clrb    pulse
        call    del250
        jmp     tend

;SX will not clear s_ack pin unless an extra clrb is used

        setb    s_ack         ;send acknowledge
        nop
        nop
        clrb    s_ack
        nop
        clrb






--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body




part 2 6700 bytes content-type:image/gif; (decode)


part 3 2 bytes
-

2003\01\30@091343 by Chris Loiacono

flavicon
face
Have you tried placing a putting a dummy load in place of the '123? and
watching to see if the pin clears properly? I know it would be unusual, but
the input on the '123 may be to blame.

Do you have this line pulled down? Any other h/w on it?

Have you checked this with other HC123's, from different vendors? I vaguely
recall a similar situation with a part in the same family - Philips, I
believe. The problem went away with a part from a different maker. I believe
at one point Philips discontinued their 74HC123....


> The problem is that s_ack will not clear unless it is told to twice.
> I've tried more NOPs, delays of ridiculous length (this is meant
> to be a high speed transfer routine), but only an extra clrb will
> do it. I've noticed this happen on another output pin that has
> just a 10k pulldown connected, and it happens on other SX18s.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2003\01\30@155449 by Jinx

face picon face
> Have you tried placing a putting a dummy load in place of the '123?

Yes. It doesn't matter what is attached (or not) to the pin, it
does the same thing. I'm wondering if there's some kind of
reflection going on, yet a.0 drives 60ns pulses into a 30cm
wire going to a level-shifting buffer with no problems at all

BTW the last lines of the original post should have been

        setb    s_ack         ;send acknowledge
        nop
        nop
        clrb    s_ack
        nop
        clrb    s_ack

The final s_ack got mislaid in the c&p.

What is interesting (I'll use "interesting" because I'm bored
with expletives) is that with or without the second clrb, the pin
does go low when required, but the second clrb seems to
reinforce the first, and the pulse is the correct length, ie does
not go L-H-L-H-L, but L-H-L. In the original pulse wave, the 1
cycle low before going high again is a real worry because
there's no code possible to make this pattern

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2003\01\30@220550 by Jinx

face picon face
Here's where I'm up to after some testing

To recap -

setb   ra.0
nop
clrb    ra.0

As described yesterday, ra.0 will go high, then low for 1 cycle,
then back to high, even though it's not been told to (by my s/w
anyway)

Adding

nop
clrb  ra.0

will make ra.0 do the pulse as it's meant to

Now I find this is repeatable on any ra pin, and tried that out
on 3 different SX batches (new date, AA, AB or AC). It matters
not a jot what is connected to the pin. And, furthermore, it doesn't
even have to be a clrb instruction to the same pin. Any pin
activity causes a proper clear. For example

setb   ra.0
nop
clrb     ra.0
nop
setb    ra.1

or even

setb    ra.0
nop
clrb     ra.0
nop
clrb     rb.0

PortB doesn't seem to suffer from the mysterious Phoenix-like
behaviour. Small comfort in this app because rb is used as an
8-bit wide input buss

I've d/led the latest SX18 manual - not a mention, so unless anyone
here has a clue I'll have to drop a line to Scenix. Although after their
last attempt to answer to a query I might as well ask the freakin' cat

Now that I'm aware of the nature and extent of the problem there
are some work-arounds I could try, but it'll be a thorough PITA
with the code timing so tight

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2003\01\31@024818 by Stephen

picon face
I still think you are seeing a read-modify-write issue. Have you tried 2
nops between the setb and clrb? It's possible that port a has some
slightly longer propogation delays that may explain it's different
results from other ports.

Also, what type load is being driven? I high capacitive load (long
traces?) could explain this behaviour.

The PORTRD bit was added in the SX48/52 to help combat this behaviour.
It enables the port latch to be read instead of the pin (as on the
SX18/20/28), so getting around the problem of a slow ramp on an output
pin.

{Original Message removed}

2003\01\31@033316 by Jinx

face picon face
> I still think you are seeing a read-modify-write issue. Have
> you tried 2 nops between the setb and clrb?

(Thanks for the reply)

Yes, as noted in the OP. Also tried 1000 - no change. The only
thing that works is in the post you replied to. Sometime over the
weekend I'll make a couple of PCBs with different layouts and
also see if the problem exists at frequencies other than 50MHz.
I have to get to the bottom of this before I can move on to other
code

> It's possible that port a has some slightly longer propogation
> delays that may explain it's different results from other ports

I can't comment as I don't see that parameter in the data.However,
the phenomenon still doesn't make sense to me. It's <spock> highly
illogical </spock>

> Also, what type load is being driven? I high capacitive load (long
> traces?) could explain this behaviour.

2" PCB traces (32mil) to a header connector. Either a 5mA resistive
load, no load or CMOS gate inputs. Any SX o/p pin is rated to drive
45mA, so I don't think that's the problem

> The PORTRD bit was added in the SX48/52 to help combat this
> behaviour

I'm not even sure what behaviour this is

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu>

2003\01\31@075613 by Mr MCU

flavicon
face
Hi Jinx,

I have done similar applications with a SX28 without any problems.  Using it
to R/W on a Z80 buss.  Although not with PortA; however I have used PortA
with other high freq apps.  Always with the SX28 ... size is generally not a
problem in our products ...

Is the SX decoupled, (eg .1mf or tant cap right at the SX's power pins)?
The only other thing I can think of is to hack wire up a SX28.  I don't
believe that lead length, capacitance / inductance of the trace or any of
that other stuff is the problem.  Assuming that the SX18 is decoupled,  I
think the problem may be in the '18.

- Mike



Jinx wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu>


'[SX]: Pin won't turn off properly'
2003\02\02@131809 by John Ely
flavicon
face
I too have had timing problems with the Philips 74HC123 parts.  The
Philips part produced a significantly shorter pulse than Fairchild's
part.  We use the part for a long pulse (30 seconds or so) and by
using much larger capacitors could still only get to about 26 seconds.

I don't know if this will affect your application, but I can verify the
Philips' part is different.

Regards,

John


{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\02@133417 by Brian Aase

picon face
> I too have had timing problems with the Philips 74HC123 parts.  The
> Philips part produced a significantly shorter pulse than Fairchild's
> part.  We use the part for a long pulse (30 seconds or so) and by
> using much larger capacitors could still only get to about 26 seconds.

IIRC, several manufacturers include a cautionary statement in their
data sheets, to the effect that 74xx123 parts are not sutiable for
delays > 1 second.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\02@160904 by Jinx

face picon face
> > I too have had timing problems with the Philips 74HC123

> IIRC, several manufacturers include a cautionary statement
> in their data sheets, to the effect that 74xx123 parts are not
> sutiable for delays > 1 second.

I'm using a Nat Semi 123. Components were calculated for 8us
and by golly that's what I got. The actual pulse length is largely
irrelephant as it needs to be there just long enough for the PIC
to see it

If you want fun with CMOS try different brands of 4046

I did plan to do all sorts of SX tests over the weekend but time
got gobbled up by other things. Came across a tube of the old
SX18 and will try those too. So far it looks like it's internal to the
SX (hope not, that scuppers a fair bit of timing s/w)

What's potentially depressing is that the project is just a proof-
of-concept prototype. After all the h/w s/w problems are sorted
out (and it all has to be working 100%), it might not even be
useable. But that's what learning curves are all about

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\02@163716 by Peter L. Peres

picon face
On Mon, 3 Feb 2003, Jinx wrote:

*>If you want fun with CMOS try different brands of 4046

4047 ?

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\17@050014 by Jinx

face picon face
part 1 877 bytes content-type:text/plain; (decoded 7bit)

After 2 frustrating weeks of trying to get to the bottom of the
problem I'm no closer to solving it. And trust me, I've tried a
lot of ideas. No answer from Scenix, and I may have to bug
them until they do. Hate that

Attached pic is typical of the SX behaviour - the port pins simply
will not reliably turn off when told to or, in this case, one actually
turns off prematurely. As noted before (see OP for setup) it is not
related to speed or pin terminations. General code that doesn't
involve pins is no problem at all, but unless anyone has a last flash
of inspiration, it's got the point where I may have to drop the SX in
this application (and cast a jaded eye on using them in the future)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




part 2 2728 bytes content-type:image/gif; (decode)


part 3 2 bytes
-

2003\02\17@104154 by G.Smith

flavicon
face
On 17 Feb 2003, at 23:00, Jinx wrote:

> Attached pic is typical of the SX behaviour - the port pins simply
> will not reliably turn off when told to or, in this case, one actually
> turns off prematurely. As noted before (see OP for setup) it is not
> related to speed or pin terminations.

Hi,
I did not spot any references to speed in the posts in the archive - have you
tried it with a 4MHz xtal?

The pcb recomendations include ground plane under the chip (guessing you
won't have that yet) but this would not matter at 4MHz.


George Smith

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\17@125122 by Stephen

picon face
What are your port settings, ie. Schmitt Trigger, pullups, TTL/CMOS,
etc.?

Rather than using setb and clrb, have you tried doing the setb and clrb
to a temporary register, then simply writing the value to the port?

With what information has been provided, I see no logical reason for the
behaviour you are seeing. I have used the SX for 5 years, and this type
of behaviour has not happened.

Stephen

{Original Message removed}

2003\02\17@183430 by Jinx

face picon face
> I see no logical reason for the behaviour you are seeing

That makes two of us. This is about as succinctly as I can put it

http://home.clear.net.nz/pages/joecolquitt/SX_pins.html

Amongst other things I've checked Vcc and Mclr for glitches

Note that the first analyser picture shows correct operation. Throw
another pin excursion into the mix though..........

There seems to be no apparent consistency. I never know what
to expect, which tends to cramp one's style. Some days the damn
thing makes me feel like a complete muppet

Handshaking between the two micros works fine. As the SX is
running 54x faster than the PIC I'm using INTF to store the Ack
coming from the SX. The code snippet to do this is in the diagram
showing the inter-connection

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\17@212513 by Stephen

picon face
I just tried your code on a SX28 and I do see the problem.

I found 2 ways to fix it, which give just one solid pulse:
1. add one more nop after each setb or clrb to the port
2. use setb and clrb on a temporary porta output value (I called it
portabuf), and then write that value to the port after each setb or clrb
to the temporary value. Usinf this method may give slightly longer pulse
widths, so another possibility is to simply have predefined state values
(ie. alloff = 0x00, sack1 = 0x08, way1 = 0x02, sack1_way1 = 0x0A)which
can then be written to the port, saving the setb/clrb instruction cycle.

I hope this helps...
Stephen



{Original Message removed}

2003\02\17@231913 by Roman Black

flavicon
face
Jinx wrote:
>
> > I see no logical reason for the behaviour you are seeing
>
> That makes two of us. This is about as succinctly as I can put it
>
> http://home.clear.net.nz/pages/joecolquitt/SX_pins.html

> There seems to be no apparent consistency. I never know what
> to expect, which tends to cramp one's style. Some days the damn
> thing makes me feel like a complete muppet


And other times you feel like only half a muppet? ;o)

I've only had the quickest look at your link above, but
it does seem like a RMW fault;
* randomness indicates hardware (electrical) fault
* you are using clrb and setb (not movwf)

Try tackling it from an electrical side, change of
decoupling cap to a faster (lower ESR) type or
different size, or better located etc. Have you checked
distance (ie pF) of the driven lines?
Maybe a small series resistor on each line would allow
the SX output to rise faster and be less dependant on
line capacitance loading?

Dare I suggest it, have you considered writing to the
whole port using a shadow register as recommended by
all good muppets? :o)
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\18@135534 by David Cary

picon face
{Quote hidden}

Dear Jinx,

How bizarre. Thanks for reducing this down to a simple test case.

So you're running at 20 ns / instruction, right ?
I think that rules out interrupt problems ...

Have you looked at the actual wave form with a (analog) o'scope, rather
than a logic analyzer ?

I suspect you are hitting the read-modify-write gotcha
        http://massmind.org/techref/readmodwrite.htm
. Adding a single NOP isn't reliable -- the more capacitance connected to
the pin, the more NOPs would be needed.
(PICs have this gotcha -- do SX chips also have this problem ?)

Because of that gotcha, I *only* use the movwf instruction to write to
output pins. Typically I allocate a mirror RAM byte corresponding to each
port, something like this:

        setb mirror_port, s_ack
        movfw mirror_port
        movwf real_port
        setb mirror_port, way
        movfw mirror_port
        movwf real_port
        nop
        nop
        clrb mirror_port, s_ack
        clrb mirror_port, way
        movfw mirror_port
        movwf real_port

I'm much happier with code that works vs. clever code that only takes 1/3
the number of instructions that doesn't work.

If this "read-modify-write gotcha" is the true explanation, I would expect
this to cause s_ack to prematurely turned off at the *same* time as the
software turned on the other pin ... odd.

Please tell us if you ever discover the real problem -- perhaps it will
help the next person to slam into this gotcha.

--
David Cary

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\18@153602 by Stephen Holland

picon face
I ran Jinx's code on an oscilloscope, and I could only see correct results
when using code exactly as David has provided.

The read-modify-write issue is a common one, especially with the setb clrb
instructions. It makes perfect sense once you understand that bit-wise
instructoins such as setb and clrb are actually nothing more than the
sequence of read-or-write or read-and-write. If these instructions are not
followed by nops, then if you look at the pipeline to see when reads and
writes actually occur, you will see the problem clearly. Simply, the port
does not yet have what you expecting when the next instruction's read
occurs. Using back to back setb or clrb instructions on different port pins
is fine, but not on hte same port.

Cheers,
Stephen






{Quote hidden}

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\18@200608 by James Newton, webhost

face picon face
source= http://www.piclist.com/postbot.asp?id=piclist\2003\01\30\155449a

Jinx, I'm sorry I didn't answer you sooner, I've just seen this thread... I
think you understand all the issues correctly, but I'll bet that you (as I)
are not seeing the EXTENT of the issues.

With speed comes friction. An SX at 50MIPS is a little bundle of
read-modify-write problems just itching to happen. Anything that runs at 50
or 75 MIPS is going to do this sort of strange things when you use bit
operations directly on a port.

The data sheet says:
3.1.1  Read-Modify-Write Considerations
Caution must be exercised when performing two succes-
sive read-modify-write instructions (SETB or CLRB oper-
ations) on I/O port pin.
....
Also note that reading an I/O port is actually reading the
pins, not the output data latches. That is, if the pin output
driver is enabled and driven high while the pin is held low
externally, the port pin will read low.

Which really understates the issues in my opinion.

Take a look at those signals with a good scope rather than that logic
analyzer and watch all the nice ones and zeros devolve into a mess of
ringing, standing waves, etc... I couldn't believe it when I finally saw the
signals in my first prototype on a really good scope (100MHz if I remember
correctly and even that is not really sufficient for 50Mhz signals)

I have personally seen an SX work just like a TDR; allowing us to see the
difference between a PCB with a broken trace (still conductive, but
apparently hairline cracked) and one that was not just from the standing
wave returning from the crack at just the point when the SX needed to
transition the pin. we got 11111000000011111 on the good board and
11111000000010111 on the bad one. Looking at the trace on a (really, really
good) scope, you could see the negative spike killing the pin drive at a
consistent period from the first 1 to 0 transition. We could modify the
length of the low state of the pulse and see the 0 still appear at a fixed
time. e.g. 11111000001110111 or 11111000111110111

If you happen to "read-modify-write" one pin at the exact time that your
other output pin gets hit with some crap, it will retain the crap and loose
its previous setting.

In short: clrb and setb are not for ports. Exception: With a low value
resistor in series and a tiny cap on the other side of the resistor to
ground, you can often get away with it.

When you need REALLY fast updates (like pulses) out a port, just setup the
chip so that W appears as register 1 (you can do that on an SX) then read
the shadow into W. setb 1.x; mov RA, W; clrb 1.x; move RA, W. that will get
you 25Mhz pulses from the 50Mhz SX without concern for RMW problems.

One other gottcha: When you do use shadow registers, look out for interrupt
routines that try to update the shadow while you are working on it.

---
James Newton: PICList.com webmaster, former Admin #3
jamesnewtonEraseMEspam.....piclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\19@030712 by Jinx

face picon face
> > thing makes me feel like a complete muppet
>
> And other times you feel like only half a muppet? ;o)

Yeah, sometimes I can't eat a whole one

> I've only had the quickest look at your link above, but
> it does seem like a RMW fault

To all who replied (thanks for your time) -

Having foregone the pleasures of r-m-w problems on the PICs
this is a bit of a culture shock. I guess you could say the problem
could be phrased "My Scenix isn't quite a high-speed PIC is it ?".
I've had my suspicions that it's r-m-w and had a little time today
for some objectivity

http://home.clear.net.nz/pages/joecolquitt/sx_pins2.html

(the analyser is sampling at 200MHz so there's the odd 5ns)

To me this clearly identifies what code works for driving the SX pins
and what to avoid. This does make things a little tricky for the current
application which is based on instruction cycles but I think I can work
around it

> Try tackling it from an electrical side, change of decoupling cap
> to a faster (lower ESR) type or

I've yet to finds anything that has more effect than changing the code
although everything around andon the SX was checked

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\19@053235 by Roman Black

flavicon
face
Jinx wrote:

> I've yet to finds anything that has more effect than changing the code
> although everything around andon the SX was checked


I think you'll find that putting series resistors
CLOSE to your output pins will effectively remove
the capacitive loading of the line you're driving.
If the resistors are too large you will get soggy
transitions at the receiving end obviously, but your
scope will show that.
-Roman

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\19@074813 by Jinx

face picon face
> > I've yet to finds anything that has more effect than changing
> > the code although everything around and on the SX was checked
>
>
> I think you'll find that putting series resistors CLOSE to your output
> pins will effectively remove the capacitive loading of the line you're
> driving

Have a look at the last picture here

http://home.clear.net.nz/pages/joecolquitt/sx_pins2.html

PIC b0, driven by SX ra3,  has a max capacitance of 50pF. ra1
isn't connected to anything except either the 20pF of the scope
probe or 8pF for the analyser probe

Just to see what would happen I added 470R between ra3 and b0
and gave ra1 a 10mA load to play with. I think I'll just accept the
limitations for now

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\21@051646 by Jinx

face picon face
part 1 695 bytes content-type:text/plain; (decoded 7bit)

It looks like read-modify-write was the problem I'm embarrassed
to say (blush). Attached shows a portion of the code working
properly, picking up parallel motor control data transparently whilst
also processing previous data and putting out pulses. I'll just have
to remember that the SX needs more IC between port instructions
than the PIC

Thanks to all who pitched in

=================================

BTW, English is a funny language

read - write
right - wrong

????

read - right
write - wrong



--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads




part 2 4393 bytes content-type:image/gif; (decode)


part 3 2 bytes
-

2003\02\22@012333 by David Cary

picon face
Dear embedded system programmers,

>Date:         Fri, 21 Feb 2003 23:16:29 +1300
>From: Jinx <RemoveMEjoecolquittTakeThisOuTspamspamCLEAR.NET.NZ>
>Subject: Re: [SX]: Pin won't turn off properly
>
>It looks like read-modify-write was the problem
...

I'm glad it's working for Jinx now. Let's try to summarize what all of us
have learned, OK ?

>I'll just have
>to remember that the SX needs more IC between port instructions
>than the PIC

Jinx and Stephen Holland and many, many other people seem to think the
solution to read-modify-write problems is to add more and more NOPs or
other delay between "setb port" instructions.

While they may be lucky enough to get away with only 2 NOPs on some
projects, there are other situations where even 100 NOPs between "setb
port" instructions is not enough.

I think James Newton has (attempted to) explain the problem, and the
solution, at
        http://massmind.org/techref/readmodwrite.htm
.
Why, then, do so many people use setb and clrb on output ports ? When the
next batch of newbies starts using these chips, is there any way to get
this information to them, and make it easier to understand ? Preferably
*before* they all spend a week pulling their hair out ?

(In summary: use *only* the movwf instruction (or its equivalent on other
processors) to write to output pins. Don't use any other instruction to
modify the output pins -- not "setb", not "clrb", not "and", not "xor" ....
only "movwf" to write to output ports.)

>Thanks to all who pitched in

You're welcome. Of course, now you're obligated to help the next newbie.
Pass it forward.

>BTW, English is a funny language

Yes. :-)

--
David Cary

>Date:         Tue, 18 Feb 2003 17:02:30 -0800
>From: "James Newton, webhost" <EraseMEjamesnewtonspamspamspamBeGonePICLIST.COM>
>Subject: Re: [SX]: Pin won't turn off properly
...
>The data sheet says:
>3.1.1  Read-Modify-Write Considerations
>Caution must be exercised when performing
...
>read-modify-write instructions (SETB or CLRB oper-
>ations) on I/O port pin.
>....
>Also note that reading an I/O port is actually reading the
>pins, not the output data latches. That is, if the pin output
>driver is enabled and driven high while the pin is held low
>externally, the port pin will read low.
...
>If you happen to "read-modify-write" one pin at the exact time that your
>other output pin gets hit with some crap, it will retain the crap and loose
>its previous setting.
>
>In short: clrb and setb are not for ports.
... [although]
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@025914 by Stephen

picon face
David,

No, I do not think that the final solution is to simply add more nops...
I only gave that as a simple way to test. I also suggested writing
directly to the port in the same email, just as I have always done. You
provided example code that got the point across a little clearer. Good
job.

Read-modify-write is a common problem in any pipelined architecture and
is covered in any good college computer electronics course. Many people
however do not fully understand what it is or how it occurs, and as a
result don't know how to recognize the symptoms. The datasheet even
specifically mentions the issue, but is probably a little too soft on
the topic (to avoid scaring people?). As a result, people start blaming
the chip, when it is simply doing what it was designed to do.

I guess once someone sees a setb or clrb instruction in the datasheet,
they are just appear too tempting to pass up!! It is not immediately
obvious what actually happens in the pipeline when a setb or clrb
instruction is executed.

Cheers,
Stephen

{Original Message removed}

2003\02\22@040857 by Jinx

face picon face
> >It looks like read-modify-write was the problem
> ...
> I'm glad it's working for Jinx now.

Not half as happy as Jinx is. The rest of the code almost worked
first time, just needs a little twiddling

> > I'll just have to remember that the SX needs more IC between
> > port instructions than the PIC
>
> Jinx and Stephen Holland and many, many other people seem
> to think the solution to read-modify-write problems is to add  more
> and more NOPs or other delay between "setb port" instructions

I think it's fair to say that adding NOPs is "a" solution. If you look at
the first 3 pictures here

http://home.clear.net.nz/pages/joecolquitt/sx_pins2.html

you'll see the waveform come into line as more NOPs are added.
> Why, then, do so many people use setb and clrb on output ports ?

I did get stung and it's obviously embarrassing because I've offered
PIC advice about how not to get stung !!! I do understand the reasons
for r-m-w problems, but in my defense I'm an SX newbie and r-m-w
wasn't immediately apparent when there were so many other SX
things I could have been ignorant of

That said, the code is working with setb and clrb instructions. If each
pin is allowed time to rise or fall to the intended level and is not subject
to interference by other port instructions then I see nothing wrong with
using them

> >In short: clrb and setb are not for ports.
> >... [although]
> >you can often get away with it.

> (In summary: use *only* the movwf instruction (or its equivalent
> on other processors) to write to output pins

The 4th code example at the page above produces exactly the same
waveform as the 3rd - so is it safer ?

Except for a couple of instances out of countless interface programs
I've never used anything but bsf / bcf on PICs  or bset / bclr on Motorolas
and this is the first time I've come afoul of r-m-w, purely because the
speed of the SX caught me unawares. It won't catch me again ;-)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@054410 by Russell McMahon

face
flavicon
face
Summary:

   MINI TUTORIAL
   Why you should NEVER use read-modify-write on an SX or rely on port
states.

> I think it's fair to say that adding NOPs is "a" solution. If you look at
> the first 3 pictures here
>
> http://home.clear.net.nz/pages/joecolquitt/sx_pins2.html

No (alas) - it's only fair to say that adding NOPs is a "solution" 'in this
case'.
ie not in every case.

> That said, the code is working with setb and clrb instructions. If each
> pin is allowed time to rise or fall to the intended level and is not
subject
> to interference by other port instructions then I see nothing wrong with
> using them

I know you know the following, but others with less experience may well not,
so I'll spell it out.

There are two distinct forms of this problem and the above only deals with
one of them.
The WHOLE problem is that the port read instruction reads what the actual
real world levels are and NOT what you may expect them to be as a result of
program action. When the actual and expected values are the same then there
is no problem.

The actual and expected values can differ for two reasons.

i)    As above - there is a delay in actual pin level response due to
dynamic loading (eg load capacitance etc). If you read the pin before the
capacitance has had time to charge/discharge then you may get the wrong
value.
The solution above cures this.

ii)    There is a static load which holds the output pin permanently at one
or other level regardless of what value you write to the port. NOTE
CAREFULLY - the port may work entirely correctly as an output in such cases.
But no number of nops or intervening instructions will make it work in a
read-modify-write mode because the port will ALWAYS read as having one
value.

A real world example should make this clearer.

Imagine an npn  transistor used to drive a lamp load with the transistor
driven by the port pin.
Transistor emitter to ground.
Transistor collector to lamp.
Other side of lamp to Vcc supply or where-ever.
Now imagine that the transistor base is driven directly by a port pin with
no drive resistor. This is very bad practice but will work.
When port pin is low the base is low and transistor is off.
Read the port pin and you will see a logic low, as you would expect.

Now drive the port pin high with eg a setb instruction.
The transistor Vbe junction will clamp at about 0.7v. The SX will try to
drive it higher but will not succeed. The SX will current limit at 20+ mA
into the base. This is a naughty thing to do but will probably not hurt the
SX or most transistors.
The SX will "think" that there "should" be a logic 1 on the pin as it has
sent a high level. The transistor will agree - it WILL see a high level and
it WILL be turned on.
BUT if you read the SX pin the 0.7v level due to the transistor base-emitter
diode clamp will (probably) mean that the pin appears as a logic low.

The answer: As noted elsewhere there is an easy solution which should be
used as the standard solution UNLESS you really really need the extra speed
and slightly fewer instructions and really really understand what you are
doing.
Use a "shadow port " instead of the port. The shadow port is simply a RAM
location that you write to INSTEAD of writing to the real port. Whenever you
need to write to the port, instead write to the shadow port and then copy
the shadow port to the real port. Input pins can be read directly from the
real port.

The shadow port adds slight extra delay and code overhead but ALWAYS works
as intended. Use it wherever possible and you won't be sorry.

SOME microprocessors (eg AVR) have ports with TWO data registers per port.
One is used to write the output data to and can also be used to read the
data that you have written. The other is used to read the actual port pin
level. This is a generally superior arrangement but is slightly more
expensive to implement. It has no real disadvantages for programming.



       Russell McMahon

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@064722 by David Duffy

flavicon
face
Russell wrote:
>Summary:
>
>     MINI TUTORIAL
>     Why you should NEVER use read-modify-write on an SX or rely on port
>states.
>
> > I think it's fair to say that adding NOPs is "a" solution. If you look at
> > the first 3 pictures here
> >
> > http://home.clear.net.nz/pages/joecolquitt/sx_pins2.html
>
>No (alas) - it's only fair to say that adding NOPs is a "solution" 'in this
>case'.
>ie not in every case.

I don't think Jinx was saying that it was a solution for ALL cases.

{Quote hidden}

Huh? You just said "This is very bad practice but will work".
In this case, the designer gets a bad result because of a bad design.
That's not the fault of the micro at all - it's the designers fault.

{Quote hidden}

The shadow port is unnecessary in this case IF the designed did their job.
Fixing "faulty" code this way (in this case) is just avoiding the cause.
David...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@075405 by Wouter van Ooijen

face picon face
> I think it's fair to say that adding NOPs is "a" solution.

There are two problems:
1 pipelining
2 physical pin level

Adding nops solves 1 and might solve 2, depending on the external load
and the number of nops. Or put it in a more harsh way: assing nops is
*not* a solution. Just use a shadow register, that solves both problems.
BTW the Jal IO routines use a shadow register, invisible to the casual
user. One more argument for using a HLL...

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@100323 by Russell McMahon

face
flavicon
face
> >Now imagine that the transistor base is driven directly by a port pin
with
> >no drive resistor. This is very bad practice but will work.
> >When port pin is low the base is low and transistor is off.
> >Read the port pin and you will see a logic low, as you would expect.

> Huh? You just said "This is very bad practice but will work".
> In this case, the designer gets a bad result because of a bad design.
> That's not the fault of the micro at all - it's the designers fault.

Sorry - I was trying to use a simple example that was clear enough to be
sure to explain how the affect happens.
What I meant was bad HARDWARE practice. It may in fact be legitimate from a
spec sheet point of view.

More generally - in real world situations you can not always guarantee that
the pin will be loaded as you hope or intend or even design it to be. If you
are willing to acept that your program may misbehave or lock up if
unexpected external situations occur then you don't need to use a shadow
register. If you want your program to always function as intended
independent of external conditions then a shadow register is a simple and
easy and low resource cost solution. You still have to decide what action
the program should take if the unexpected hardware conditions alter what the
hardware does BUT the program itself always works as intended.

Example. My PIC drives a MOSFET gate directly. The pin connects directly to
the gate. This is entirely within spec sheet requirements and is good
hardware practice with an appropriate FET. Imagine that the program sets the
gate high, does something else then makes a decision depending on whether
the gate is high or low. If the MOSFET suffers a ftal failure the gate may
become connected to source and be a hard ground. This is a not uncommon
failure mode (believe me :-) !). In this case, if the program makes the
high/low gate decision by reading the port pin then it wil decide that the
port is low. The port is indeed low - BUT the drive signal is high. My
program may loop forever and "hang" the program. While neither decision will
make the dead FET work, having the program make the desired decision rather
than making one based on an erroneous hardware situation, is liable to be
superior. Obviously you have to have thought this through to get a fully
useful program. (What do I do if th FET is dead .... ? )

Designing a program this well may well be too much effort for many people.
But the shadow register is liable to "save your skin" in many less dramatic
situations.

Note that it MAY be acceptable (depending on data sheet specs for the given
device) to use a port pin to drive a load which loads it so heavily that the
pin can not be driven to a guaranteed high level. Such a result is a design
decision which can be made if you have enough information available. In such
cases, use of a shadow port GUARANTEES that you will know what your port is
being driven to do externally. Reading the port itself will not tell you
with certainty.

> The shadow port is unnecessary in this case IF the designed did their job.
> Fixing "faulty" code this way (in this case) is just avoiding the cause.

No. As above. While writing "good" code is not a substitute for proper
hardware design, the aim is to make your software as immune as is easily
possible, to real world events. The shadow register does this with minimal
cost and effort. I have used shadow ports on processors which require them
for many years and have never regretted doing so. On processors which are
specifically designed to overcome the "pin loading" shortcoming (eg AVRs)
the shadow port is not needed as long as the instructions used utilise the
provided ports appropriately.



       Russell McMahon.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@102858 by Roman Black

flavicon
face
Russell McMahon wrote:

>     MINI TUTORIAL
>     Why you should NEVER use read-modify-write on an SX or rely on port
> states.

> There are two distinct forms of this problem and the above only deals with
> one of them.
> i)    As above - there is a delay in actual pin level response due to
> dynamic loading
> ii)    There is a static load which holds the output pin permanently at one
> or other level regardless of what value you write to the port.


iii) (roman numerals RM?? gee that's an ugly way to
numerise) if a power glitch/spike etc occurs at the
same time you are doing RMW then the pin will be set
to an unknown state.

I can't see why you would EVER risk a RMW unless there
was no possible way to get the timing that tight by
writing direct to the whole port. Shadow register. :o)
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@103301 by Roman Black

flavicon
face
David Duffy wrote:

> >No (alas) - it's only fair to say that adding NOPs is a "solution" 'in this
> >case'.
> >ie not in every case.
>
> I don't think Jinx was saying that it was a solution for ALL cases.


Well, Jinx is a PIC genius, that's not in doubt.
:o)
BUT I do have to question the logic behind adding
nops to a RMW, if you can afford one or more
instructions timewise why not just movf,w then
movwf PORT and write to the entire port??
Or is there some esoteric benefit to clinging to
a bsf PORT,x when you have cycles to spare??
-Roman

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@123021 by Stephen

picon face
Assuming having a setb/clrb on a temp value which gets written to the
port takes too long, you could save a cycle by just writing predefined
states to the port.

On the SX at least, wrting values directly to the port is common way to
share multiple VPs on the same port as well, while still possibly
maintaining jitter free operation.

Cheers,
Stephen

{Original Message removed}

2003\02\22@160144 by David Duffy

flavicon
face
>Russell:
> > >No (alas) - it's only fair to say that adding NOPs is a "solution" 'in
> this
> > >case'.
> > >ie not in every case.

>David Duffy wrote:
> > I don't think Jinx was saying that it was a solution for ALL cases.

Roman:
>Well, Jinx is a PIC genius, that's not in doubt.
>:o)
>BUT I do have to question the logic behind adding
>nops to a RMW, if you can afford one or more
>instructions timewise why not just movf,w then
>movwf PORT and write to the entire port??
>Or is there some esoteric benefit to clinging to
>a bsf PORT,x when you have cycles to spare??

What I was getting at is that there's nothing wrong with using BCF
and BSF instructions on a port as long as you're aware of R-M-W.
I don't agree that Russell's example case of a transistor is a valid
one - he & I will have to "agree to disagree" on that one. :-)
With a correctly designed circuit, the BCF/BSF instructions are a
valid way to code. I'd rather code it as "BSF PORTA,LED" than use
a shadow register and do:
BSF             SHADOW,LED
MOVF            SHADOW,F
MOVWF   PORTA
The BSF saves two instructions in this case. That may be important
in busy code running at less than blistering speeds. I've written heaps
of code that uses BCF/BSF and has/will always work just fine but I
also have written code that uses shadow registers when required.
David...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@160352 by Russell McMahon

face
flavicon
face
> I can't see why you would EVER risk a RMW unless there
> was no possible way to get the timing that tight by
> writing direct to the whole port. Shadow register. :o)
> -Roman

That about summarises what I was trying to say. With the qualification that
some processors explicitly allow you to do this by "proper" hardware design.


       iv    RMW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\22@163902 by Jinx

face picon face
> BUT I do have to question the logic behind adding
> nops to a RMW, if you can afford one or more
> instructions timewise why not just movf,w then
> movwf PORT and write to the entire port??
> Or is there some esoteric benefit to clinging to
> a bsf PORT,x when you have cycles to spare??
> -Roman

In this particular case using a shadow register would slow
things down too much. Partly this goes back to the maths
in the PIC which generates the data that the SX uses. The
16/32-bit division/multiplication creates timing segments
in 4-cycle or multiples of 4-cycle blocks, sent to the SX as
9 bytes of data

The r-m-w code anomaly that caught my attention has been
re-written so that only one pin at a time is accessed, using
setb nop nop clrb, which fortunately is working (subject to
tests) for the timing-critical part of the code. The original
problem was during the handshake phase. I've added one
more handshake from the SX to the PIC and allowed 4us
for the PIC to turn off its lines. This in effect puts a full stop
on the comms and so the SX can move on the timing and
pulsing portion of its code, unencumbered by pinging the
handshake line

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\23@033515 by Eric Bohlman

picon face
2/22/03 2:59:57 PM, David Duffy <RemoveMEdavidKILLspamspamAUDIOVISUALDEVICES.COM.AU> wrote:

>With a correctly designed circuit, the BCF/BSF instructions are a
>valid way to code. I'd rather code it as "BSF PORTA,LED" than use
>a shadow register and do:
>BSF             SHADOW,LED
>MOVF            SHADOW,F
>MOVWF   PORTA

You know, your choice of symbolic name for the bit in question really detracts from your argument.
If I wanted to make the point Russell was making, I wouldn't have picked the direct-base-drive
transistor example.  I'd have picked directly driving an LED.  And that's exactly the sort of static
load that will give you static RMW problems.  Try that with two or more LEDs on a port, and you may
well find that trying to turn one of them off or on affects the other.

>The BSF saves two instructions in this case. That may be important
>in busy code running at less than blistering speeds. I've written heaps
>of code that uses BCF/BSF and has/will always work just fine but I
>also have written code that uses shadow registers when required.

This looks to me like a classic case of laziness masquerading as premature micro-optimization.
Another one, which has come up here far too often, is trying to do a table lookup without checking
to see if a 256-byte boundary has been crossed.  I have a hard time imagining how writing the extra
*two* instructions needed to do this properly can be harder than trying to keep your tables
boundary-aligned.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@041915 by David Duffy

flavicon
face
>2/22/03 2:59:57 PM, David Duffy <davidSTOPspamspamspam_OUTAUDIOVISUALDEVICES.COM.AU> wrote:
>
> >With a correctly designed circuit, the BCF/BSF instructions are a
> >valid way to code. I'd rather code it as "BSF PORTA,LED" than use
> >a shadow register and do:
> >BSF             SHADOW,LED
> >MOVF            SHADOW,F
> >MOVWF   PORTA

Eric B:
>You know, your choice of symbolic name for the bit in question really
>detracts from your argument.
>If I wanted to make the point Russell was making, I wouldn't have picked
>the direct-base-drive
>transistor example.  I'd have picked directly driving an LED.  And that's
>exactly the sort of static
>load that will give you static RMW problems.  Try that with two or more
>LEDs on a port, and you may
>well find that trying to turn one of them off or on affects the other.

Huh? What's the problem with more than one LED on the same port and BCF/BSF?
I am NOT saying doing consecutive BCF/BSF operations on a port is ok - I
never have.
What I'm saying is that BCF/BSF operations are perfectly valid although you
do have to
be careful not to end up with them too close together and causing problems.
That's no reason to "throw the baby out with the bath water" is it? Are you
suggesting
that the LED's are connected to the port pins with no current limiting
resistors?
I don't design that way - maybe others do. In my book, that's just bad
design practice.
Do designers really take such nasty shortcuts in their hardware? I surely
hope not.
Maybe that's the case with people who write code with no real hardware
experience.

{Quote hidden}

Double Huh? The table lookup case shares nothing in common with the LED
example.
If you're in an interrupt routine and want to turn the LED on/off, you'd
really don't want to be
wasting clock cycles on a shadow register when the BCF/BSF would be quite ok.
I agree with the table boundary checking. Maybe if time is scarce AND you
are doing a lot
of table lookups AND you can put the table somewhere safe, then you can
skip them.
The table has got more chance of being shifted to where it's crossing a
boundary when
the code is modified than my simple LED example going loopy sometime in the
future.
David...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@042330 by Russell McMahon

face
flavicon
face
> >With a correctly designed circuit, the BCF/BSF instructions are a
> >valid way to code. I'd rather code it as "BSF PORTA,LED" than use
> >a shadow register and do:
> >BSF             SHADOW,LED
> >MOVF            SHADOW,F
> >MOVWF   PORTA
>
> You know, your choice of symbolic name for the bit in question really
detracts from your argument.
> If I wanted to make the point Russell was making, I wouldn't have picked
the direct-base-drive
> transistor example.  I'd have picked directly driving an LED.  And that's
exactly the sort of static
> load that will give you static RMW problems.  Try that with two or more
LEDs on a port, and you may
> well find that trying to turn one of them off or on affects the other.

The transistor base example was intended to be an extreme case in order to
demonstrate the problem very clearly. ie the base-emitter junction clamps at
about 0.6v so obviously it isn't going to be able to get up to near "usual"
logic levels. Both transistor base drive and LED drive can of course be
designed so that they will work properly. When things work as expected.

The overwhelmingly important point that I was hoping to make is that,

       the use of a shadow register means that your software is not at
       the mercy of your hardware.

Conversely, if you rely on RMW instructions and they don't work because of a
hardware problem, regardless of WHY the problem occurred,  then your
program's operation is wrested from your control and placed at the mercy of
whatever it is that is happening that you don't expect. This might be (as I
described in my FET drive example) a failed component, or an out of spec
component or a hardware change made without enough thought of the effect on
software or (importantly) by someone who doesn't know what the software is
doing.

Murphy and reality say that YMWV.

Use of a shadow register gives you added certainty and costs little.
Sometimes performance issues make it an unviable solution.
In all other cases its use is prudent.
However, as they used to say when I rode motorcyles long ago, "If you have a
$10 head then by all means buy a $10 helmet." if you're head, or the correct
operation of your program is valuable to you, its prudent to take
appropriate precautions.



           Russell McMahon








>
> >The BSF saves two instructions in this case. That may be important
> >in busy code running at less than blistering speeds. I've written heaps
> >of code that uses BCF/BSF and has/will always work just fine but I
> >also have written code that uses shadow registers when required.
>
> This looks to me like a classic case of laziness masquerading as premature
micro-optimization.
> Another one, which has come up here far too often, is trying to do a table
lookup without checking
> to see if a 256-byte boundary has been crossed.  I have a hard time
imagining how writing the extra
> *two* instructions needed to do this properly can be harder than trying to
keep your tables
> boundary-aligned.
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@053259 by David Duffy

flavicon
face
<snip>
Russell:
>Conversely, if you rely on RMW instructions and they don't work because of a
>hardware problem, regardless of WHY the problem occurred,  then your
>program's operation is wrested from your control and placed at the mercy of
>whatever it is that is happening that you don't expect. This might be (as I
>described in my FET drive example) a failed component, or an out of spec
>component or a hardware change made without enough thought of the effect on
>software or (importantly) by someone who doesn't know what the software is
>doing.

But if the transistor has failed, it won't really matter what the port pin
thinks
the level currently is as the lamp/motor/whatever will still be stuck on/off as
anyway. I've tried to think of a situation where feedback from the shorted pin
could cause the code to behave badly but I really can't. Maybe if you rely on
the port pin output state to make decisions on then you could get bitten. I
usually have flags to indicate the system state so I avoid it that way.

>Murphy and reality say that YMWV.

Yes, reality has a nasty habit of getting in the way of all things proper! :-)

>Use of a shadow register gives you added certainty and costs little.
>Sometimes performance issues make it an unviable solution.
>In all other cases its use is prudent.

As long as you're aware of RMW issues, I don't see them as a big problem.
David...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\23@075039 by Morgan Olsson

flavicon
face
Hej David Duffy. Tack för ditt meddelande 10:18 2003-02-23 enligt nedan:
>Are you
>suggesting
>that the LED's are connected to the port pins with no current limiting
>resistors?
>I don't design that way - maybe others do.

Example: driving large MOSFET
In most cases it is desireable to switch on/off fast.
Normally used gate drive resistor is about 30 ohms.
I have not done this with PIC but, I would think it is electrically feasable to connect the gate directly to PIC pin, and the pic internal resistans is adequate.  For the short time the current flows it is no problem with overload.
(yes it might cause transients on pic supply)
The gate har capacitance both to source and drain, which will load the pic output, both at turnon and turnoff, at a voltage that is the fet´s transfer region.  
so, the voltage change is delayed

Also, when the fet is turned off, transients on drain capacitively couples to gate, it the pic then do a RMW on that port it accidentally torns the tranny on, which may be a really bad thing, and might only happen seldom enough it is not noted until it the products are sold...

(for thoose naturally worrying if a high transient might damage the pic: the fet will turn on as normal and conduct to limit the peak at gate to normal turn on voltage.)

/Morgan

--
Morgan Olsson, Kivik, Sweden

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

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