Searching \ for 'R: Re: Which is the truth on I2C-SLAVE for PI' 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: 'R: Re: Which is the truth on I2C-SLAVE for PI'.

Truncated match.
PICList Thread
'R: Re: Which is the truth on I2C-SLAVE for PI'
1999\10\26@054608 by Paolo Marras

flavicon
face
Tanks a lot for your clear and precious answer.

-----Messaggio Originale-----
Da: Barry King <spam_OUTbarryTakeThisOuTspamNRGSYSTEMS.COM>
A: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Data invio: lunedl 25 ottobre 1999 16.47
Oggetto: Re: Which is the truth on I2C-SLAVE for PIC 16C74A?


> > I don't have an ack from a SLAVE micro neither when the PC is  the
Master
> > transmitter, nor when the comunication is between micro.
> > Why doesn't the PIC ack the first address byte of a I2C message?(the
address
> > is right)
> > Doesn't the PIC make the ack by hardware?

> Yes, if it is set up correctly.  So if it doesn't ACK, then it ISN'T set
> up right.  Interrupt has nothing to do with it until the SECOND byte, if
> you miss the first interrupt (from reset) the hardware will still ACK.
>
> > (And so if the SSP registers are configured, the interrupt enabled, and
the
> > proper Trisc bits set..., why no ack?)
> Are you sure you are setting up the registers right?  Did you
> remember to switch RAM banks to write the SSPADD register?
> Can you tell us what the values are in each register?  TRISC,
> SSPSTAT, SSPADD, SSPSTAT?   Do your tools allow you to
> confirm the values in the registers?

These are the register values that I can see in a simulation session by
Mplab:
Address Symbol       Value
93      SSPADD       B'10100100'
14      SSPCON       B'00111110'                        <<<<< Is This value
rigth?
13      SSPBUF       B'00000000'
39      SLAVE        B'10100100'
03      STATUS       B'00111100'
87      TRISC        B'00011000'
94      SSPSTAT      B'00000000
Thisi is the register image that I see when the PIC is waiting for a I2C
message, and another PIC (Programmed as Master) or a PC (that trys with
every possible address to catch an ack, scanning for active devices on the
bus) are sending their  message
What do you think about it?
>   And you are using 7 bit addresses?
yes I'm.


> test just the I2C Slave receive first.  Maybe just present the byte sent
> to you on Port B?  When you get that working, then do the same
> function with interrupts.  The ISR for the SSP must be careful to
> detect and clear error conditions, or the bus may be locked up by
> the Slave, but you are seeing no ACK, so this is not the problem.

Now, I'm working to do this.
And I'm waiting to obtain the use of an emulator, by which
I think to see the complete real register situation of the micro during
program esecution,
to see where is the problem.
May be that the PIC doesn't sense the START condition? Or what else?!
Bye and thanks.

Paolo Marras
AIRLAB (Artificial Intelligence and robotics LAB)
Politecnico di Milano

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