And... boom!  That was it!  Timing works great now.

And this is why I hate being an occasional coder... there's too much I=20
forget when I'm not doing it regularly.

FWIW, looking at AN997 (which I used as the starting point for my code),=20
I see it was written in 2005.  I should've known to not trust something=20
this old.

Much thanks!

Cheers,
-Neil.



On 8/27/2014 5:53 PM, Neil wrote:
> Hmmm... actually it's currently set to PORT (ie: PORTDbits.RD0, etc).  I
> should change that.
>
> Cheers,
> -Neil.
>
>
> On 8/27/2014 4:46 PM, Jan-Erik Soderholm wrote:
>> Just a thought...
>>
>>    > Technically, both bits cannot even change at the same time,
>>    > as they're being individually set (ie: I'm not setting the
>>    > PORT or LAT in one cycle).
>>
>> When setting the port pins, are you using PORTx or LATx ?
>>
>> Jan-Erik.
>>
>>
>>
>> Neil wrote 2014-08-27 20:36:
>>> Having some issues when I run a PIC18F46K22 at higher speeds.  I'm
>>> bit-banging I2C (as both EUSARTs are in use for serial comms), and the
>>> code works as expected at low speeds.  When I go to higher speeds
>>> (32Mhz) the bit timings for the stop condition are odd, and I comms wit=
h
>>> a serial-EEPROM fails.  Anyone know why?
>>>
>>> (1) This works -- 8Mhz, no PLL...
>>> http://veisystems.com/stuff/2014-08-27-PIC-HS-Issue-01-8Mhz-GOOD.gif
>>>
>>> You'll see that there's 5.5us between the positive edge of SCL to the
>>> positive edge of SDA, as expected.  FWIW, I'm using some Nop()'s to get
>>> the correct timing.
>>>
>>> (2) This is the same section of the bit pattern (the I2C stop
>>> condition), for which I only changed the PLLCFG fuse to ON.  This fails=
....
>>> http://veisystems.com/stuff/2014-08-27-PIC-HS-Issue-02-32Mhz%28PLL%29-F=
AIL.gif
>>>
>>> Technically, both bits cannot even change at the same time, as they're
>>> being individually set (ie: I'm not setting the PORT or LAT in one
>>> cycle).  My logic analyzer is sampling at 24Mhz here, so it can
>>> certainly catch the timing.  Also, the low pulse in this screenshot is
>>> also way off in timing, compared to the previous (working) test.
>>>
>>> (3) Without recompiling or reflashing (to ensure that there's no
>>> different optimization going on), I just changed the 8Mhz crystal to
>>> 4Mhz so it's running at 16Mhz now (with the PLL on).  This works again.=
...
>>> http://veisystems.com/stuff/2014-08-27-PIC-HS-Issue-03-16Mhz%28PLL%29-G=
OOD.gif
>>>
>>> I also checked the code size between (1) and (2) where the PLL was
>>> enabled, and code size is the same, so there's no different optimizatio=
n
>>> going on.  I'm not sure what to do from here.  I do need this chip to
>>> run at a higher Fosc (48Mhz).  Any thoughts?
>>>
>>> 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
.