Searching \ for 'i2c' 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=i2c
Search entire site for: 'i2c'.

Truncated match.
PICList Thread
'i2c'
1997\01\22@103306 by Nihat Dagdemir

flavicon
face
i need i2c slave rutine for pic 16c84
if you have or if you know where i can get  please help me.
thank you.

1997\01\22@212718 by Sarunas Cepulis

flavicon
face
Nihat Dagdemir wrote:
>
> i need i2c slave rutine for pic 16c84
> if you have or if you know where i can get  please help me.
> thank you.
Hi,
See Microchip's (http://www.microcip.com or http://www.microchip2.com)
AN515 , AN541 , AN567 .
& see Paralax documents.
Best regards,
       Saras.


'I2C'
1997\03\03@162851 by Ed Todd
picon face
I've done master and slave in software on PIC.  I think the master runs
slower than most hardware driven masters, but who is counting cycles when
you can do it all on 2 wires.  The slave runs at a compatible speed to the
master software.  Our most complex I2C setup is:

 Master        PIC with lots of logic, LCD, keypad, etc
 0             Clock/alarm (via interrupt line) device for time keeping, 24 hou
r
wakeup alarms, etc.
 2             8 kByte memory device
 3             PIC with 6 line serial link to a PC.  Non-I2C interrupt line to
master
when a message arrives

The interrupt lines are needed to trigger the master to read from the
device when an event occurs.
 <spam_OUTedtoddTakeThisOuTspamsni.net>    Ed Todd

1997\03\16@050529 by richardd

flavicon
face
hi fellow pic list readers

i'am new to pic processors can anyone help me interface a pic to
the dallas one wire system
could someone provide me with an example of code to get me started
in the rite direction

1997\03\16@053057 by richardd
flavicon
face
hi fellow pic list readers

i'am new to pic processors can anyone help me interface a pic to
the dallas one wire system
could someone provide me with an example of code to get me started
in the rite direction


'I2C'
1998\02\23@091755 by Steve Parker
flavicon
face
   Hi,
      I have spent a torrid weekend trying to get my 16C74 communicating
      with a 24LC16B I2C memory chip. I just want to store a value at a
      time down and then retrieve the values for display on an LCD unit
      (this side of it works fine). I have based my efforts on AN578,
      but this uses a multi-master environment that is controlled through
      interrupts. I have therefore removed all the interrupt and keyboard
      stuff and just use the RDBYTE and WRBYTE routines. It appears to
      write ok but the values read back seem to be garbage. So my
      questions are:
          1) Is there any point using the I2C features on the 16C74 for my
             application (or is it all done in software - as all the modes
             supported are slave modes).
          2) Do I need interrupts.
          3) Is there a better example (code etc) anywhere which shows me
             more clearly.
      I expect you've had similar questions to these before - sorry!!
                          Thanks for any help,
                                Steve (Parker).
      PS: the application is storing altitude values in a model rocket.

1998\02\23@092638 by Steen Jensen

flavicon
face
Have a look at AN567. The code is very simple and easy to use.

Regards
Steen Jensen




From: .....Steve.ParkerKILLspamspam@spam@SRC.BAE.CO.UK on 23-02-98 12:07 GMT

Please respond to PICLISTspamKILLspamMITVMA.MIT.EDU

To:   .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
cc:    (bcc: Steen Schelle Jensen/Sales/DK_GDK/Grundfos)
Subject:  I2C




   Hi,
      I have spent a torrid weekend trying to get my 16C74 communicating
      with a 24LC16B I2C memory chip. I just want to store a value at a
      time down and then retrieve the values for display on an LCD unit
      (this side of it works fine). I have based my efforts on AN578,
      but this uses a multi-master environment that is controlled through
      interrupts. I have therefore removed all the interrupt and keyboard
      stuff and just use the RDBYTE and WRBYTE routines. It appears to
      write ok but the values read back seem to be garbage. So my
      questions are:
          1) Is there any point using the I2C features on the 16C74 for my
             application (or is it all done in software - as all the modes
             supported are slave modes).
          2) Do I need interrupts.
          3) Is there a better example (code etc) anywhere which shows me
             more clearly.
      I expect you've had similar questions to these before - sorry!!
                          Thanks for any help,
                                Steve (Parker).
      PS: the application is storing altitude values in a model rocket.

