I'm not sure what you're asking for. I don't have a flow chart, as it is the MCC generated code. It is also quite complex and I'm just barely good enough to step through the code trying to debug it. -- Sincerely, James Burkart *925.667.7175* On Mon, Oct 28, 2019 at 12:15 PM Nicola Perotto wrote: > Hi James, > can you share also your "flow chart" of the algorithm? > Nic > > > > On 28/10/2019 18:46, James Burkart wrote: > > OK, so update. Amazingly I stumbled across an online forum run by the > > person who wrote the MCC Foundation I2C driver. At first they were > > optimistic they could help me with getting it to work properly. > > > > A little background. I am able to successfully read and write to an I2C > > slave device. The problem is when there is a NACK such as when the slav= e > > you are requesting isn't present on the bus. The driver doesn't handle = it > > properly, it goes into an endless loop. > > > > So we have been going back and forth with some code changes, and as it > > stands, the person realizes there are some bugs, but unfortunately they > do > > not have the time at the moment to debug the code. They gave me some > > suggestions on things to try, buy my knowledge in C and specifically th= e > > workings of this driver, are not very good. I am in over my head, but I > > need to get this to work, or else I'm back to writing my own bit-bang > > driver. > > > > If any of you are interested, here is my thread on the forum: > > > https://www.microforum.cc/topic/90-help-with-mcc-generated-i2csimple-gett= ing-stuck-in-a-loop/ > > > > -- > > Sincerely, > > > > James Burkart > > *925.667.7175* > > > > > > On Mon, Oct 21, 2019 at 4:59 AM Jason White < > > whitewaterssoftwareinfo@gmail.com> wrote: > > > >> If things still are not working you ought to post some waveforms of th= e > >> device's i2c read request and response. Chances are that it would be > easy > >> to see what the problem is from that information (eg. Pull ups too wea= k, > >> incorrect clock stretching, wrong clock rate, etc.) > >> > >> On Monday, October 21, 2019, James Burkart > >> wrote: > >> > >>> I saw that. I do have a logic analyzer I'm using to debug. > >>> > >>> I gave up on my soft i2c code and I am earnestly trying to figure out > how > >>> to use the mcc foundation services simple i2c drivers. The reason I > >> ditched > >>> it before is because it was slow. There was a long pause between ever= y > >> byte > >>> written and read. But I just dug into the driver and found where the > >> delay > >>> is and shortened it some. It's acceptable now. > >>> > >>> The delay is in a function labeled inline void > mssp_waitForEvent(uint16_t > >>> *timeout) > >>> > >>> There was a 100us delay located in a while loop that's checking for a= n > >>> interrupt flag to set. If someone knows why it's even there, I'm all > >> ears. > >>> In the meantime, I'm moving on though I've noted where I made the > change > >> in > >>> case something gets wonky in the future. I'll eventually dig deeper t= o > >>> understand the driver more. > >>> > >>> On Mon, Oct 21, 2019, 2:23 AM Chris Roper wrote: > >>> > >>>> If you have a PICKit 2 or 3 you can use the GUI as a crude Logic > >>>> analyzer that will allow you to see your SLC and SDA lines and look = at > >>> the > >>>> response and timing. It is a very useful and oft overlooked tool for > >> this > >>>> sort of debugging. > >>>> > >>>> On Mon, 21 Oct 2019 at 09:41, Joep Suijs wrote: > >>>> > >>>>> The slave is allowed to strech the clock. > >>>>> I once had trouble with i2c software master code reading a slave. I= t > >>>> turned > >>>>> out the slave used clock streching to setup data requested by the > >>> master. > >>>>> The master didn't check the clock though, and read rubbish while th= e > >>>> slave > >>>>> was still busy preparing the requested data... > >>>>> > >>>>> Joep > >>>>> > >>>>> Op ma 21 okt. 2019 om 09:00 schreef James Burkart < > >>>>> james@burkartstudios.com > >>>>>> : > >>>>>> I haven't got to the clock stretching yet. I'm still just working > >> on > >>>>>> reading the I2C bus. > >>>>>> -- > >>>>>> Sincerely, > >>>>>> > >>>>>> James Burkart > >>>>>> *925.667.7175* > >>>>>> > >>>>>> > >>>>>> On Sun, Oct 20, 2019 at 11:12 PM Joep Suijs > >>> wrote: > >>>>>>> Hi James, > >>>>>>> > >>>>>>> I did check your code and didn't see where it actually checks for > >>> the > >>>>>> clock > >>>>>>> to go high (that is, read input and check it, not fixed delay). > >>>> Didn't > >>>>>>> check all of your code though, so I might have missed it. > >>>>>>> > >>>>>>> Good luck. > >>>>>>> Joep > >>>>>>> > >>>>>>> Op ma 21 okt. 2019 om 06:44 schreef James Burkart < > >>>>>>> james@burkartstudios.com > >>>>>>>> : > >>>>>>>> Thanks Joep, > >>>>>>>> > >>>>>>>> I appreciate the help. I do understand how I2C works, my > >>> questions > >>>>> are > >>>>>>>> about my code. The port pins I am using for clock and data are > >>>>>> operating > >>>>>>> as > >>>>>>>> open drain, so I'm not driving anything high. > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Sincerely, > >>>>>>>> > >>>>>>>> James Burkart > >>>>>>>> *925.667.7175* > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sun, Oct 20, 2019 at 4:11 AM Joep Suijs > >>>> wrote: > >>>>>>>>> Hi James, > >>>>>>>>> > >>>>>>>>> The slave hold the clock low to hold off the master when it > >>> needs > >>>>>> time. > >>>>>>>> So > >>>>>>>>> after the master 'releases' the clock to go high, it needs to > >>>> wait > >>>>>>> until > >>>>>>>>> the clock line actually is high before it can proceed. This > >> is > >>>> also > >>>>>> the > >>>>>>>>> reason you shouldn't drive clock high, only low... > >>>>>>>>> > >>>>>>>>> Joep > >>>>>>>>> > >>>>>>>>> Op zo 20 okt. 2019 om 00:23 schreef James Burkart < > >>>>>>>>> james@burkartstudios.com > >>>>>>>>>> : > >>>>>>>>>> I am using pull up resistors on both SCL and SDA. Analog is > >>>>>> disabled > >>>>>>> on > >>>>>>>>>> RC7. The author of the original code mentions that he wrote > >>> the > >>>>>> code > >>>>>>> to > >>>>>>>>> be > >>>>>>>>>> as universal as possible. I understand the reasoning, it's > >>> just > >>>>>>>>>> implementing it that's giving me issue. So I re wrote the > >>> code > >>>>> and > >>>>>> am > >>>>>>>>> using > >>>>>>>>>> the open drain feature of my micro on SDA and SCL. But now > >>> I'm > >>>>>> trying > >>>>>>>> to > >>>>>>>>>> successfully read from SDA. > >>>>>>>>>> > >>>>>>>>>> On Sat, Oct 19, 2019, 4:13 PM Mike < > >> pic.developer@gmail.com> > >>>>>> wrote: > >>>>>>>>>>> Do you have pull-up resistors on both SCL and SDA? Have > >>> you > >>>>>>>> configured > >>>>>>>>>>> the ANSELC register to disable analog input in RC7? > >>>>>>>>>>> > >>>>>>>>>>> Using the TRIS register to switch a pin between an input, > >>> or > >>>> an > >>>>>>>> output > >>>>>>>>>>> with a logic 0 level set is a common way of simulating an > >>>>>>> open-drain > >>>>>>>>>>> output if this function is not support in hardware. The > >>> code > >>>>> you > >>>>>>> used > >>>>>>>>>>> was very likely written for an old 14 bit part (16C/16Fxx > >>>> etc.) > >>>>>>> which > >>>>>>>>>>> don't have open-drain outputs. > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> > >>>>>>>>>>> Mike > >>>>>>>>>>> > >>>>>>>>>>> On 19/10/2019 22:49, James Burkart wrote: > >>>>>>>>>>>> I wrote up a bit-bang I2C routine to communicate with a > >>>>> couple > >>>>>>>>> devices, > >>>>>>>>>>> an > >>>>>>>>>>>> SSD1306 OLED and an MCP23018 port extender. I'm using a > >>>>>>>> PIC18F27K40. > >>>>>>>>>>>> I've got the sending data part just fine, but I can't > >>>> figure > >>>>>> out > >>>>>>>> the > >>>>>>>>>>>> receiving part, including reading acknowledge bits. I, > >> in > >>>>>> large, > >>>>>>>>> copied > >>>>>>>>>>> the > >>>>>>>>>>>> code example from a blog post by Calvin Cherry ( > >>>>>>>>>>>> > >>>> https://calcium3000.wordpress.com/2016/08/19/i2c-bit- > >>> banging-tutorial-part-i/ > >>>>>>>>>>>> ). > >>>>>>>>>>>> To be honest, the way he was switching SDA between an > >>> input > >>>>> and > >>>>>>>>> output > >>>>>>>>>>> was > >>>>>>>>>>>> confusing to me and so I just enabled open drain on the > >>>> port > >>>>>> pins > >>>>>>>> in > >>>>>>>>>>>> question. And that's why I can write to the I2C bus > >> just > >>>>> fine, > >>>>>>> but > >>>>>>>>>>> reading > >>>>>>>>>>>> from it I am stumbling. For my bit read function I > >> change > >>>> the > >>>>>>> port > >>>>>>>>> pin > >>>>>>>>>>> used > >>>>>>>>>>>> for SDA to an input and read its value through > >>>> PORTCbits.RC7 > >>>>>> but > >>>>>>>> it's > >>>>>>>>>>>> always reading 0. > >>>>>>>>>>>> > >>>>>>>>>>>> I'd like to use the hardware I2C but I can't get the > >> MCC > >>>> code > >>>>>> to > >>>>>>>>> work, > >>>>>>>>>>>> either the Foundation Services version, nor the other > >> one > >>>>> that > >>>>>> is > >>>>>>>> to > >>>>>>>>> be > >>>>>>>>>>>> obsoleted soon. > >>>>>>>>>>>> -- > >>>>>>>>>>>> Sincerely, > >>>>>>>>>>>> > >>>>>>>>>>>> James Burkart > >>>>>>>>>>>> *925.667.7175* > >>>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list > >>>>> archive > >>>>>>>>>>> View/change your membership options at > >>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/piclist > >>>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list > >>>> archive > >>>>>>>>>> View/change your membership options at > >>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/piclist > >>>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list > >>> archive > >>>>>>>>> View/change your membership options at > >>>>>>>>> http://mailman.mit.edu/mailman/listinfo/piclist > >>>>>>>>> > >>>>>>>> -- > >>>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list > >> archive > >>>>>>>> View/change your membership options at > >>>>>>>> http://mailman.mit.edu/mailman/listinfo/piclist > >>>>>>>> > >>>>>>> -- > >>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > >>>>>>> View/change your membership options at > >>>>>>> http://mailman.mit.edu/mailman/listinfo/piclist > >>>>>>> > >>>>>> -- > >>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > >>>>>> View/change your membership options at > >>>>>> http://mailman.mit.edu/mailman/listinfo/piclist > >>>>>> > >>>>> -- > >>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > >>>>> View/change your membership options at > >>>>> http://mailman.mit.edu/mailman/listinfo/piclist > >>>>> > >>>> -- > >>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > >>>> View/change your membership options at > >>>> http://mailman.mit.edu/mailman/listinfo/piclist > >>>> > >>> -- > >>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > >>> View/change your membership options at > >>> http://mailman.mit.edu/mailman/listinfo/piclist > >>> > >> > >> -- > >> Jason White > >> -- > >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > >> View/change your membership options at > >> http://mailman.mit.edu/mailman/listinfo/piclist > >> > > -- > > Nicola Perotto - NP Engineering > Sistemi Informatici ed Elettronici > skype: nicolap > mob IT: +39 335 7162 582 > mob HU: +36 30 417 3780 > tel: +39 06 916 502 732 > fax: +39 0439 633 1191 > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .