Searching \ for '[PIC]: IIC Routines - giving, not needing' 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/i2cs.htm?key=iic
Search entire site for: 'IIC Routines - giving, not needing'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: IIC Routines - giving, not needing'
2001\02\21@033039 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,

Andrew wrote:
>Had some free time and noticed that the PICLIST library was running short
of
>I^2C routines, especially COMMENTED ones that can actually be understood.
I
>can't stand impenetrable code.  So I pulled mine out of some recent code
>that I had.  Should be helpful at the very least to build up the library.

Amen !

I just wish more people thought like that.

/Tony


Tested/bulletproof at 4MHz.  See attached.
Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: spam_OUTtony.kubekTakeThisOuTspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

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


2001\02\21@033924 by spam

flavicon
face
Great idea. Thanks.

If anyone needs an I2C slave in CCS C (16F877) that actually
works (using interrupts) I have one.
Sorry for not sending it out there right now. I am kind'a busy these
next days.

Kent

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


2001\02\21@042757 by Martin Lintzgy

picon face
Hi Tony.

Stumbled across your email in the piclist, Re I2C, but no attachment.
I have written a bit bashed master <-> talking to a
PIC hardware slave using the SSI module. The master is easy, the slave no
walk in the park.
I am sending 6 bytes back and forth between master and slave, and my
routines work OK,
but every now and then, the bus gets stuck. Trying to debug is driving me
nuts, as the stuck lines happen once every couple of weeks or so.
You mentioned that your routines are bulletproof !
Any chance of a copy, (there was no attachment) ?

.....matin.lintzgyKILLspamspam@spam@tesco.net


{Quote hidden}

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

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


2001\02\21@082459 by Drew Vassallo

picon face
>Hi Tony.
>
>Stumbled across your email in the piclist, Re I2C, but no attachment.

That's because it was my email.

>You mentioned that your routines are bulletproof !
>Any chance of a copy, (there was no attachment) ?

They are bit-banged routines.  Probably wouldn't help your cause too much if
you are using the SPI interface.  Check back in the PICLIST for my original
email; I don't have the routines on this computer.

--Andrew

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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


2001\02\21@114509 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Drew Vassallo [SMTP:@spam@snurpleKILLspamspamHOTMAIL.COM]
> Sent: Wednesday, February 21, 2001 12:20 AM
> To:   KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
> Subject:      [PIC]: IIC Routines - giving, not needing
>
> Had some free time and noticed that the PICLIST library was running short
> of
> I^2C routines, especially COMMENTED ones that can actually be understood.
> I
> can't stand impenetrable code.  So I pulled mine out of some recent code
> that I had.  Should be helpful at the very least to build up the library.
>
> Tested/bulletproof at 4MHz.  See attached.
>
> --Andrew
>
Not looking a gift horse in the mouth but I have some constructive criticism
based on some (very frustrating) experience.

The routines use consecutive bsf/bcf operations on a port throughout the
code.  Although it might be bulletproof under the condtions you tested at,
any extra line capactitance could lead to very intermitant or no operation.
Raising the clock speed would have simmilar consequences.  At a minimum I
would be tempted to have a nop between bit sets to a port, even at 4MHz.
For real bulletproof operation at higher clock speeds, bit sets on a port
would have to be avoided, and a shadow register used.

Mike

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


2001\02\21@115713 by Richard Sloan

flavicon
face
Is this a known problem with PICS?

What do you mean shadow reg?

R.

 >>  > -----Original Message-----
 >>  > From: Drew Vassallo [SMTP:RemoveMEsnurpleTakeThisOuTspamHOTMAIL.COM]
 >>  > Sent: Wednesday, February 21, 2001 12:20 AM
 >>  > To:   spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU
 >>  > Subject:      [PIC]: IIC Routines - giving, not needing
 >>  >
 >>  > Had some free time and noticed that the PICLIST library was running
 >>   short
 >>  > of
 >>  > I^2C routines, especially COMMENTED ones that can actually be
 >>   understood.
 >>  > I
 >>  > can't stand impenetrable code.  So I pulled mine out of some recent code
 >>  > that I had.  Should be helpful at the very least to build up the
 >>   library.
 >>  >
 >>  > Tested/bulletproof at 4MHz.  See attached.
 >>  >
 >>  > --Andrew
 >>  >
 >>  Not looking a gift horse in the mouth but I have some constructive
 >>   criticism
 >>  based on some (very frustrating) experience.

 >>  The routines use consecutive bsf/bcf operations on a port throughout the
 >>  code.  Although it might be bulletproof under the condtions you tested at,
 >>  any extra line capactitance could lead to very intermitant or no
 >>   operation.
 >>  Raising the clock speed would have simmilar consequences.  At a minimum I
 >>  would be tempted to have a nop between bit sets to a port, even at 4MHz.
 >>  For real bulletproof operation at higher clock speeds, bit sets on a port
 >>  would have to be avoided, and a shadow register used.

 >>  Mike

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

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