1998\02\25@085233 by Wayne Foletta

flavicon
face
Check out my PIC84 to 24LC16B test program. It may be of help to you.
It is under the "Engineering Design and Support Files" section at:

http://www.siliconsoft.com/ftp1site.htm

-Wayne Foletta
SiliconSoft, Inc.


You wrote:
{Quote hidden}


'I2C'
1998\05\02@151812 by Gordon Couger
flavicon
face
I am developing a I2C bus on a 68HC11. I will be using PICs on
the peripherals. What is the least expensive PIC that has I2C on
board? Dose anyone know where a bit bang routine for a PC
parallel port is available and does are there any standard
documents for I2C?

I am new to the list and new to PICs so I mostly a consumer of
information on PICs at the present. This will change. I am a pretty
good source of information on embedded systems in general I have
been doing then for 10 years now.

Thanks
Gordon

Gordon Couger EraseMEgcougerspam_OUTspamTakeThisOuTrfdata.net
624 Cheyenne
Stillwater, OK 74075
405 624-2855   GMT -6:00

1998\05\05@070939 by Keith Howell

flavicon
face
Hi Gordon <gcougerspamspam_OUTrfdata.net> and PIC people.

I've been working with I2C networked PICs for some time now, developing a smart
front panel for hi-fi.
Debugging this kind of thing, even with a storage scope, is like driving screws
with your thumbnail.
It's bad enough debugging one gadget, but if the other gadgets are of unknown re
liability and written by
someone else, then you can get into finger-pointing standoffs with other enginee
rs.
I developed an I2C snooping tool for my PC, so that I could do things like read
a whole EEPROM on screen as
hex bytes.
I can exchange particular messages to I2C slaves. I can tell my panel to shut do
wn its application, read
its switches and rotor, then write text to the display. Most usefully, I can gat
her evidence to say "look
mate, your gadgets writing the wrong data to EEPROM, it's _your_ bug!"

The I2C hardware is simple. STB drives SDA, AFD drives SCL. These are open-colle
ctor outputs with pull-ups.
Some chips like the 16C552 read the STB and AFD _pins_ back, but some may return
nothing (write only) or
the bits driving the OC buffers. For this reason, I've made it so SDA is sensed
by BSY, SCL is sensed by
ACK. This is easier to optoisolate if needed, and easier to tell if the PC or a
slave is driving a signal
low.

I'd advise isolation for anything remotely connected to the mains. Yesterday I p
lugged a TV aerial cable
into my I2C- programmable TV tuner/teletext project. I was shocked (literally) t
o find 144VDC between the
co-ax cable and my project ground. Turns out this condition exists while the liv
ing-room TV is in standby
mode (it shares the same aerial). Okay it is obviously of non-lethal impedance,
but if it caused me to say
ouch!' then it may damage chips. Just shows that opto-isolating your PC->I2C in
terface is welcome
insurance against unexpected nasties!

Once you have the code, you can use the same routines for I2C debugging tools an
d hobby projects.
I wrote my code in plain old C, so I can port it to micros if I wish, or wrap it
in a DLL for Windows.

Hope these tips help. Keith.


'I2C'
1998\06\11@151717 by Peter Schultz
flavicon
face
Hi All,
An usaul quick question,
The I2C bus supply mulitple devices, correct ?
You have to address them, so how the receiving device will know what is its
address ?
Where can I find the detailed description of I2C bus ?
Lots of thanks,
Peter

1998\06\11@171022 by David Wong

