Searching \ for ' 16C74A I2C-module woes ...' 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: '16C74A I2C-module woes ...'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] 16C74A I2C-module woes ...'
2000\09\12@064412 by Caisson

flavicon
face
Hello ,

 Yes, it's me again.  I'm still trying to get the I2C-module of the 16C74a
to work.  After some expirimentation I decided to go-with-the-flow and use
the method described in the 00734a papers.  Well, it workes.  As long as
the master sends a known number of bytes.

And that's my problem.  I do not know how many bytes the Master will send.
My solution was to incoorporate the Start & Stop-bits into the program.
Well, I can detect the Stop-condition all-right, but the combination of
bits in the SSPSTAT register for a Start-condition seems to be the same as
when a NACK is send (well, I mean an ACK is *not* send :-)

Has anyone got experience with the above, and/or knows a (good) solution to
the problem ?

Regards,
 Rudy Wieser

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use spam_OUTlistservTakeThisOuTspammitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\12@073815 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

I don't quite understand the problem (probably me being thick).  Presumably
you have set up a receive buffer in your slave.  The most bytes you can
recieve is the size of this buffer unless you are really cunning and make it
circular so that you use the data as it's being sent.  But as long as your
buffer is large enough for the biggest message why do you need to know how
many bytes the master will send?

Mike

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use .....listservKILLspamspam.....mitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\12@102206 by Barry King

flavicon
face
Rudy said:
> Well, it workes.  As long as
> the master sends a known number of bytes.
>
> And that's my problem.  I do not know how many bytes the Master will send.

Yes, that's true in general.

In a slave-write (PIC slave reading data from master), the PIC slave
does not know how many bytes the master will send, and must either
ACK every byte, or NACK them so the master will know you failed.

You can pre-arrange the desired number of bytes, but data corruption
can always make it seem more or less, so your software is more robust
if it can handle any number of bytes.

What I do in my slave-only code is have a buffer which can hold a few
more than the expected number of bytes, and if the buffer fills, stop
sending ACK, so the master can detect the failure.  He sends STOP,
and then tries again in another complete transaction.

> My solution was to incoorporate the Start & Stop-bits into the program.

Yes, that's important, especially in slave-transmit mode, where the
master WILL clock in as many bytes as it wants.  If you stop loading
bytes when the master is asking for more, the PIC will leave SCL
locked low and crash the bus forever.  So you've got to be prepared
to send dummy bytes for the "extra" data byte requests, until you get
an interrupt that has the STOP bit set, so you know you're done.

> Well, I can detect the Stop-condition all-right, but the combination of
> bits in the SSPSTAT register for a Start-condition seems to be the same as
> when a NACK is send (well, I mean an ACK is *not* send :-)

I don't understand.  There are seperate bits for START and STOP.
What bit pattern are you seeing that tells you that the master sent a
NACK?  I think the only way you know that the last byte was NACKed is
that the SSP does not ask you for another byte, because the master
NACKs the last byte to say it it done.

You get an interrupt for the last data byte requested, then later get
an interrupt with STOP set.  The NACK of the last byte is not really
indicated by the SSP (I wish it was).

Regards,

Barry.
------------
Barry King, KA1NLH
NRG Systems "Measuring the Wind's Energy"
http://www.nrgsystems.com
Check out the accumulated (PIC) wisdom of the ages at:
PIC/PICList FAQ: http://www.piclist.org

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu?body=SET%20PICList%20DIGEST>

2000\09\13@034131 by Caisson

flavicon
face
----------
> Van: Michael Rigby-Jones <mrjonesspamspam_OUTNORTELNETWORKS.COM>
> Aan: @spam@PICLISTKILLspamspamMITVMA.MIT.EDU
> Onderwerp: Re: 16C74A I2C-module woes ...
> Datum: dinsdag 12 september 2000 13:36
>
> > {Original Message removed}

2000\09\13@034142 by Caisson

flavicon
face
> Van: Barry King <KILLspambarryKILLspamspamNRGSYSTEMS.COM>
> Aan: RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU
> Onderwerp: Re: 16C74A I2C-module woes ...
> Datum: dinsdag 12 september 2000 16:40
>
> Rudy said:
> > Well, it workes.  As long as
> > the master sends a known number of bytes.

[Snip]

> > Well, I can detect the Stop-condition all-right, but the combination of
> > bits in the SSPSTAT register for a Start-condition seems to be the same
as
> > when a NACK is send (well, I mean an ACK is *not* send :-)
>
> I don't understand.  There are seperate bits for START and STOP.
> What bit pattern are you seeing that tells you that the master sent a
> NACK?

The bit-pattern I'm referring to is the one in the SSPSTAT-register.  It's
used in the routine described in the 00734.PDF (Using an I2C in-SSP-Module)
document.

> I think the only way you know that the last byte was NACKed is
> that the SSP does not ask you for another byte, because the master
> NACKs the last byte to say it it done.

You are right.  But what happens if a Master does not really behave well,
and terminates the reception of data with a Stop-bit ?  There would be an
open send condition present in the slave.

And that's just one of the problems. The other problem is that I do not
know when a Master stops *sending* data.  Timing out is not a real option,
because the other side could be tied-up in something more important that
sending I2C-bytes.  A real end-of-transmission would be the arrival of
either a Stop or Re-start-bit ...

And that's where I am now.  I can't seem to be able to incoorporate those
two.

> You get an interrupt for the last data byte requested, then later get
> an interrupt with STOP set.

Right.  The problem is that I can't recognise a NACK and a Start condition
from each other.  The bit-combination in the SSPSTAT register is exacly the
same for those two ...

> The NACK of the last byte is not really indicated by the SSP (I wish it
was).

Yeah.  That was another funny thing I found out .....

Regards,
 Rudy Wieser

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

2000\09\18@031516 by Caisson

flavicon
face
Hello all,

(I did send this before.  I just forgot to add the [PIC]: prefix ....)


 Yes, it's me again.  I'm still trying to get the I2C-module of the 16C74a
to work.  After some expirimentation I decided to go-with-the-flow and use
the method described in the 00734a.PDF papers.  Well, it workes.  As long
as
the master sends a known number of bytes.

And that's my problem.  I do not know how many bytes the Master will send.
My solution was to incoorporate the Start & Stop-bits into the program.

Well, I can detect the Stop-condition all-right, but the combination of
bits in the SSPSTAT register for a Start-condition seems to be the same as
when a NACK is received (well, I mean an ACK is *not* send :-)

Has anyone got experience with the above, and/or knows a (good) solution to
the problem ?

Regards,
 Rudy Wieser

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


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