On the ESP32 it is often not possible with the I2C software implementation to communicate with an AIP31068 based LCD module. Therefore, the I2C hardware implementation is enabled when the AIP31068 driver is used, but it is more buggy than stable. The timing of the two implementations seems to be almost identical. The only difference is that the hardware implementation clears the bus before each access by sending 10 clock pulses on the SCL line while SDA is LOW. Using the same mechanism during I2C initialization for the software implementation solves the communication problem with the AIP31068.
The same software implementation works reliably with the AIP31068 on the ESP8266.
The pseudomodules used by the PCF7857x driver are correctly defined by `Makfefile.include` of the driver. However, by mistake they were left in `makefiles/pseudomodules.mk` when the very old PR was rebased to the current master. That is, they were only leftovers that have been overseen after rebasing an squashing dozens of fixup commits.
When the measurement results are read from the `ALG_RESULT_DATA` register set including the STATUS register, the `DATA_RDY` flag in the STATUS register is already cleared during reading. Therefore it is not possible to check this flag after the `ALG_RESULT_DATA` has been read. Therefore the function `ccs811_read_iaq` always returned `CCS811_ERROR_NO_NEW_DATA` although the data were valid either after checking for new data with the function `ccs811_data_ready` or after triggering the Data Ready interrupt.
In the tests fixed in this commit, the header tells that there is a PAN
ID in the header, but no PAN ID was provided in the test vector. This
amends the test vector with the PAN ID (as done in other tests in this
test suite) and adds a check if the PAN was correct.
This fixes the handling when the source address is neither short nor
long. For the reserved address mode no PAN behavior is defined, so
rather check, if the source address is in reserved mode before trying to
read the destination PAN.