flavicon
face
You can find a detailed description of how to use the I2C bus on the Philips
site, www-us.semiconductors.philips.com.  The document of interest would be,
"The I2C bus and how to use it."  Look under microprocessors.

As for the slave address.  Typically the upper address range of a slave
devices is hard coded.  And the lower 3 lsb of the address range is user
selectable.  I2C uses a 7 bit address range (there's also a 10 bit, but you
can read up on that on your own).

Later
DW

       {Original Message removed}

1998\06\11@172655 by Ari Wahyudi

flavicon
face
There's an app note about I2C bus. and it's available at microchip
website..

-ari-

On Thu, 11 Jun 1998, Peter Schultz wrote:

> Hi All,
> An usaul quick question,
> The I2C bus supply mulitple devices, correct ?
> You have to address them, so how the receiving device will know what is its
> address ?
> Where can I find the detailed description of I2C bus ?
> Lots of thanks,
> Peter
>

1998\06\11@172703 by Martin Green

flavicon
face
    Some I2C devices have a hardwired ID code (according to some
    predefined ID ranges for particular devices in the I2C spec.), while
    other devices allow you to set at least some part of the ID code by
    grounding some input pins (typically 3, for 8 possible addresses).


    CIAO - Martin.


______________________________ Reply Separator _________________________________
Subject: I2C
Author:  pic microcontroller discussion list <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU> at
Internet
Date:    6/11/98 10:56 AM


Hi All,
An usaul quick question,
The I2C bus supply mulitple devices, correct ?
You have to address them, so how the receiving device will know what is its
address ?
Where can I find the detailed description of I2C bus ?
Lots of thanks,
Peter

1998\06\11@183951 by eas Dante

flavicon
face
On Thu, 11 Jun 1998, Peter Schultz wrote:
> The I2C bus supply mulitple devices, correct ?
In general right. Some serial EEPROMS have restricted address capability.
Hence it is allowed to have only one of them per I2C bus.

> You have to address them, so how the receiving device will know what is its
> address ?
> Where can I find the detailed description of I2C bus ?
Have a look in the datasheet of the PIC17C75X there is a long appendix
about I2C. You can find it on the Web page of microchip
(http://www.microchip.com).
I guess it is also written in datasheets of other PICs.
Good look!

Andreas, London, UK


------------------------------------------------------------------------------
my e-mail addresses:
               KILLspamA.DanteKILLspamspamCity.ac.uk
                 RemoveMEdanteTakeThisOuTspamsnoopy.e-technik.uni-dortmund.de

------------------------------------------------------------------------------

1998\06\12@004758 by tjaart

flavicon
face
Peter Schultz wrote:

> Hi All,
> An usaul quick question,
> The I2C bus supply mulitple devices, correct ?
> You have to address them, so how the receiving device will know what is its
> address ?
> Where can I find the detailed description of I2C bus ?
> Lots of thanks,
> Peter

Here are a few links :
http://www.wasp.co.za/~tjaart/electronicsearch.html

--
Friendly Regards

Tjaart van der Walt
spamBeGonetjaartspamBeGonespamwasp.co.za

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS TakeThisOuT0832123443EraseMEspamspam_OUTwasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1998\06\12@060541 by Keith Howell

flavicon
face
I'd recommend getting it straight from the horses mouth,
i.e. Philips. That's where Microchip got it from,
to write their own text. Why risk transcription errors?

It is a very clever bus, and well thought out, but
Microchip's app notes are virtually or worse than useless.

It's unfortunate that it is possible to write I2C code that
seems to work but is not completely correct or robust.

If I were Microchip, I'd be embarrassed to publish these
notes as they indicate an inadequate understanding of the I2C
bus and software to drive it.

If they can't provide code to drive the I2C bus properly,
have they ever fully tested their hardware? Believe me,
their SSP I2C hardware is pretty half-assed.

1998\06\12@064439 by Caisson

flavicon
face
> Van: Andreas Dante <RemoveMEdantespamTakeThisOuTsnoopy.E-Technik.Uni-Dortmund.DE>> > Aan: PICLISTEraseMEspam.....MITVMA.MIT.EDU
> Onderwerp: Re: I2C
> Datum: donderdag 11 juni 1998 22:51
>
> On Thu, 11 Jun 1998, Peter Schultz wrote:
> > The I2C bus supply mulitple devices, correct ?
> In general right. Some serial EEPROMS have restricted address capability.
> Hence it is allowed to have only one of them per I2C bus.

This is not a restriction in the EEPROM itself, but by way of
adressing-space.
All Memory-devices should have an Device adres address of 1010AAA? Binary.
(AAA == Device sub-address. can be set on pins 1, 2 & 3. ? is the
Read/Write bit)
Regard a 2048-byte RAM/EEPROM as eight seperate devices thrown together,
and it'll make more sense (you _address_ them as eight devices, from A0
thru AE (disregarding the Read/write bit) ).  Add to this the secondary
address-byte and there you have your memory-limit. (Extended adressing modi
devices have a special base-address)

