Hi Joep, Did some testing with the 18f devices, I've added a delay of 200us in i2c_hw_slave_isr_handler() procedure in the i2c_hw_slave_eeprom_simulator example, downloaded into one PIC and loaded a USB-I2C app in another PIC. When testing a read-increment-write function, it did fill with the timer. Then changed slave code by setting the SSPCON2_SEN bit, result: master hangs. Hooked up my scope and added a low value resistor on both side to determine whats going on. Saw that clock pin was held low by the slave, so looked at the AN734 app note (rev b) and saw that the Microchip code was clearing the CKP bit at the end of the ISR function (the only place), after adapting the code, the example was working OK. So it seems like that we have to set the SEN bit (at least for 18f devices) and have to adapt the statemachine, can not test it yet with a 16f877a since I still have to make a test board. Regards Albert
----- Original Message ----- From: "Joep Suijs" <[email protected]> To: <[email protected]> Sent: Saturday, August 01, 2009 6:13 PM Subject: [jallib] Re: i2c slave; clock stretch not enabled for MSSP hardware? > > 2009/8/1 a.faber <[email protected]>: >> In Slave mode: >> >> 1 = Clock stretching is enabled for both slave transmit and slave receive >> (stretch enabled) >> >> 0 = Clock stretching is enabled for slave transmit only (PIC16F87X >> compatibility) > Very interesting. 16f88 does not have this bit and since it only > supports slave, I assume it is 16f877 compatible. > This does mean that we've done without clock-streching while receiving > and never ran in trouble. This might be due to the fact that I queue > received bytes and processes them at the end and then we're probably > at the point of transmitting and do have clock-stretch support... > >> So to enable i2c slave clock stretching for bot transmit an receive, the >> SEN >> bit should be set in slave mode. > I think we should enable this, if we have the option. It might delay > comms a bit but keeps users out of trouble (missing or corrupted data > trouble). > >> Maybe tonight I can do a little testing, but currently I have not a >> 16f877a >> board with i2c, so I have to do some soldering first, I think it can be >> easily tested by adding 10us delay in the i2c slave echo example > you might need to send two bytes to the slave and put the delay in the > slave after it receives a byte. > > Just in case: 16f877a is good, 16f877 has different i2c behavior. > Can't remember what - just recall to stay away and rtfm when I can't > ;) > > Joep > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
