Searching \ for 'SSP in I2C slave transmit problem' 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: 'SSP in I2C slave transmit problem'.

Truncated match.
PICList Thread
'SSP in I2C slave transmit problem'
1997\12\10@090833 by Keith Howell

flavicon
face
Dear all,

I've just subscribed to this discussion so please feel free to correct my
etiquette.

I have a problem using the PIC16C65 as an I2C slave returning data back to the
master.
Things work fine until the end of the first data byte returned.
The SCL and SDA line stay low. I believe this is the PIC's fault and not the
master, because the master
continues working when the PIC is reset.

I've checked everything I can: the CKP bit is cleared at the right time, the
TRISC registers indicate the I2C
output pins should be hi-z, there are no error conditions, etc. I thought the
problem was sending the wrong
number of data bytes, and tried to write interrupt code to examine the ACK bit
and thus eliminate this possible
culprit. The data sheet explains no way to do this. I've tried loading dummy
null bytes into SSPBUF before
setting CKP. I've tried trying to force SCL and SDA to hi-z by software.

I've trawled the web and come back with low quality info and amateur HTML.
Eventually I found the Microchip BBS
site and sifted out SSP I2C SLAVE related messages. Some have noticed the ACK
bit is unreadable from
interrupts. Some complain of lock-ups similar to mine. Quite a few express
annoyed with the fact that the SSP
only does slave duty not master (like finding a UART which provides a TxD pin
you have to bit-bang!). Microchip
don't seem to answer queries which highlight the shortcomings of their chips -
perhaps a wise move in
litigatious America.

I've also asked all my trade contacts without success. Ominously, one said his
experienced predecessor had
tried and failed to get I2C fully working with PICs and eventually implemented
some proprietary 4-bit bus! So I
don't think my problem is trivial.

Has anyone had these problems and if so how were they solved?

Thanks for your time in reading this.

1997\12\10@130718 by Dmitry Kiryashov

flavicon
face
Hello Keith .

There are two probable answers on your question:

1. Test carefully interrupt part of you code - what PIC doing after I2C
byte
  was received, looks like undesirable interrupt take place.

2. PIC processor have one interesting feature in Read-Modify-Write
instructions.
  For example BSF PORTA,1 read data from real pins (not internal latch)
modify
  bit 1 to "1" and write back byte to port_A output latch. The error
appear when
  port initially set as input but when you switch it to output mode
after R-M-W
  instructions you may get random values at port pins. For details see
your PIC
  manual. Also this error appear in mixed in-out port pins
combinations, after
  switching input pin to output mode after R-M-W command was executed
under this
  port.

Hope my suggestions help you.

WBR Dmitry.


{Quote hidden}

1997\12\11@073108 by Keith Howell

flavicon
face
Hi Dmitry (Kiryashov)

Thank you for writing. In response:
1. It's not an undesired interrupt after the I2C byte is received.
  The signals lock low within the first interrupt, immediately after sending
  the data byte.
  When they are stuck low, no I2C traffic can occur, so there are no further
  interrupts from the SSP either.

2. I'm aware of the Read-Modify-Write CPU access cycle effects.
  I can see how this could cause confusion in byte operations, but not single
bits.
  Surely Microchip can make a chip where a one-bit operation only affects one
bit?

  I don't think this is the problem because
  a) the problem occurs with or without my bit-twiddling code fragments trying
     to release the signals into hi-z.
  b) the registers indicate the signals should be hi-z.

I've just had a call from spam_OUTsteve.diaperTakeThisOuTspammicrochip.com who is a general microchip
FAE (Field Apps Eng,
Scandinavian area) directly employed by Microchip. He spoke to a chap called
Robert in the USA who says that he
has seen I2C slaves working in read and write directions. So it IS possible.
They say people have two common
problems with I2C.

1. Interrupt bits: SSPIF and SSPIE are same bit number in different banks.
  If you slip up on the data-page switching, can disable interrupts which can
lock signals low.

2: The problem with read-modify-write and bit operations, as you said.
  I said: "You're telling me Microchip have made a chip where a one-bit
operation
  affects more than one bit, and affects the other bits in bizzare ways? That's