[Cut]

Greetz,
 Rudy Wieser

1998\06\14@215705 by cdmb

flavicon
face
Please see:

http://www.semiconductors.philips.com/acrobat/3114.pdf\

I hope than this information is useful.

Sol—n C‡ceres Moreno
Ing de Sistemas UIS
Bucaramanga-Colombia

At 10:56 11/06/98 -0700, you wrote:
{Quote hidden}


'I2C'
1998\10\21@194508 by Jose Antonio Gracia Negre
flavicon
face
part 0 1490 bytes content-type:multipart/alternative; boundary="------------0FFBDACECAC875829620D" (decoded 7bit)


--------------0FFBDACECAC875829620D7B2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Hi All,
>
There are some code
athttp://margo.student.utwente.nl/el/ports/i2c/i2c       .zip
Algorithm for accessing an I2C bus.
i2c_faq   .zip    I2C FAQ by Vincent Himpe.
pci2c     .zip    Philips I2C monitoring program !! It uses the PC
printerport.
pci2cbd   .zip    Schematic (only a few ports) for using the Philips I2C
monitoring program.

Very interesting for beginners




--------------0FFBDACECAC875829620D7B2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>

<BLOCKQUOTE TYPE=CITE>
<PRE>Hi All,</PRE>
</BLOCKQUOTE>
There are some code atmargo.student.utwente.nl/el/ports/i2c/i2c&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;&nbsp;
.zip&nbsp;&nbsp;&nbsp; Algorithm for accessing an I2C bus.
<BR>i2c_faq&nbsp;&nbsp; .zip&nbsp;&nbsp;&nbsp; I2C FAQ by Vincent Himpe.
<BR>pci2c&nbsp;&nbsp;&nbsp;&nbsp; .zip&nbsp;&nbsp;&nbsp; Philips I2C monitoring
program !! It uses the PC printerport.
<BR>pci2cbd&nbsp;&nbsp; .zip&nbsp;&nbsp;&nbsp; Schematic (only a few ports)
for using the Philips I2C monitoring program.

<P>Very interesting for beginners

<P>&nbsp;
<BR>&nbsp;</HTML>

--------------0FFBDACECAC875829620D7B2--

part 1 260 bytes content-type:text/x-vcard; charset=us-ascii; name="vcard.vcf" (decoded 7bit)

begin:          vcard
fn:             Jose Antonio  Gracia Negre
n:              Gracia Negre;Jose Antonio
email;internet: EraseMEjgranespamcolon.net
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard



'i2c'
1999\06\28@190125 by Simon Redwood
flavicon
picon face
Does anyone have an i2c read routine in written in C ?

I am trying to read the information in a 24C02 eeprom, I can write to it
without any problems but my read fails.  Any source snippets would be of
assistance.

TIA

Simon

1999\06\28@190511 by Simon Redwood

flavicon
picon face
Does anyone have an i2c read routine in written in C ?

