• Delaying the I2C1.setup() solves the issue.

    Ok, thanks - that's interesting.... So just to be sure I'm understanding from the traces you've put up:

    • The first slow pulse train is from freeI2Cbus
    • The first picture is with I2C1 - and there's absolutely no activity whatsoever
    • The third picture is software I2C and it all works fine

    How did you save your code - with save()? Or 'to flash' - http://www.espruino.com/Saving

    Either way something is odd with Espruino - I wonder if it's trying to restore pin state, and it's doing so after onInit() is called for some reason. I've filed an issue for this and I'll see if I can reproduce with any old I2C device I have kicking around: https://github.com/espruino/Espruino/iss­ues/2016

    it would of course be nice to extend the I2Cx objects with a 'transfer complete' event

    Yes, absolutely. The vast majority of I2C transactions do tend to be just a few bytes though, so given the execution speed of Espruino you're probably not saving too much time (in most cases - I2C OLED is the one I know is a pain). A quick addition that would have a noticable impact in most cases would actually be just adding a I2c.readFromAddr function that wrote a single byte first.

    From my point of view adding an async SPI function is probably more of a priority, although it's not to say I2C won't get added as well. Once there's more of a framework in place for it, adding to different peripherals (ADC as well) wouldn't be such a big deal.

About

Avatar for Gordon @Gordon started