appalling!"
  Response: "Yeah, really sucks, doesn't it?"

Right, I'm going bug hunting. I'll be back.


Joke: What is 1km long, has thousands of legs, teeth, eyes, and eats cabbage?

Clue: It's not a Chernobyl caterpillar.













Answer: The queue at a Polish butcher's shop.

1997\12\11@130231 by Keith Howell

flavicon
face
I've made some progress, but not complete success.

In hunting the wily bug, I noticed 1 or 2 bugs which may (or may not) have
reduced the problems.

I made my code loop endlessy when it came across problems. Such as the SCL line
not being high when it should.
The ICEPIC times out, and I can see where it does. Anyway, I notice that this
happens only on the second
interrupt (the one that says the first data byte sent - after receiving the
address - has gone).

Okay, then I notice that CKP has not gone high, despite the instruction to do
so.
It's locked somehow.
What am I doing differently between the two interrupts?
On the first I'm loading a byte into the SSP, on the second I'm not.
Aha! Maybe the SSP won't let you clear CKP unless you load the SSPBUF first?
I load a dummy byte, and the system does not lock up! Great!

However, this dummy byte is causing problems later on, but I'll work on that
tomorrow!

Hi again Dmitry.

I forgot my bike lights on leaving the building. By the time I'd be in and out
I'd miss the train home, so I'll
stay here till the next one. I wonder how good an engineer I have to be to
afford a Ferrari like the one Andy
Warren of Fast Forward engineering is selling (see their homepage!). If cars are
Freudian phallic symbols, then
my brand-new all-alloy mountain bike probably equates to a clitoris! Whoops, can
I say that kind of thing here?
Well, could be worse, a Lada or Trabant equate to body cavities.

Erm, where was I? Oh yes, I've begun to notice subtle problems emerging.

I can see that there seems to be no way of stopping the flow of bytes to the
master if you have to keep loading
dummy bytes into SSPBUF.  The master itself has to read the first data byte in
order to know how many bytes
will follow. So it must check the value of the first byte to decide when to put
the ACK/NACK bit.
For reasons previously discussed, the slave (PIC) has no way of reading the
ACK/NACK bit from an interrupt
anyway. But it may be vital to put this bit in the right place for the benefit
of the SSP hardware.
Maybe if this bit is set (indicating last transfer) then the SSP won't bother
interrupting the CPU to ask for
another byte.

If the SSP continues to be obstinate, I may just use it to detect the address
byte, then send the bytes back
using software. Okay, not as simple as loading a buffer, but the SSP would still
be partially useful in
alerting the PIC to the start of I2C messages.

Cheerio for now, Keith.

PS: Actually, if cars really were phallic symbols, you'd never drive them
anywhere.
You'd just drive it in and out of the garage all night wouldn't you?

1997\12\15@180831 by rustyc

flavicon
face
Keith Howell wrote:

> Hi Dmitry (Kiryashov)
>
> Thank you for writing. In response:
> ...

> 2. I'm aware of the Read-Modify-Write CPU access cycle effects.
>    I can see how this could cause confusion in byte operations, but not single
>  bits.

whoa there - if you need to change a bit in a byte, how are you going to NOT
changethe other bits without reading them?  Thus, changing a single bit demands
a
RMW cycle.

Unless I've really missed something, which is highly possible ;-)

rusty

1997\12\16@060916 by Keith Howell

flavicon
face
Rusty Carruth wrote:
>
> Keith Howell wrote:
>
> > Hi Dmitry (Kiryashov)
> >
> > Thank you for writing. In response:
> > ...
>
> > 2. I'm aware of the Read-Modify-Write CPU access cycle effects.
> >    I can see how this could cause confusion in byte operations, but not
single
> >  bits.
>
> whoa there - if you need to change a bit in a byte, how are you going to NOT
> change the other bits without reading them?  Thus, changing a single bit
demands
> a RMW cycle.
>
> Unless I've really missed something, which is highly possible ;-)
> The PIC instruction set has instructions that manipulate individual bits.
They read the whole register byte, twiddle the relevant bit,
then write the whole register byte back. Works fine for data registers.

