I2C: Fix NACK issue in PN532 driver / example

[omeh-a]

Currently and for all recent versions, the PN532 driver causes a constant stream of NACKs. This means that all of the error prints in the driver have simply been disabled to remove the pollution. This issue proposes discovering the root cause of this issue, fixing it~~, and restoring all of the commented out error reporting in i2c.c~~

This isn't just a reporting error - as can be seen in the attached logic analyser screenshot, every ACK / NACK frame sent to the PN532 is terminated with an electrical NACK. The NACK only shows up at the actual end of a transaction, implying that this is purely a PN532 issue (phew). You can see this in the screenshot where fragmented parts of a transaction still end with an appropriate ACK.

[omeh-a]

Note: changes to the prints have rendered the need to change error reporting unneccesary. The constant NACKs are real however and result in unwanted errors.

[omeh-a]

The device also emits a constant stream of timeout errors from the I2C hardware on the ODROID - the actual conditions for the IRQ to trigger are not documented whatsoever, so I am assuming that they fire whenever the list processor is not explicitly stopped and doesn't receive a reply. There are between 1000 and 2000 timeout IRQs between every successful read attempt of the PN532 example

[wom-bat]

I think we're using the PN532 wrongly. And we should look at that first.

[omeh-a]

Further investigation shows that we are not using the PN532 wrong - the PN532 uses I2C wrong! There seems to be no way to fix this issue; even when using IRQs the same things happen. This suggests that the only action to take is to inspect the NACK handling in the driver - at present, we seem to be retrying transactions even when we have a confirmed failure, forever - fixing this behaviour should be enough to unblock #212

[omeh-a]

Superceded by #239