I am trying to read the information in a 24C02 eeprom, I can write to it
without any problems but my read fails.  Any source snippets would be of
assistance.

my read sequence is as follows:

{
byte i_byte = 0x00;
byte o_byte = 0x00;
int i;
int n;

start();
out_byte(0xa0 | (device<<1) | 0x01);    /* 1010 000 1 */
nack();
for(i=0; i<255;i++) {
 fprintf(stderr, "%x ", in_byte());
 nack();
}

stop();
}

TIA

Simon


'i2c'
1999\07\09@002149 by Marco Giammarinaro
flavicon
face
Does any one have a source (ha) for a reliable i2c driver in C?  I'm
using a PIC16C74A and PIC-C.  The sample code is just a little
suspect if you know what I mean.


'I2C'
1999\08\05@101619 by Jess LaFentres
flavicon
face
I am using a PIC 16C74A @ 4Mhz in my design.  I am attempting to use the
I2C module in the master mode.  I am addressing a 24C01C  device for
non-Volatile memory.  I am looking for some assembly code to do this with.
The things I have found at Microchips are either too encrypted to follow
or are for processors which are to different from the PIC I am using.  If
anyone could help I would greatly appreciate it

Jess LaFentres
Electro/Mech. Eng.
Global Surgical Corp.
3610 Tree Court Ind. Blvd.
St. Louis MO 63122-6622
(314)861-5286 Phone
(314)225-2036 Fax
RemoveMEjlafentrEraseMEspamEraseMEglobalsurgical.com

1999\08\05@174650 by kfinney

picon face
I've done it with C77 as master and 74A as slave
in the production version, but have run the master
code on the 74A as a testbed when we ran out
77s back in the spring, and couldn't source
any (remember that fiasco ? Nobody could get
a 77 to save their grandmother's life for about
6 weeks back in March/April sometime).

Anyway, the code is in production, so it works.
The gotcha is that it's for C (Hi-Tech flavour).
The upside is that, except for the actual bit
bashing that shoves the 1's & 0's out the door,
the rest is pretty much 1-for-1 mappable to
assembly code. Except for the bank switching,
too, of course 8^)

If you are still interested, even though its in
C, let me know.

Ken

----------------------------------------------
Kenneth C. Finney
==============================================
Wilkes Associates, Inc.
Software Engineering - Embedded Systems
Design & Development - Project Management
==============================================
170 The Donway West Ste. 405, Toronto, Ontario
Office: (416) 445-9224 Mobile: (416) 453-6400
----------------------------------------------

> {Original Message removed}


'I2C'
1999\12\04@161712 by felix centeno
flavicon
face
Hi Piclisters, I just build the PonyProgramer and tested it with a 24C16
and now I want to conect the eeprom to a 16F84 but I  don't have a i2c
rutine
has somebody a rutine disponiblk?

1999\12\04@191038 by Jose Souto

flavicon
face
The smallest and fastest I saw is from Microchip. I don't know where they
have it but it's a matter of seach their web site.

[]'s
JSouto

felix centeno wrote:
>
> Hi Piclisters, I just build the PonyProgramer and tested it with a 24C16
> and now I want to conect the eeprom to a 16F84 but I  don't have a i2c
> rutine
> has somebody a rutine disponiblk?


'I2C'
2000\01\07@212806 by Jinx
face picon face
Yes, I've checked the archives, still uncertain, and reluctant to ask.
Trying initially to get an F84 to talk to a 24LC65 but have other I2C
ICs in the wings. No problem with start bits or bytes but have run
into difficulty over the 9th clock pulse.

I have the Philips guide to I2C as well as AN515 (are the sub
headings mixed up BTW ?) and Nicole Ambrose's program from
the archives. Unfortunately everything else relating to I2C at the
archives seems to be unavailable.