The PIC designers mapped the I/O ports into register space.
Write a byte  to  PORTC and this goes to the output latch.
Read  a byte from PORTC and this is read from the port pins.
Seems fair enough.

Off they went and built the thing. However, strange things happen
when you try to bit twiddle I/O. For example, when bit-banging I2C,
you can make pins act as open-collector outputs by writing binary
xxx00xxx to the PORTC output latch.
Clear the corresponding bits in TRISC, and the outputs go low.
Set them, and the outputs float high.
The CPU can read PORTC to check the logic level on the pins.
So far so good.

Notice that what you read from PORTC is NOT what you wrote.
This is important.

Now suppose these output pins are set to be tristate, and are floating high.
Do a bit operation on any other port C bit.
You'd like to think that it would just affect that bit.
But you'd be disappointed.
The CPU will:
a) read a whole byte from PORTC, (SDA and SCL inputs as being high)
b) modify the other bit within the byte,
c) write the whole byte to the PORTC output latch.
This changes bits you did not expect: the SDA and SCL output latch bits.
Then when you try to operate SDA and SCL via TRISC,
they don't go low when expected, they get driven high.

As a result, because the chip architects some sloppily thought putting two
different registers at the same
logical address, all chip programmers are condemmed to thinking harder and more
carefully to compensate. There
are work-arounds, but I'm not pleased at having to do this extra work.

The words "Oh bugger" form in the mind.

Microchip are aware of all this but it's too late to change the fundamental
internal operation.

1997\12\16@153111 by John Payson

picon face
> The PIC designers mapped the I/O ports into register space.
> Write a byte  to  PORTC and this goes to the output latch.
> Read  a byte from PORTC and this is read from the port pins.
> Seems fair enough.
>
> Off they went and built the thing. However, strange things happen
> when you try to bit twiddle I/O. For example, when bit-banging I2C,
> you can make pins act as open-collector outputs by writing binary
> xxx00xxx to the PORTC output latch.

The PIC 16C5x was designed to be as simple and cheap as possible.  Adding
hardware to allow port reads to read the latch (rather than the physical
pin) would have increased the price.

If you need to do bit manipulations and don't trust the latches to read
back properly, use a "shadow register" and copy it to the real port as
needed.

1997\12\17@090430 by Keith Howell

flavicon
face
John Payson wrote:
>
> The PIC 16C5x was designed to be as simple and cheap as possible.  Adding
> hardware to allow port reads to read the latch (rather than the physical
> pin) would have increased the price.
> The cost of one 8-bit buffer and a bit of thought is insignificant
compared with the cost of the entire chip.
I know about the shadow register kludge technique.
I just object to having to need it.
Someone just asked me how you can modify one bit from a group of eight
without reading the others. It's perfectly possible to do this in hardware:
look at the 74LS259 chip: you can set/clear any one of eight 1-bit latches.

On the positive side, I think I have the PIC's SSP working.
I had to spend most of a week pursuing the matter through distributors etc,
and eventually right to a chap at Microchip's Arizona Fab.

I was right, there is no way I'd have got it working with the data sheets.
Essentially, the problems is caused by the R/W bit.
It isn't valid all the time!
Only when the address byte arrives.
After that, it contains a record of the ACK bit from a data byte transfer.

So if you service SSP interrupts by testing SSPSTAT R/W bit first, you're
stuffed.

The way to kludge round it is to test the Address/Data flag.

       If (an incoming address)
       {
               if( R/W bit says Read )
               {
                       // received the read-address
                       set a COPY of the R/W bit
                       load the SSPBUF with first data byte for master
               }
               else
               {
                       // received the write-address
                       clear a COPY of the R/W bit
                       empty the SSPBUF to clear the BF flag
               }
       }
       else
               if( the COPY of R/W bit says Read )
               {
                       // received the read-data
                       load the SSPBUF to send a byte to the master
               }
               else
               {
                       // received the write-data
                       empty the SSPBUF to accept a byte from the master
                       // this will clear the BF flag
                       handling this incoming data as necessary
               }
       }

