Trev,

Making I2C monitor you can't use master or slave mode it is
Some thing else mode witch you simply do not respond to any
Command that means you can't use PIC hardware I2C to do this
Because of I2C in PIC must be master or slave mode so your choice
Is software I2C that works differently you do not ACK and
You do not send any thing you just monitor. Some thing like
This will work


1. wait for start condition if appeared then display [S]
2. read address what ever it is display [f3] for example
3. read ACK if 1 then NACK if 0 then ACK [ACK] or [NACK]
4. read data and display as is [DF]
5. wait for start condition [P] stop

you also need to add arbitration control that multiple masters may
attempt to control the bus that way you can display that too.

Andre Abelian


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>



Dear all,

I require an I2C monitor that works up to 400KHz (and possibly above).
At
present I'm using a monitor I built using a PIC and a PCF8584. The
beauty of
the PCF8584 is that it provides a special monitor mode, and therefore
hardware address-matching does not get in the way and no ack's are sent.
Unfortunately, the PCF8584 won't work with bus speeds higher than
100KHz.

I am investigating the possibility of using the internal I2C (MSSP)
module
in a PIC16F877 to perform the I2C interfacing. I presumed this would be
relatively straighforward if I configured the device for slave mode, but
one
thing concerns me: address matching. It appears that I2C messages are
only
readable by the software if a successful address match has occurred
first,
i.e. the message address matched with that stored in SSPADD. If there is
no
address match, the I2C data is discarded and NOT written to SSPBUF and
therefore cannot be read by the software. For an I2C monitor to listen
to
ALL I2C traffic, I don't want this address matching to happen. So, does
anyone know a way to get around this? In other words, is it possible to
implement a completely open I2C bus monitor using a PIC's internal MSSP?
Neither of the PICs I have looked at appear to have a monitor option to
disable this process.

If what I'm trying to do is indeed not possible, it looks like the best
option might be a pretty fast PIC with all I2C interfacing done purely
in
software.

Alternatively, I thought about configuring the MSSP to SPI mode and
using
some external glue logic to perform start / stop condition detection
(using
a flipflop or something). The MSSP in SPI mode would receive each I2C
byte
which would then be readily accessable by the software via the SSP's
receive
buffer. But the read buffer is only 8-bits wide... so presumably this
wouldn't be sufficient for I2C (I presume we have up to 10 or so clock
cycles, with the start/stop and ack pulses).

Any thoughts? Many thanks in advance to any advice offered on this
problem.

Cheers,

Trev
Trevor Page

The E-mail and any attachments hereto are strictly confidential and
intended
solely for the addressee. If you are not the intended addressee please
notify the sender by return and delete the message. You must not
disclose,
forward or copy this E-mail or attachments to any third party without
the
prior consent of the sender.

--
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: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics