I2C improvements in 1.8.7

[deshipu]

I was just writing some new device drivers recently, and I had the opportunity to actually test the improvements for the I2C protocol handling in release 1.8.7, and I have to admit that they are really great. The ability to tell whether a byte was acked or nacked, and the more detailed exceptions allowed me to implement waiting for measurement on the SI7021 sensor, and the ability to configure the clock stretching timeout lets me talk to the BNO055 sensor at a sensible speed, without having to reduce the clock frequency of the whole bus. Bringing back the stop argument to the writes lets me send data from several sources more efficiently, without having to copy it all into a single buffer first. Well, done, and I'm really glad that our over-the-top and wishing-for-the-moon discussions here didn't stop the practical small changes from happening. Thank you.
I also had a comparison with the CircuitPython API, since I ported those drivers to both forks, and I sincerely hope that all those improvements will be some day ported over to CircuitPython, because the MicroPython API is currently so much better.

[Turbinenreiter]

I also had a comparison with the CircuitPython API, since I ported those drivers to both forks, and I sincerely hope that all those improvements will be some day ported over to CircuitPython, because the MicroPython API is currently so much better.

I haven't spent too much time in the CircuitPython API and also haven't worked with the improvements you just described, but I still got to form an opinion:
The MicroPython API is better.
CircuitPythons shared binding approach is really smart.

I'm trying right now to implement SPI on the Raspberry Pi by using the other SPI implementations as reference and it is so confusing. It looks different on all ports and the C API is not really documented, so you just have to grep through the codebase and figure it out (I'm also seriously considering modifying my syntax highlighting files to get all the special types we have highlighted). I'd happily fund a third Kickstarter solely aimed at documenting the C API and restructuring the codebase to make porting and API implementation easier.

I had moments when everything fell into place when I wrote my dbus-library, and when it does, it is beautiful. Maybe I went into the SPI library wrong, but when I first looked at it I thought - hey just replace the code in the transfer function with the appropriate stuff from the C SPI example and done - but man, what a nightmare.

[deshipu]

There is always the problem of spending time on actually implementing things, versus spending time on documenting things so that more people can work on the implementation. However, with the pull request ban in force, I don't think documentation is such a good investment at the moment, because the extra work force thus gained would be wasted anyways.

However, I started writing some documentation some time ago at http://micropython-dev-docs.readthedocs.io/en/latest/ -- it's really just the beginning, mostly cobbled together from dhylands' examples, but it's a start. If you like, you can add to it. Of course, it would be much more convenient to just pay someone to do it, but I'm afraid the people who are qualified are busy with other things...

[Damien]

Thanks @deshipu for the feedback. The main driver for improving machine.I2C was the new LCD160CR display in the uPy shop. It needs a fast and robust I2C implementation with support for nacks.

Sent from my GT-I9105P using Tapatalk