Another warning: when the master is reading bytes from the PIC, the PIC will
always interrupt the PIC CPU.
If you have no more data to return, then you can't set the CKP bit without
loading the SSPBUF first!
You have to load a dummy byte.
What is more, the first (msb) of this byte will later appear on the SDA line.
So if your dummy byte is 0xxxxxxx, the SDA will be left stuck low, jamming the
bus!
So you must ensure your dummy byte begins with logic one.

I suspect this problem arises because my master is a bit naughty and
acknowledges all bytes from the PIC.
Perhaps if it NACKed the last byte, the SSP would not interrupt to ask for any
more bytes.
This is not a problem for many I2C slaves - the STOP condition resets all their
internal logic.
However there are some circumstances where the master might not know when to
acknowledge or not.
For example, if the PIC asked the master to read a variable length of message
data.
Either way, it seems a good precaution to send a dummy byte >= 128 if the master
reads too many bytes.

Hope this hard-won knowledge helps others implement readable I2C slaves using
PICs.
I may unsubscribe from PICLIST if I have no further problems, so if anyone
wishes to contact me use my work
e-mail, or if in the far future I no longer work there then try
.....106576.1560KILLspamspam@spam@compuserve.com

Cheers, Keith H.

1997\12\17@095922 by Thomas Magin

flavicon
face
At 13:39 17.12.1997 +0000, you wrote:

Hi,

>I was right, there is no way I'd have got it working with the data sheets.

Oh YES ...

>Essentially, the problems is caused by the R/W bit.
>It isn't valid all the time!
>Only when the address byte arrives.

Really ?

{Quote hidden}

What do you think of this piece of code (16C72):

I2C     bcf     PIR1,SSPIF      ; Clear SSP Interrupt
       bsf     STATUS,RP0      ; switch to Bank1

       btfss   SSPSTAT,DA_     ; If Address were received last
       goto    access          ;  decode next access
       btfsc   SSPSTAT,RW_     ; Data were received
       goto    rd_dat          ; master has read data
       goto    wr_dat          ; master wrote data

access  btfsc   SSPSTAT,RW_     ;
       goto    rd_adr          ; master read access will follow
       goto    wr_adr          ; master write access will follow

rd_dat  bcf     STATUS,RP0      ; switch to Bank0
       movf    TXCHECK,W       ; load Checksum
       movwf   SSPBUF          ;  in I2C-Register
       bsf     SSPCON,CKP      ; enable serial clock
       goto    intout          ; data was read by master

wr_dat  bcf     STATUS,RP0      ; switch to Bank0
       movf    SSPBUF,W        ; Get I2C data
       movwf   RXBUF           ;  store it in RXBUF
       bsf     PS,I2CDATA      ; set I2CDATA Flag
       goto    intout          ; data was written, result is stored in RXBUF

rd_adr  bcf     STATUS,RP0      ; switch to Bank0
       movf    TXDATA,W        ; load DATA
       movwf   SSPBUF          ;  in I2C-Register
       bsf     SSPCON,CKP      ; enable serial clock
       goto    intout          ; data will be read by master

wr_adr  bcf     STATUS,RP0      ; switch to Bank0
       movf    SSPBUF,W        ; read SSPBUF in order to clear BF
       goto    intout          ; data will be written by master

intout  return

It seems to be working fine. Without the copy of the RW-Bit.

Any comments ?

Regards

Thomas
=8-)

**********************************************************
* Thomas Magin                  FON:   ++49-761-4543-489 *
* marquette-Hellige GmbH        FAX:                -507 *
* Emergency Systems             email: maginspamKILLspamhellige.de  *
* Munzinger Str. 3                                       *
* D-79111 Freiburg / Germany                             *
**********************************************************

1997\12\17@112752 by Keith Howell

flavicon
face
Thomas Magin wrote:
>
> Oh YES ...
>
> Really ?

That's exactly the tone of voice parents use when about to confronting a kid
with
damning evidence of some misdemeanour. Sent shivers down my spine.

> Any comments ?

They say that too, just to make you squirm!

{Quote hidden}

Erm, I swear, me and my code is innocent!
I was only acting as per the information told me by the Microchip chap.
Ask him, he told me!
It fixed the problem, and I have no reason to complain.
Apart from the fact I enjoy it just a teeny bit.

