Hi, Victor and others.
It have happened, in version 1.78 of device library for PIC10-PIC12-PIC16-PIC18,
the task queue driver for I2C have disappeared.
Instead, there is a variant of the previous Foundation Services driver.
There are significant improvements, and a differences in location and naming of some files,
and a number of changes in symbols and function names, mostly some more uppercase letters.
The driver design is just as obscure and undocumented as before.
Also the code in i2c_master.c and i2c_master.h,
isn't a complete driver, it is a transfer engine and some building blocks for:
"Write your own driver."
There is a table with a number of callback function pointers,
so when something interesting happen, the transfer engine will call one of those pointers,
where you are supposed to put in a function to take care of whatever may be needed.
There are some functions provided, so when everything go well, it may work as expected.
In the current release of the library, hardware interface to MSSP registers,
is generated in the same source file,
so it might be possible for inline optimizations to work with optimization level 1
in free mode in version 2.xx of XC8 compiler.
In addition to the transfer engine,
there is also a subdirectory with i2c_master_example.c and i2c_master_example.h.
They contain application interface functions similar to what is provided by
i2c_simple_master.c and i2c_simple_master.h
While the transfer engine in i2c_master.c may be configured to work in non-blocking mode using interrupts,
all the application interface functions in i2c_master_example.c and i2c_simple_master.c degenerate to blocking mode, waiting for every transfer to complete before returning.
This may be o.k. for many simple programs using I2C sensors,
and in many PIC16 devices with only one interrupt priority level and small hardware stack, interrupt I2C driver may be more nuisance than benefit.
There was some other bad behaviour in previous versions of Foundation Services driver that have been removed.
In case of a slave not responding due to beeing busy or disconnected,
previous versions of foundation services driver did retry the address write without limitation or timeout, causing the bus to be jammed for any other devices using the same lines, and making the program hang without returning to caller.
This also make it impossible to scan a bus for available devices.
See this thread and the link to microforum https://www.microchip.com/forums/FindPost/1117381
The task queue driver for I2C in previous versions of device libraries,
also have mistakes and limitations.
A design mistake in application interface to task queue use local structure in API routines as part of task queue entries, such that if more than one read and one write transfer is requested, they may destroy each other.
Also task queue entries was released immediately when a transfer was started,
making difficulties for retries or recovery.
A rewrite of the task queue I2C driver is here: https://www.microchip.com/forums/FindPost/978822
There are versions of the driver that may run on many different families of PIC devices,
PIC16 and PIC18 with MSSP peripheral,
some PIC24 and dsPIC33 devices,
and PIC32MX devices.
Driver is also running on PIC32MZ.
Generally, it is not difficult to port the driver code to different devices in the same families, even if it cannot be generated by MCC.
They all provide the same application interfaces for all devices.
There is also a blocking bitbanging I2C driver for PIC32MM devices that have no functional I2C peripheral, it also have the same application interface.
I might publish a blocking, non-interrupt driver for use with PIC16 devices with MSSP peripheral. It will provide the same application interface as for other examples in the same thread.
Application example code in projects in the thread is big and messy,
intended to exercise a lot of different usage.