2001\02\21@120349 by promero

flavicon
face
part 0 44 bytes
his is a multi-part message in MIME format.
part 1 804 bytes content-type:text/plain; charset=us-ascii (decoded 7bit)

> Not looking a gift horse in the mouth but I have some constructive
criticism
> based on some (very frustrating) experience.

> The routines use consecutive bsf/bcf operations on a port throughout
the
> code.  Although it might be bulletproof under the condtions you tested
at,
> any extra line capactitance could lead to very intermitant or no
operation.
> Raising the clock speed would have simmilar consequences.  At a
minimum I
> would be tempted to have a nop between bit sets to a port, even at
4MHz.
> For real bulletproof operation at higher clock speeds, bit sets on a
port
> would have to be avoided, and a shadow register used.

Note that bsf/bcf operations are performed to the tris (data direction)
registers, not to the port.


part 2 422 bytes content-type:text/x-vcard; charset=us-ascii;
(decoded quoted-printable)

begin:vcard n:Romero Plaza;Pável Ernesto
tel;cell:5489528
tel;fax:6-7444829
tel;home:6-7464233
tel;work:6-7444829
x-mozilla-html:TRUE
url:http://www.insitel.com.co
org:Insitel Ltda.;Research & Development
adr:;;Calle 21 # 16 - 46 Piso 7;Armenia;Quindío;;Colombia
version:2.1
email;internet:TakeThisOuTpromeroEraseMEspamspam_OUTinsitel.com.co
title:Hardware Engineer
fn:Pável Ernesto Romero Plaza
end:vcard


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


2001\02\21@132722 by Drew Vassallo

picon face
> > The routines use consecutive bsf/bcf operations on a port throughout
>the
> > code.  Although it might be bulletproof under the condtions you

>Note that bsf/bcf operations are performed to the tris (data direction)
>registers, not to the port.

Very true.  I believe the problems encountered with consecutive PORT bit
operations are not applicable to TRIS registers.  But otherwise, you'd be
right.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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


2001\02\21@133137 by Drew Vassallo

picon face
>Is this a known problem with PICS?

Yes.  Consecutive PORT operations (namely bcf/bsf) do not always work with
higher capacitance loads.  Also, there is a warning on consecutive PORT
write/read operations in many of the datasheets.  It's always a good idea to
add a nop (or even more than 1) between these commands.

>What do you mean shadow reg?

I dunno.  Never used them.  I would be interested, though, because I have
some untested 20MHz I^2C code that I need to use in the future.  If there's
going to be a problem, it would be nice to know it.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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


2001\02\21@152834 by Olin Lathrop

face picon face
> >What do you mean shadow reg?
>
> I dunno.  Never used them.  I would be interested, though, because I have
> some untested 20MHz I^2C code that I need to use in the future.  If
there's
> going to be a problem, it would be nice to know it.

A "shadow register" is a term for keeping a separate copy of something which
is the state you want the real thing to be.  In this instance, he wants to
avoid read-modify-write operations on PORTB.  The shadow register contains
the desired value of PORTB.  The read-modify-write operations are performed
on the shadow register where there are no problems with this, then the new
shadow register value is written (no read) to PORTB.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinspamTakeThisOuTembedinc.com, http://www.embedinc.com

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


2001\02\21@154253 by Drew Vassallo

picon face
>A "shadow register" is a term for keeping a separate copy of something
>which
>is the state you want the real thing to be

Oh, well, then I *have* used them :)  Boy, gotta know the lingo here.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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


2001\02\21@203013 by promero

flavicon
face
part 0 44 bytes
his is a multi-part message in MIME format.
part 1 908 bytes content-type:text/plain; charset=us-ascii (decoded 7bit)

Drew:

There may be a problem with your iic routines:

Byte_In
   clrf    Data_Buf
   movlw    0x08   ; 8 bits to receive
   movwf    GenCount