Anyway, assuming your code to be working, you say it is for the (16C72).
Maybe the flags don't work in quite the same way as the 16C65.
Clutching straws I know.
Just a moment while I consult my 1996/1997 data book.

[sound effects of boots hobbling into the distance and back,
a la Goon Show, followed by pages flipping]

Aha! The PIC16C7x data sheet on page 10-77 says of R/W

       "This bit is only valid during the transmission"

does this mean it is NOT valid during reception?
And transmission from the master or slave's point of view?

The PIC16C6x data sheet on page 9-79 says of R/W

       "This bit is only valid from the address match to the next
       start bit, stop bit, or /ACK bit"

does this mean it is NOT valid almost immediately when the slave
acknowledges reception of the address byte?
/ACK bit high, low, or either?

In my best Inspector Clouseau voice, I can say that I deduce the
technical author had some reason for altering the text.
Normally a similar document is copied and the differences incorporated.
I should know. I was one once.
Do these two sentences mean exactly the same thing?
If so, why not use the same sentence?
Either way, I smell a rat.

Given the fact your code works on a '72, and my code needs the fix on a '65,
I suspect the two chips behave differently.

Just to confuse things even further, I've had the problems on my ICEPIC
emulator. This uses a 16C62 (running the code) in parallel with a 16C74
(running peripherals). So which is carrying the SSP I'm not sure.

So I put my hands on my hips, and say "What do you make of that then?"

Yours pedantically, Keith.

PS. I don't think this is going to lie down just yet!

1997\12\17@114904 by Marc Heuler

flavicon
face
Hi Keith (Keith Howell), in <.....34965DC5.EBEKILLspamspam.....arcam.co.uk> on Dec 16 you wrote:

> As a result, because the chip architects some sloppily thought putting two
>  different registers at the same
> logical address, all chip programmers are condemmed to thinking harder and
more
>  carefully to compensate. There
> are work-arounds, but I'm not pleased at having to do this extra work.
>
> The words "Oh bugger" form in the mind.

The AVR architecture is quite nice on this, it has a PORTx register which
is the latch.  You can read back what you wrote to it for bit operations.
And it has PINx, which represents the actual voltage level on the pin.

1997\12\17@121312 by Thomas Magin

flavicon
face
At 16:21 17.12.1997 +0000, you wrote:

Ouups,

>I was only acting as per the information told me by the Microchip chap.
>Ask him, he told me!

I've changed my code in the way you recommended.

>It fixed the problem, and I have no reason to complain.

And a problem was fixed which I were blaming the master (a PC-I2C-Interface)
for.

>
>Anyway, assuming your code to be working, you say it is for the (16C72).
>Maybe the flags don't work in quite the same way as the 16C65.

Nope. Now I'm quite sure that they are working in the same way.

>Aha! The PIC16C7x data sheet on page 10-77 says of R/W
>
>        "This bit is only valid during the transmission"

I told this sentence to a german microchip-guy several months before. They
had no real solutions, only some hints like "maybe it could ..., but I'm not
sure". The easiest way to confuse microchip ? Ask them for the SSP-Unit,
especially I2C.

Thanks for your pre work, it solved a tricky problem !

Let's enjoy the evening without I2C ...

So long

Thomas
=8-)

**********************************************************
* Thomas Magin                  FON:   ++49-761-4543-489 *
* marquette-Hellige GmbH        FAX:                -507 *
* Emergency Systems             email: EraseMEmaginspam_OUTspamTakeThisOuThellige.de  *
* Munzinger Str. 3                                       *
* D-79111 Freiburg / Germany                             *
**********************************************************

1997\12\17@124240 by XYGAX

picon face
In a message dated 17/12/97  16:38:44, you write:

<<
[sound effects of boots hobbling into the distance and back,
 a la Goon Show, followed by pages flipping]
 >>
Sounds like you were one of those people who made a computer from ECC83's and
shoveld coal in at the roots.

Ho Ho Ho and A MERRY CHRISTMAS TO ALL....................Steve

1997\12\17@130123 by Keith Howell

