Neil,

You are correct that the step 4 is where the timing requirement needs to=20
be met and that it is referenced from 3.
My "Safe to sample "  remark is an attempt to take advantage of the fact=20
that Param 11 (Step 4) will always be satisfied after Param 3 (Tlow) is=20
complete, and doing it this way would eliminate the need to additionally=20
wait before setting SCL high for the next bit.
I tried to modify your steps to illustrate but it is late and actually=20
putting it into the bit_in() routine as written is not easy.
The app note code does not require the additional delays due to the=20
slower clock.
Sorry to be adding noise.

Joe W

On 8/13/2014 9:34 PM, Neil wrote:
> Joe,
>
> That's what I did, adjusting all the timing between bit transitions to
> meet the parameters.  But it's that one spec I was not clear on and
> thought that the code from AN997 might have clarified it for me.
>
> When you say "... it should always be safe to sample SDA on the rising
> edge of SCL,",  I'm still confused, as I would expect this to happen...
> (1) Send L-->H transition.
> (2) Wait min clock-pulse high time
> (3) Send H->L transition.
> (4) Wait for next bit to be ready at the EEPROM output.
> (5) Sample the bit.
>
> It's that step (4) time that I want to be sure of, if it's referenced
> from (1) or from (3).
>
> FWIW, I do have my time period referenced from (3) currently and all
> works fine, but at 64Mhz it's a lot of Nop()'s to hold the 600ns min
> pulse time, THEN hold the 900ns data valid time.
>
> Cheers,
> -Neil.
>
>
> On 8/13/2014 5:31 PM, Joe Wronski wrote:
>> Without doing all the math, I think it is safe to assume that the App
>> note code is safe to use in the circuit specified, which has a 4 MHz
>> crystal.  The app note also says
>>>    If a faster clock is used,
>>> the code may need to be modified to ensure all timing
>>> specs are met.
>> You're gonna need some delays or interrupts to satisfy the Fclk spec
>> with a 64 MHz crystal (but you don't mention any prescaling) .  Assuming
>> your Fclk is in spec, it should always be safe to sample SDA on the
>> rising edge of SCL.
>> I would use the I2C timing specs more to decide on top level design than
>> to write the line to line code.  IOW, design it so that Fclk <=3D 400 kH=
z
>> and Tlow >=3D 1300 nS.
>>
>> Joe W
>>
>>
>> On 08/13/2014 04:14 PM, Neil wrote:
>>> I'm bit-banging I2C to a 24LC16B serial EEPROM with a PIC18F46K22 and
>>> working out the best timing for running at 64Mhz Fosc.  When reading
>>> bits from the EEPROM, I'm confused if the time for the data on the
>>> EEPROM output to be valid from the SCL pulse is referenced from the
>>> positive clock edge, or the negative clock edge.
>>>
>>> Figure 1-1 and Table 1-2 in the serial-EEPROM datasheet (
>>> http://ww1.microchip.com/downloads/en/DeviceDoc/21703L.pdf ) shows that
>>> parameter 11 ("Output valid from clock", which seems to be the one I
>>> want) is measured from the negative edge of the SCL pulse, but
>>> Microchip's AN997 (for bit-banging I2C) has this code, which seems to b=
e
>>> based off the positive clock pulse...
>>>
>>> void bit_in(unsigned char *data)
>>> {
>>>         SCL =3D 0;                        // Ensure SCL is low
>>>         SDA_TRIS =3D 1;                   // Configure SDA as an input
>>>         SCL =3D 1;                        // Bring SCL high to begin tr=
ansfer
>>>         *data &=3D 0xFE;                  // Assume next bit is low
>>>         if (SDA)                        // Check if SDA is high
>>>         {
>>>             *data |=3D 0x01;              // If high, set next bit
>>>         }
>>>         SCL =3D 0;                        // Bring SCL low again
>>> } // end bit_in(unsigned char *data)
>>>
>>> You'll see above that the clock is sent high, data read in, then the
>>> clock pulse is completed by sending it low.  So which is correct?
>>>
>>> Alternately, if the data at the serial-EEPROM output does not change
>>> (which I suspect, but am not sure about) after the clock pulse goes low=
,
>>> I guess I could just play it safe and wait the 900ns after that, though
>>> that would be unnecessarily wasting cycles which I could be using to do
>>> other processing.
>>>
>>> Cheers,
>>> -Neil.
>>>
>>>
>>
>

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.