I'm uncertain because every sample of code I look at seems to be
using a different method at the 9th pulse to determine Ack. I won't
go into details but suffice to say I'm confused. Part of the reason is
sparse commenting on code, but we've been there before haven't
we. Notes like "move FF into the accumulator" after movlw 0ffh
aren't particularly helpful. Plenty of what-it-does but hardly any why-
it-does-it.

OK, what I'd like to know specifically is - after the 8th data bit has
been clocked into the EEPROM, do you change the PIC SDA to
an i/p to test Ack or can you just send a "dummy" 9th pulse out,
and assume on a single-memory bus that Ack has been generated ?
Nowhere have I seen an explicit direction to change SDA direction
at Ack testing time and can't tell whether there's an implied one.

Can someone take a minute to give a blow-by-blow, doesn't even
have to be code, about I2C procedure please.

Jinx

2000\01\07@224430 by Ken Webster

flavicon
face
After the 8th bit, the EEPROM should pull the data line low for an ACK or
leave it high for NACK.  The IIC bus must be pulled high with resistors (1k
or 10k depending on how fast you want to go) and the PIC must only drive low
(not drive high) .. open-drain outputs are ideal for this but you can
achieve the same effect by seting the PORT bits low and using the TRIS bits
to drive the line low or let the resistors pull it high.

I have code for a 17C756 talking to a 24C64 here:
http://kdsl32.dnvr.uswest.net/cgi-bin/tl.exe/AERC/poscalc/eeprom.asm

It is commented .. I think pretty well but I haven't gotten anyone else's
opinions yet.

The port initializations (after reset) are here:
http://kdsl32.dnvr.uswest.net/cgi-bin/tl.exe/AERC/poscalc/init1.asm

Note that RA2 and RA3 are open-drain outputs on the 17C756, specifically
designed for IIC or similar applications.  On a normal output you would
simply program the PORT bit low and toggle the TRIS bit in the same manner
as the PORT bits are toggled in my 17C756 code.

Hope this helps,

Ken


{Quote hidden}

2000\01\08@041505 by Jinx

face picon face
Thanks, helpful. One reason I wanted a text explanation is because
it can be heavy-going sorting out calls and labels, even in a smallish
program, especially when there's a something you don't understand.
Open-drain pin RA4 would be the pin to use for SDA on an F84 then
to make life a little easier ?

Jinx

|
| Hope this helps,
|
| Ken

2000\01\08@071129 by Ken Webster

flavicon
face
>Thanks, helpful. One reason I wanted a text explanation is because
>it can be heavy-going sorting out calls and labels, even in a smallish
>program, especially when there's a something you don't understand.
>Open-drain pin RA4 would be the pin to use for SDA on an F84 then
>to make life a little easier ?


Perhaps.  I actually found the ordinary pins quite easy to use on a 16C74,
particularly because it is ok to use BCF and BSF directly on the TRISA,
TRISB, or TRISC registers (thus you needn't use a mirror register like you
do with PORTA, PORTB, or PORTC with read-modify-write instructions).

For example, with an open-drain pin:

     BSF   PORTA_MIRROR,2
     MOVF  PORTA_MIRROR,W
     MOVWF PORTA

With an ordinary pin:
Initialization:
     CLRF PORTA

Toggling a pin high:
     BSF  STATUS,RP0
     BSF  TRISA,2
     BCF  STATUS,RP0


A shortcut I often used was to point FSR at TRISA at the start of a
subroutine that talks to the EEPROM.  Then, in the body of ths subroutine, I
could use the following (instead of switching STATUS,RP0 back and forth):

     BSF  INDF,2


So, actually, I think it is easier to not use an open-drain pin as long as
you can use 2 pins on the same port and point FSR to that port.  For the
17C756 I chose to use the open-drain pins only because they were not useful
for anything else and I was short on pins.


I just found my code for a 16C74 talking to a 24C65.  It gives a good
example of using ordinary (not open drain) outputs.  I posted it here:
http://ken.webster.org/picee.txt

The program I chopped it out of is here:
http://kdsl32.dnvr.uswest.net/cgi-bin/tl2.exe/MPLAB/GPSPOS/main.asm