ControlIn
   bsf    STATUS, RP0  ; select Bank 1 to access TRISB
   rlf    Data_Buf, 1  ; shift bits into buffer
   bcf    SCL   ; pull clock line low
   nop
   bsf    SCL   ; pull clock high to read bit
   bcf    STATUS, RP0  ; select Bank 0 to read PORTB bits directly!
   btfsc    SDA   ; test bit from EPROM (if bit=clear, skip because
Data_Buf is clear)
?    bsf    Data_Buf, 0  ; read bit into 0 first, then eventually shift
to 7
?    decfsz    GenCount, 1
   goto    ControlIn
   bsf    STATUS, RP0  ; leave Bank 1 active (don't have to wait for
ACK here)

in the lines where i put the question marks you are modifying/reading
two variables(GenCount and Data_Buf) belonging to bank1, but you are in
bank 0!!!



part 2 422 bytes content-type:text/x-vcard; charset=us-ascii;
(decoded quoted-printable)

begin:vcard n:Romero Plaza;Pável Ernesto
tel;cell:5489528
tel;fax:6-7444829
tel;home:6-7464233
tel;work:6-7444829
x-mozilla-html:TRUE
url:http://www.insitel.com.co
org:Insitel Ltda.;Research & Development
adr:;;Calle 21 # 16 - 46 Piso 7;Armenia;Quindío;;Colombia
version:2.1
email;internet:promeroEraseMEspam.....insitel.com.co
title:Hardware Engineer
fn:Pável Ernesto Romero Plaza
end:vcard


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


2001\02\21@210953 by Drew Vassallo

picon face
>There may be a problem with your iic routines:
>     bsf    STATUS, RP0  ; select Bank 1 to access TRISB
>     rlf    Data_Buf, 1  ; shift bits into buffer
..snip...
{Quote hidden}

Who said they were in bank 1?  You could put them wherever you wanted :)

Interesting, this could be a problem with many PICs.  I hadn't considered
the various ports possible.  These were created for a PIC16C71, which maps
Bank1 addresses to Bank0.  I'll have to recheck these and put some notes in.

Good catch.  However, on a lot of PICs, there are memory addresses that are
mapped in all Banks.  Granted, people would like to reserve these for more
important registers instead of using them for I^2C routines, but they're
there anyways. :)

--Andrew

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

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


2001\02\22@030258 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Drew Vassallo [SMTP:EraseMEsnurplespamHOTMAIL.COM]
> Sent: Wednesday, February 21, 2001 6:27 PM
> To:   RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU
> Subject:      Re: [PIC]: IIC Routines - giving, not needing
>
> > > The routines use consecutive bsf/bcf operations on a port throughout
> >the
> > > code.  Although it might be bulletproof under the condtions you
>
> >Note that bsf/bcf operations are performed to the tris (data direction)
> >registers, not to the port.
>
> Very true.  I believe the problems encountered with consecutive PORT bit
> operations are not applicable to TRIS registers.  But otherwise, you'd be
> right.
>
Heh, guess I should have looked a little closer before shooting that email
off!  I only mentioned it, because I had so much grief on the first ever PIC
project I worked on (a PID TEC controller...talk about jumping in at the
deep end!).  The PIC was running at 4MHz and I was driving a MOSFET bridge
to control current direction through the PIC.  Couldn't understand why some
bits weren't getting set :o)  I suspect the MOSFET's had enough gate
capacitance to upset things.

Mike

--
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


2001\02\22@035856 by Martin Lintzgy

picon face
Ok, so a lot of talk about bit bashed I2C masters, which even as a newcomer,
is no too difficult, and there are a lot of code example about.


But has anyone out there implemented a bullet proof I2c interupt-driven SSI
based slave, to receive multiple bytes ?.


Martin Lintzgy

--
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


2001\02\22@044122 by spam

flavicon
face
--Message-Boundary-5465
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

Certainly !
Here !


--Message-Boundary-5465
Content-type: text/plain; charset=US-ASCII
Content-disposition: inline
Content-description: Attachment information.

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

  ---- File information -----------
    File:  i2c.c
    Date:  21 Feb 2001, 20:58
    Size:  1784 bytes.
    Type:  Program-source

--Message-Boundary-5465
Content-type: Application/Octet-stream; name="i2c.c"; type=Program-source
Content-disposition: attachment; filename="i2c.c"
Content-transfer-encoding: BASE64

