Hi Albert, As you might have seen, I also fixed an i2c bug (checking & clearing overrun). It turns out it is not too complicated to get i2c slave running, but when stress is increased, bugs surface... I think your test proves that, since clock streching does not work on 16f877a and alike, speedy respoonse is required to stay out of trouble (and low target_clock will thus get you in trouble). With clock-strech supported, it should be possible to make it full-proof.
Joep 2009/8/4 Albert Faber <[email protected]>: > > 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 -~----------~----~----~----~------~----~------~--~---
