Or perhaps the apt-get upgrade bit screwed up things? We had to add jessie repositories to this image (despite it being Wheezy) to get some of the newest stuff, which is why - I imagine - some things may get screwed if you upgrade.
Again, the steps above work fine on 0.2.0b

yeah, id already tried the update without the upgrade... and wasn't working so i think its a 0.2.0a issue.
I'll install 0.2.0b later to try to resolve

anyway, manually installed the deb, and now Pillow is installed.. thank you for that
now I'm getting a 121 io error on i2c_bus 1, using the breakout molex header.

all seems to be wired correctly, 3.3v to VDD, GND to GND , SCA to SCA , SCL to SCK(?!) , P9_12 to RST

thoughts, is there a simple way to test the I2C?

giuliomoro

 root@bela1 ~$ i2cdetect -y -r 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

(out of interest i see data for bus 0 and 2 , with i2cdetect)

ive got an analog discovery 2 here... but never used it for protocol analysing ( so not really sure how to use it for this!), but if i connect that i can see voltage on vdd/gnd ... and when python tries to write to i2c bus 1, i see a very brief bit of activity on sck and sca ... then i get the 121 error and it stops

Ive got an rPI3 here, perhaps I'll install everything for that, and see if that works !?

    it looks like there may be something wrong with the connection: the activity you see is probably due to the master (the BBB) trying to communicate to the slave.

    Can you try

    grep "97c\|978\|980\|984" $PINS

    just to double check that the pinmuxer settings are ok?
    You should get

    pin 94 (44e10978) 00000073 pinctrl-single
pin 95 (44e1097c) 00000073 pinctrl-single
pin 96 (44e10980) 00000073 pinctrl-single
pin 97 (44e10984) 00000073 pinctrl-single

    Also, while Bela is not running, you could try to connect your I2C device to the i2c2 bus. There you should see something like this when nothing is connected:

    # i2cdetect -r -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

    Which is the audio codec for Bela. If you plug in your device, then the above should change to show up your device.

    Running another I2C device on the same bus as the one used for the Bela audio codec is fine as long as you make sure that you do not communicate with that device when a Bela program starts ( the codec is configured every time the Bela program is started).

      giuliomoro it appears to also have the same issue on a rPI3...

      can i use SPI on bela? perhaps that will work 😉

        You can sure try the SPI, but the SPI is also used by the Bela analog I/O, so you would have to disable those* in order to be able to use your display (or re-arrange the PRU code to accommodate display commands in between analog readings (!!!!)).

        Perhaps just give it a try while Bela is not running so that you can check your display is not running.

        * make sure you get a recent-ish version of the Bela code (i.e.: post https://github.com/BelaPlatform/Bela/commit/d7f71f02e68ffb569ada85b0be6c3925623e26f3), otherwise the SPI transactions will still take place even when the analogs are disabled.

        another note: there are two SPI busses broken out the P9 header, but only SPI0 is usable when the McASP is activated, as the latter takes over the pins where SPI1 would be available. SPI0 is in use by the Bela analogs.

        ok, ive solved it 🙂

        the issue was the oled display was configured for SPI, to convert to I2C I had to remove a resistor, and put a couple of solder bridges in place.

        then I needed to hold the CS,DC to ground... and I found a circuit which enables you to not require the RST pin, so saving a digital IO.
        https://electronics.stackexchange.com/questions/164680/ssd1306-display-spi-connection-or-i2c-according-to-resistors

        and viola, it now works on both Bela and my rPI3 over I2C 🙂

        thanks for your help, its really useful to know about using i2cdetect to see if there is any life in your i2c device 🙂

        a month later

        Hi all,

        Apologies in advance for being the newest of noobs - I have (hopefully) a very basic question! This appears to be the relevant thread, but if not then I will delete and re-post elsewhere.

        I have an I2C accelerometer, which I want to use to control a libpd patch. I've connected the accelerometer to the corresponding I2C pins on the Bela cape (GND, 3.3V, SCL, SDA), and I'm able to drag-and-drop my Pd patch into the IDE, but what should I add to my Pd patch so that it recieves the accelerometer input?

        Many thanks 🙂

          papa_sangre Correction: It's actually an Accelerometer + Gyroscope: GY-521 MPU-6050 Module 3 Axis Gyroscope + Accelerometer.

            I2C sensors are not supported by default on Bela within Pd. The reason for this is that each of them have a very specific interface and data structure that is very hard to generalize. So if you want to bring I2C sensors in, you will have to write some C++ code to read and parse the data coming through the I2C bus , then you can pass the readings into pure data.
            There is an abstract class I2c in the core code in Bela/include/I2c.h and example implementations of that class for mpr121 and touchkeys sensors are in Bela/core/I2c_TouchKey.cpp, Bela/include/I2c_Codec.cpp and Bela/examples/06-Sensors/capacitive-touch/I2C_MPR121.cpp.

            All this code would go in a render.cpp file within your Pd project folder. See for instance the 08-PureData/customRender example.

              2 years later

              hey giuliomoro ... I'm trying to get some I2C communication going on the Bela. But I'm not using the Molex connector (rather I'd like to connect directly to the headers of the BBB via a custom capelet). I'm a bit confused though.. in the document you linked I see that the Bela is using pins P9.26 & P9.24 ... but in the BBB documentation these pins the TX and RX pins for UART1. Am I missing something painfully obvious? I want to make sure I'm tapping into the right pins :-)

              I2C1 header (broken out to the molex connector on the Bela cape but unused on the board)

              "P9.26", 0x180 0x73 / i2c1_sda, MODE3 | INPUT_PULLUP | SLEWCTRL_SLOW /
              "P9.24", 0x184 0x73 / i2c1_scl, MODE3 | INPUT_PULLUP | SLEWCTRL_SLOW /

                that is because each pin can have multiple function, and the name of a pin is "randomly" chosen as one of the names of the functions it can have. So yes, those two pins are CALLED "UART1 Rx/Tx" however, they can perform different functions, including I2C. And the function that is active by default on Bela is ... I2C!

                8 days later

                Ah! I didn't realize that. Thanks :-)
                I guess these pin modes are all set and configured at a low level in the Bela OS.