dHlwZWRlZiBlbnVtIHtOT1RISU5HLCBDT05UUk9MX1JFQUQsDQogICAgICAgICAgICAgIEFE
RFJFU1NfUkVBRCwgUkVBRF9DT01NQU5EX1JFQUR9IEkyQ19TVEFURTsNCg0KLy8gSTJDIGJ1
ZmZlciBpcyBzYWZlIHdoZW4gZnN0YXRlIGlzIE5PVEhJTkcgKGF0IGxlYXN0KQ0KI2RlZmlu
ZSB3YWl0X3NhZmVfaTJjKCkgd2hpbGUgKGZzdGF0ZSE9Tk9USElORykge30gOw0KDQpJMkNf
U1RBVEUgZlN0YXRlOyAgICAgICAgLy8gU3RhdGUgb2YgSTJDIGNvbW11bmljYXRpb24NCmJ5
dGUgaTJjYWRyOyAgICAgICAgICAgICAvLyBJMmMgYWRkcmVzcyBhbmQgaW5kZXggaW4gYnVm
ZmVyDQpieXRlIGkyY2J1ZltpMmNidWZsZW5dOyAgLy8gaTJjIGJ1ZmZlcg0KY2hhciogaTJj
aWR4OyAgICAgICAgICAgIC8vIGkyYyBkcml2ZXIgaW50ZXJuYWwgYnVmZmVyIHRvIGlkeA0K
DQojYnl0ZSBTU1BDT04gID0gMHgxNA0KI2J5dGUgU1NQQ09OMiA9IDB4OTENCiNieXRlIFNT
UFNUQVQgPSAweDk0DQoNCi8vIEJpdHMgaW50ZXJlc3RpbmcgZm9yIGludGVycnVwdCByb3V0
aW5lDQojZGVmaW5lIGkyY19yZCAgICAgYml0X3Rlc3QoU1NQU1RBVCwyKSAvKiBTZXQgd2hl
biByZWFkIG9wZXJhdGlvbiAqLw0KI2RlZmluZSBpMmNfcyAJICAgYml0X3Rlc3QoU1NQU1RB
VCwzKSAvKiBTZXQgd2hlbiBzIHJlY2VpdmVkIGxhc3QgKi8NCiNkZWZpbmUgaTJjX3AgCSAg
IGJpdF90ZXN0KFNTUFNUQVQsNCkgLyogU2V0IHdoZW4gcCByZWNlaXZlZCBsYXN0ICovDQoj
ZGVmaW5lIGkyY19ja3AgICAgYml0X3Rlc3QoU1NQQ09OLDQpICAvKiByZXNldCB3aGVuIGh3
IGhvbGRzIGNsayBsb3cgKi8NCiNkZWZpbmUgaTJjX2RhdGEgICBiaXRfdGVzdChTU1BTVEFU
LDUpIC8qIFNldCB3aGVuIGRhdGEgKG5vdCBhZGRyZXNzKSBvcGVyYXRpb24gKi8NCg0KDQov
Ly0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoN
Cg0KI2ludF9zc3ANCnNzcF9pc3IoKSB7DQogICBjaGFyIGluY29taW5nOw0KDQogICBpMmNz
Y2xsb3c9MDsgLy8gU29tZXRoaW5nIHJlY2VpdmVkLCBzY2wgZGlkIHNvbWV0aGluZywgZG8g
bm90IHRpbWUgb3V0Lg0KICAgaWYgKCFpMmNfcG9sbCgpKSB7IC8vaTJjX3BvbGwoKSByZXR1
cm5zIGZhbHNlIG9uICBydz0xLCByZWFkLiBzYW1lIGFzIGlyY19yZA0KCWlmIChpMmNfY2tw
KSBmc3RhdGU9Tk9USElORzsgZWxzZSB7IGkyY193cml0ZSgqKGkyY2lkeCsrKSk7IGZzdGF0
ZT1BRERSRVNTX1JFQUQ7IH07IC8vIE5BSyAtIGVuZCBvciByZWFkIG1vcmUNCiAgIH0gZWxz
ZSB7DQogICAgIGluY29taW5nPWkyY19yZWFkKCk7IGlmICghaTJjX2RhdGEpIGZzdGF0ZT1O
T1RISU5HOyAvLyBIZXJlIGFuIGFkZHJlc3MgKHdyaXRlKSB3YXMgcmVhZC4NCg0KICAgICAg
aWYgKGZTdGF0ZSA9PSBBRERSRVNTX1JFQUQpIHsgKihpMmNpZHgrKykgPSBpbmNvbWluZzsg
cmV0dXJuOyB9IAkJICAgICAgICAgICAgICAgICAvLyBNb3JlIGRhdGEgdG8gc3RvcmUNCiAg
ICAgIGlmIChmU3RhdGUgPT0gTk9USElORyAgICAgKSB7IGkyY2Fkcj1pbmNvbWluZzsgZlN0
YXRlID0gQ09OVFJPTF9SRUFEOyByZXR1cm47IH0gICAgICAgICAgICAvLyBUaGUgYWRkcmVz
cyBvZiB0aGUgUElDIHdhcyByZWFkLg0KICAgICAgaWYgKGZTdGF0ZSA9PSBDT05UUk9MX1JF
QUQpIHsgaTJjaWR4PSZpMmNidWZbMF0raW5jb21pbmc7IGZTdGF0ZSA9IEFERFJFU1NfUkVB
RDsgcmV0dXJuOyB9IC8vIEFkZHJlc3MgdG8gYnVmZmVyIGluIGkyY2lkeA0KICAgfQ0KfQ0K
DQo=

