[Flashforth-devel] I2c using PIC MSSP

[craig b. <dab...@ya...>]

I'm coming back to FORTH after being away for a while including programming PIC16-s in assembler for a couple of decades.  I've never really gotten the I2c mode of the MSSP module to work, I've always just fallen back on bit-banging a couple of I/O pins and been done with it.

I now have a PIC18F4458 with FlashForth 3.8 up and ticking along on a 48Mhz oscillator with customized A/D routines to do 12-bit reads, and the included I2cBase routines loaded (tweaked for PortB SCL & SDA) because I also need to talk to ADS1100 I2c A/D converter chips.  I don't actually have any I2c devices to talk to yet, but I have 10K pullups on the 2 pins and a BitScope attached to watch behavior.  The I2cINIT, SSEN, and SPEN routines work as expected.  I can even stick an i2c@nak in the middle and it runs straight through.  What doesn't seem to work for me is the sspbuf! routine.  I can't see any sign that pir1.sspif is ever changing after I clear it.  The SCL pulses and data states for that one byte go out and then it just hangs.  I have to ^O it to get out... which leaves little to diagnose with.  the only thing that calls it and "works" is I2cWS which sits there madly banging the pins continuously untill I ^O that, too.

Obviously I'm missing something, is it an I2c Slave on the bus?  I won't get that for a day or more and if that's the problem, how can I test for that condition and keep running?  


I can still load up the FF Assembler and write yet another I2c bitbanger, but I was really hoping to get the hardware to work this time.  If anyone can help point me in the right direction, I would be much obliged...  Thanks for reading this, you're either very patient or completely bored (grin).

craig bair

 
...averaging may or may not help clarify data. 
   If Bill Gates walks into a bar, 
   the average patron becomes a millionaire...