flavicon
face
Marc Heuler wrote:
>
> The AVR architecture is quite nice on this, it has a PORTx register which
> is the latch.  You can read back what you wrote to it for bit operations.
> And it has PINx, which represents the actual voltage level on the pin.
>Yep, I had a quick look at the AVR vs the PIC.
Pros: Faster processor, flash code memory.
Cons: Peripherals not quite as fancy as PIC.
       No I2C hardware, no interupt on port B changes.
Conclusion: useful if you need the raw power, eg processing signals.
Less useful if you want to make a less time-critical thing, like a user
interface.
Or if you want to make an I2C slave.

Returning to the SSP problem, what the Microchip chap said was:

    The typical sequence for a slave-transmitter operation is as follows:
    On an address match and R/W = 1, the PIC will generate an ACK and hold
    the clock low.  At this point the PIC will also generate an SSPIF
    (which must be cleared in SW).  The SSPBUF needs to be loaded with the
    TX data and then you set SSPCON.CKP, as you state.  The status of
    SSPSTAT.BF will tell you when the TX is complete.  Here is where I
    think part of the problem is.  If the Master generates an ACK, then
    the PIC IIC module is expecting to transmit another byte and thus
    holds the SCL low.  This is where you mention sending a dummy byte to
    fix the problem.  IIC protocol requires that when a device read is
    complete, a NOT_ACK pulse be generated.  So if the PIC detects an ACK
    instead of a NOT_ACK it will continue to transmit.  An easy way to
    determine if an ACK or NOT_ACK was generated by the Master is to
    monitor SSPSTAT.R/W.  If an ACK was generated by the Master, then the
    bit should still be set, indicating that a read from the device is
    still requested.  If a NOT_ACK was generated by the Master, then the
    bit should be cleared, indicating that the read is complete and the
    device is waiting for its next address match.  If the Master is still
    generating an ACK, but is no longer reading data, then it is violating
    the obligatory acknowledge generation protocol specified in the IIC
    spec. (section 6.2 "master receiver...must signal the end of data to
    the slave-transmitter by not generating an acknowledge on the last
    byte that was clocked out of the slave" - FYI I have this file in PDF
    format if you would like a copy).

    There are also some other things to be aware of with the PIC.  Any
    Read-Modify-Write (RMW) operation on the TRISC register could affect
    the SCL and SDA lines.  If you do a RMW operation on the TRISC
    register while an ACK is being generated by the PIC (such as after an
    address match), then you will essentially lock up the SDA line.  This
    occurs because the module will override the TRISC value while it is
    generating the ACK (override to a 0).  A RMW operation will write back
    a 0 to the TRISC.SDA location essentially pulling the SDA line low
    indefinitely.  If you are not doing a TRISC modifications, then this
    is not a problem.  Incidentally this is how we bit-bang Master mode -
    through manipulating the TRISC.SCL and TRISC.SDA.

1997\12\17@130330 by Keith Howell

flavicon
face
Thomas Magin wrote:
>
> I've changed my code in the way you recommended.
>
> And a problem was fixed which I were blaming the master (a PC-I2C-Interface)
> for.

Hoy! I subscribed to PICLIST to get my problems fixed. Not fix yours!
Maybe I can still get something out of this though.

Is your master PC-I2C-Interface a PC plug-in board,
or (preferably) an LPT-driven gadget. I wrote code to do that
some time ago, but it was very quickly done and was not multi-master.
I'd quite like such a gadget to help debug I2C gadgets I make.

> >Maybe the flags don't work in quite the same way as the 16C65.
>
> Nope. Now I'm quite sure that they are working in the same way.

Or as we pedants say, both are NOT working in a programmer-friendly way

>
> >Aha! The PIC16C7x data sheet on page 10-77 says of R/W
> >
> >        "This bit is only valid during the transmission"
>
> I told this sentence to a german microchip-guy several months before. They
> had no real solutions, only some hints like "maybe it could ..., but I'm not
> sure". The easiest way to confuse microchip ? Ask them for the SSP-Unit,
> especially I2C.

Yep, it must be even harder reading crap documentation in a second language.
Meanwhile the only designer who knows exactly how it works is probably
driving a Porsche to the golf course.