--Message-Boundary-5465--

--
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


2001\02\22@054502 by Alan B. Pearce

face picon face
>The read-modify-write operations are performed on the
>shadow register where there are no problems with this,
>then the new shadow register value is written (no read) to PORTB.

Humm, I seem to recall a discussion through this list a while back on Interrupt
on Change, and someone demonstrated that a write to a port fouls up the
interrupt detection the same as a read/modify/write on the port. The write does
actually do a dummy read apparently, even though the info it is writing is not
what was read.

I cannot remember just when the discussion was, you will need to search the
archive - should not be hard with James' new search bot.

--
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


2001\02\22@071916 by Bob Ammerman

picon face
> >The read-modify-write operations are performed on the
> >shadow register where there are no problems with this,
> >then the new shadow register value is written (no read) to PORTB.
>
> Humm, I seem to recall a discussion through this list a while back on
Interrupt
> on Change, and someone demonstrated that a write to a port fouls up the
> interrupt detection the same as a read/modify/write on the port. The write
does
> actually do a dummy read apparently, even though the info it is writing is
not
> what was read.

This is correct. Even a MOVWF, as I understand it, does a read on the port
before writing the new value.
This isn't an issue when dealing with the pin-capacitance, back-to-back I/O,
shadow register stuff.  But it DOES mess up interrupt-on-change.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
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


2001\02\22@081443 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

Even if it does a dummy read, as long as the information it read was
discarded and it transfers your byte to the port latches there should be no
problem.  PORTB Interrupt on change is a whole other ball game though...

Mike

--
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


2001\02\22@090031 by Drew Vassallo

picon face
> > Humm, I seem to recall a discussion through this list a while back on
> > Interrupt
> > on Change, and someone demonstrated that a write to a port fouls up the
> > interrupt detection the same as a read/modify/write on the port. The
>write

I learned long ago NOT to use the port for anything except interrupt on
change, if you want that feature.  Even if it could be worked around, the
code would be so ugly it might not even be worthwhile.

From the 16C71 datasheet:

"The interrupt on change feature is recommended for
wake-up on key depression operation and operations
where PORTB is only used for the interrupt on change
feature. Polling of PORTB is not recommended while
using the interrupt on change feature."

I don't think they make as big of a deal out of this as they should.  One
small paragraph at the end of the I/O section can easily be overlooked.
Besides, they just say "not recommended"... I've *never* gotten it to work
with any reliability (i.e. >99% accuracy) without fouling everything up in
the ISR.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
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


2001\02\22@150124 by Harold M Hallikainen

picon face
       I have GENERALLY not run into trouble doing bsf and bcf on ports, but
I'm generally running light loads right next to the PIC.
       A shadow register is a location in RAM where you do all your bsf and bcf
operations for a particular port, then copy the register to the port.
       The 18c series PICs has separate access to the output latch on a port so
you can do bsf lata,0 and not worry about pin loading. In fact, the pin
can be shorted to ground and you'd still get what was previously written
to the latch. On the 18c, I use the port latch (lata, latb, etc.) for all
outputs (including bsf and bcf) and use the port registers (porta, portb,
etc.) for all inputs.

Harold


On Wed, 21 Feb 2001 13:31:37 -0500 Drew Vassallo <EraseMEsnurplespamspamspamBeGoneHOTMAIL.COM>
writes:
{Quote hidden}

FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

--
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


2001\02\22@170116 by Tony Nixon

flavicon
picon face
Martin Lintzgy wrote:
>
> Ok, so a lot of talk about bit bashed I2C masters, which even as a newcomer,
> is no too difficult, and there are a lot of code example about.
>
> But has anyone out there implemented a bullet proof I2c interupt-driven SSI
> based slave, to receive multiple bytes ?.
>
> Martin Lintzgy
>


Maybe James could set up a "Napster" for micro code :-)


--
Best regards

Tony

mICro's
http://www.picnpoke.com
RemoveMEsalesKILLspamspampicnpoke.com

--
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


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