Have you considered just throwing away the driver and manipulating the i2c peripheral directly? The datasheet typically has enough data for one with modest coding skills to write a serviceable chunk of code. I've learned over the years that often for comms and i/o it is better to just ignore the drivers and go after the device directly, as the driver often makes assumptions which are not relevant to your specific situation. On Mon, Oct 28, 2019 at 1:18 PM James Burkart wrote: > What I need is a well commented driver that doesn't have bugs that render= s > it almost useless. > > -- > Sincerely, > > James Burkart > *925.667.7175* > > > On Mon, Oct 28, 2019 at 1:00 PM Nicola Perotto > wrote: > > > > > > > On 28/10/2019 19:34, James Burkart wrote: > > > I'm not sure what you're asking for. > > > > > I don't have a flow chart, as it is > > I already know... ;-) > > > > > 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. > > If the code is complex you NEED some kind of "flow chart" (I used > > quotes...). > > It has not to be "canonical" nor complete but drawing a scheme of what > > you are > > trying to do is very useful :-) > > Nic > > > > -- > > 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 > --=20 - Forrest --=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 .