> Thanks for your pre work, it solved a tricky problem !
>
> Let's enjoy the evening without I2C ...
> I'd love to. When I get this thing working, I will.
Enjoy your evening of German beer and fair Rhinemadchens,
and I'll have a can of supermarket lager in my bedsit.

Unlucky? If I fell in a barrel of bosoms,
I'd come up sucking my thumb. :-<

1997\12\18@025457 by Thomas Magin

flavicon
face
At 17:54 17.12.1997 +0000, you wrote:
>Thomas Magin wrote:

Hi,

>or (preferably) an LPT-driven gadget. I wrote code to do that

LPT-driven.

>some time ago, but it was very quickly done and was not multi-master.
>I'd quite like such a gadget to help debug I2C gadgets I make.

It was a project of an electronic journal called "elektor". The pcbs are
still available. All you need in addition are some HCTs and a PCF8584 (and a
crystal, resistors, caps ...). The software is included if you buy the pcp.
Of course I can send it to you via email attachment before.

So long

Thomas
=8-)

**********************************************************
* Thomas Magin                  FON:   ++49-761-4543-489 *
* marquette-Hellige GmbH        FAX:                -507 *
* Emergency Systems             email: maginspamspam_OUThellige.de  *
* Munzinger Str. 3                                       *
* D-79111 Freiburg / Germany                             *
**********************************************************

1997\12\18@051943 by Keith Howell

flavicon
face
Rick Dickinson asked for a copy of the I2C spec in pdf format.
I don't have it yet, but we find the following useful:

"Single-chip 8-bit Microcontrollers. User Manual 1988"

"Philips Data Handbook IC12: I2C peripherals"

The latter has info on
       Application notes about I2C
       I2C bus and how to use it (including specifications)
       Programming the I2C interface
               (Reprint of an article by Mitchell Kahn
               in Dr. Dobb's Journal, June 1992)
       Exploring I2C
               (Reprint of an article by Steven Sarns & Jack Woehr
               in Embedded Systems Programming, Sept 1991)
       Bit banging serial ports
               (Reprint of an article by Mark Gardner
               in Embedded Systems Programming, Sept 1993)
       Development tools
       Addresses of I2Cbus hardware manufacturers.


Philips say this databook does not cover all the I2C chips around, not even all
theirs.
There are just so many these days.
It covers a lot of their LCD drivers, which I don't see a great deal of.
I guess people are happier with simple parallel-driven LCD chips.

1997\12\18@063317 by bam-mon

flavicon
face
Thomas Magin wrote:
{Quote hidden}

Hi,
I tried to order the PCB and/or the Software and the GAL from ELEKTOR,
they told me (on the phone) "yes, all available". But when I orderd the
stuff, they told me "sorry, not on stock anymore". My further questions
via Fax and mail (just to order the software and the GAL-Listing)
weren't even answered. I'm still looking for a solution like LPT -> I2C
- Converter.

greetings,   Reelf


--
        BAMBERG & MONSEES GbR
 Systeme f|r Wissenschaft und Technik
   Am Postmoor 36 * D-28719 Bremen
Fon +49-421-646775 * Fax +49-421-646785

1997\12\18@070300 by Andy Kunz

flavicon
face
>>or (preferably) an LPT-driven gadget. I wrote code to do that
>
>LPT-driven.

Carmacon has a thing called Chippey that programs EEPROM on the parallel
port.  No extra power needed, just a little PCB with a D25 on the end.
They don't have info on their page about it, but I've bought a couple.

Andy


==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\12\18@071137 by WF AUTOMACAO

flavicon
face
Keith Howell wrote:
{Quote hidden}

all
>  theirs.
> There are just so many these days.
> It covers a lot of their LCD drivers, which I don't see a great deal of.
> I guess people are happier with simple parallel-driven LCD chips.

Intel have a I2C PDF documentation! Very good!

Try http://www.intel.com and use "I2C" as search.

mIGUEL.

1997\12\18@130125 by Keith Howell

flavicon
face
Andy Kunz wrote:
>
> Carmacon has a thing called Chippey that programs EEPROM on the parallel
> port.  No extra power needed, just a little PCB with a D25 on the end.
>Yes, the hardware is no problem.

Two 2N7000 transistors and a pair of pull-ups is all you need for
any LPT port to become an I2C master. Many (maybe most) LPT ports
have open-collector control signal outputs (e.g. STB, ACK) that you can
directly drive SCL and SDA with, and do away with the components.

I've written MSDOS programs to bit bang the I2C bus, talking as a master to a
single-chip teletext receiver (GEC Plessey MV1815) and a Philips TV Tuner
(FQ916). That was fun, and relatively easy. Rather than polish up the MSDOS
user interface, I thought a Windows program would be much more worthwhile
to learn and implement. This is why I shelved the project - no time!

What I was looking for was some I2C software that would allow me to enter
I2C bus messages in ASCII hex on my PC then send them to my I2C slave PICs,
and read messages back.

Making the PC act as an I2C slave to listen to PICs acting as I2C masters
is harder. To avoid full-time polling, you can add wait-state generation
by adding an 74LS125 gate (or equivalent). With the input and output wired
to the SCL line, the SCL line will lock low if anything pulls SCL low.
This would hold it until the PC notices it, and takes over as a slave.
The PC can release SCL by raising the /OE pin.

I could get such code ready written, that would save time.
But I expect I'll have to write it myself eventually. >:o

1997\12\18@130136 by Keith Howell

flavicon
face
Thomas Magin wrote (of his LPT driven I2C interface):
>
> It was a project of an electronic journal called "elektor". The pcbs are
> still available. All you need in addition are some HCTs and a PCF8584 (and a
> crystal, resistors, caps ...). The software is included if you buy the pcp.
> Of course I can send it to you via email attachment before.
> I laughed at that project.

Why should I pay for hardware when it can be done in software alone?

Elektor is a hardware magazine. Software is seen as a necessary evil.

As a penny-pincher (professionally or personally!) I try to solve problems
with the minimum of hardware.

1997\12\19@073802 by Thomas Magin

flavicon
face
At 13:43 18.12.1997 +0000, you wrote:

>As a penny-pincher (professionally or personally!) I try to solve problems
>with the minimum of hardware.
>
>

as a hardwareengineer I solve most of my problems with a minimum of software
...

Thomas
=8-)