Ken

2000\01\09@194918 by Rich Leggitt

picon face
On Sat, 8 Jan 2000, Ken Webster wrote:

>       BSF   PORTA_MIRROR,2
>       MOVF  PORTA_MIRROR,W
>       MOVWF PORTA

Uh-oh, really? I'm new to pic, I simply assumed that BxF would work on the
output ports directly, either by RMW or bit-addressability. (Seems
unlikely the TRIS trick will help me, I need to generate ~500KHZ on PA2,
almost certainly hard pullup will be required.)

The documentation doesn't say anything about this, but DOES say: "All
write operations are read-modify-write operations, therefore a write to a
port implies that the port pins are read, the value is modified, and then
written to the port data latch".

When I first read that, my reaction was "So what?", perhaps it should have
been "What are they trying (and failing) to say?"

2000\01\09@225715 by quozl

flavicon
face
On Sun, Jan 09, 2000 at 04:49:51PM -0800, Rich Leggitt wrote:
> Uh-oh, really? I'm new to pic, I simply assumed that BxF would work on the
> output ports directly, either by RMW or bit-addressability.

A BxF will always work, for the bit you select.  It is the other bits
in the same port that may mysteriously change state from what you set
them too.  The read phase of the BxF reads the port pins, not the port
latches.

> When I first read that, my reaction was "So what?", perhaps it should have
> been "What are they trying (and failing) to say?"

Exactly.

--
James Cameron   RemoveMEquozlspam_OUTspamKILLspamus.netrek.org   http://quozl.us.netrek.org/

2000\01\10@003945 by Rich Leggitt

picon face
> A BxF will always work, for the bit you select.  It is the other bits
> in the same port that may mysteriously change state from what you set
> them too.  The read phase of the BxF reads the port pins, not the port
> latches.

OK, thanks, point noted. However, assuming that the output is well
buffered then is there any reason why a read always return the current
output state? But I will certainly no longer expect it hold state when
TRIS'd.

2000\01\10@004400 by Rich Leggitt

picon face
Sorry, key word omitted:

> A BxF will always work, for the bit you select.  It is the other bits
> in the same port that may mysteriously change state from what you set
> them too.  The read phase of the BxF reads the port pins, not the port
> latches.

OK, thanks, point noted. However, assuming that the output is well
buffered then is there any reason why a read WON'T always return the
current output state? But I will certainly no longer expect it hold state
when TRIS'd.

2000\01\10@011138 by quozl

flavicon
face
On Sun, Jan 09, 2000 at 09:41:31PM -0800, Rich Leggitt wrote:
> OK, thanks, point noted. However, assuming that the output is well
> buffered then is there any reason why a read always return the current
> output state? But I will certainly no longer expect it hold state when
> TRIS'd.

I think you're asking how long it will take for the voltage on the pin
(that is read in by a BxF instruction) will take to reach the point that
agrees with the port latch.

Depends on the capacitance of the pin, the package, the socket, the PCB
traces, and the remaining electrical circuit beyond the pin.  It can
never be zero time, unless you had infinite driving current.

Yes, "buffering" of the pin will change that.

If your clock is faster, then you will notice it more often.  Assuming
you even code something to watch it happen.  I was seriously depressed
when I figured out that a square wave edge really isn't square.  It made
electronics so much more unpredictable.

--
James Cameron   RemoveMEquozlTakeThisOuTspamspamus.netrek.org   http://quozl.us.netrek.org/

2000\01\12@184451 by dvdmods

flavicon
face
Hi
Thanks for all your input guys
I will try all your suggestions and take a better look at my start stop code
ect
will also check value of the external pull-ups (it has got some fitted)

I see what you mean Ken about leaving the sdata sclk LOW dont no what i was
thinking it would be better to tris gpio
and turn them into INPUTS after the bstart/bstop commands

Thanks Paul i like the macro and will rewrite my code

keep you all updated ..

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