**********************************************************
* Thomas Magin                  FON:   ++49-761-4543-489 *
* marquette-Hellige GmbH        FAX:                -507 *
* Emergency Systems             email: @spam@maginKILLspamspamhellige.de  *
* Munzinger Str. 3                                       *
* D-79111 Freiburg / Germany                             *
**********************************************************

1997\12\19@175912 by johnb

picon face
> Thomas Magin wrote (of his LPT driven I2C interface):
> Why should I pay for hardware when it can be done in software alone? Elektor
is a
> hardware magazine. Software is seen as a necessary evil. As a penny-pincher
> (professionally or personally!) I try to solve problems with the minimum of
hardware.


It's worse than that. Elektor was stuck in some kind of time-warp; many
projects used large numbers of chips, usually, 74LS or worse, and needed
substantial power supplies. In the case of their I2C project, the
software was not very good, using a low-level IOCTL file access method
that is rather hard to use. It had bugs, so I phoned them. They replied
loftily "we do not offer upgrades to software".

I notice that W H Smiths no longer stock this magazine, and nor does the
public library. Has something happened to it?

I2C: I noticed the following announcement in a recent magazine: "Philips
announce an enhancement to its I2C that allows ICs with different supply
voltages to communucate, for minimal additional design-in effort or
cost". The remainder of the item indicates that Philips' chips now work
on 2.7 volts or less, and their "simple effective solution" for mixing
old and new chips involves a couple of transistors. The full circuit is
probably somewhere on the Philips Web Site.

Ricoh have brought out an I2C clock-calendar chip which has an
adjustable trimmer capacitor for the quartz crystal oscillator built
into the chip. It is the RS5C372A, in an 8-pin SSOP package. Power-down
current drain is 0.5 microamp at 3 volts.

I'm sure I've seen a built-in trimmer before, but I can't remember
where.

John Blackburn.

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