Hello everyone,
I am trying to read GY-521 (Gyro+Accelerometer+Temperature) sensor data in a pure data patch but I couldn't figure out how to make a custom render file. I am very beginner on C++, It would be great if anyone could help me?
How can I read Bela's i2c pins from pd?

There is no way (yet?) to access I2C data straight from Puredata. While I am thinking that writing an external to enable that should not too complicated, this is not on my schedule yet.
So the currently recommended approach would involve steps not too dissimilar from the ones outlined here (for a different problem, that did not involve I2C) :

  1. write a C++ program to read the I2C data. The datasheet I foundfor your sensor does not seem to have the registers that you need to read. So this register map will be very useful.
  2. create a custom wrapper for Pd, see here and send the data retrieved over I2C to Pd

However, the first point is not straightforward and (unless there is a C/C++ library for Linux available for your sensor) requires quite some heavy tinkering. This project used an approach similar to the one described above in order to read I2C data from a BNO055 IMU and pass them on to Puredata.

    Thanks Giulio! but unfortunately I am unable to work this out.. Before Bela, I was using Arduino/Teensy and I2c library, it was so easy to read the data and use in pd as a musician. I tried to implement the ideas in HC-SR04 example. I understand the logic but can't figure out how to implement those ideas on a GY-521, since it is a very complex sensor, sending lots of messages. I don't have any idea to read and parse those data in C++. I think I should ask for help from some one who is good at C++.

      giuliomorohttps://github.com/uraimo/MPU-6050.swift Hey I think I have found a very useful thing, I guess this library will make it easier, it supports beaglebones. How should I use this?

        I don't think that that swift implementation will be usable directly, however it is a good reference for the functionality of the device, without having to dig through the manual. I have done some work on I2C in the past couple of days, going towards a more complete C++ base class, which I will then make available from Puredata. You will still have to implement all the device-specific stuff yourself in Pd, but at least you will not have to use C++!

          Hey giuliomoro , I just discovered your branch "better-i2c" and was wondering when it would be safe to download and use it now or wait for a more definitive version. Keep me posted and thanks for your work!

          Michele

              Sindel it's far from stable. It would work the way you saw it, but there is no guarantee the API will stay the same (actually, just the opposite, as of tonight).

                bleenisgrue I understand the logic but can't figure out how to implement those ideas on a GY-521, since it is a very complex sensor, sending lots of messages.

                Now I have implemented a way to interact with I2C devices from within PureData. See the example patch here. It's still not an easy task to write a driver for your device, but being able to do it from Pd could be useful in your case. I know nothing about swift and the library in use by the implementation you linked to, but I'd guess, looking at this that:

                • readByte(address, command) does a repeated-start read to read one byte at the register specified in command, so for instance: i2c.readByte(address, command: 0x41) would become [writeread 65 1( (where 65 is the decimal representation of 0x41 and 1 is the number of bytes to read)
                • writeByte(address, command, value) does a 2-byte write, where the first value is the register to write. For instance: writeByte(address, command: 0x6B, value: UInt8(0x80)) would become [write 107 128( (where - again - 107 and 128 are the decimal representations of 0x6B and 0x80, respectively).

                Overall - looking at the swift implementation - the device does not look too complicated and you should be able to implement it in Pd with this API, probably you will have to run reset() and enable() at the beginning and then you should be able to writeread the values from the registers. You will need some bitshifting ([<<]) and bitwise or ([| ]) to get the UInt16 16-bit values.

                Note that this branch only runs on a v0.3.1 image (which you will have already, if you got the board in November 2017 or later), or you can get from here. Actually I am soon going to merge this into topic/xenomai-3-stable (which in turn should be merged into master).

                Sindel was wondering when it would be safe to download and use it

                Now it's doing much better. In fact, the read(), write() and readWrite() are to be considered stable. I may remove (or at least rename) readRegisters() and writeRegisters(), though, because they are not universal for all I2C devices (in that readRegisters() uses a "repeated start", while writeRegisters() assumes that the first byte you write is the destination address; none of these are dictated by the I2C protocol itself, rather they are built on top of it). I am open to suggestions on how to rename them, because I have no idea (perhaps readRegisters--->readRepeatedStart?).
                Notice that there is now a I2cRt class (which is behind the libpd implementation), which uses two lock-free ringbuffers and is real-time safe (with readRt(), writeRt(), readWriteRt()), and can manage the non-realtime thread on its own, or make the non-rt callback available to an external thread (for an example of the latter, see core/deault_libpd_render.cpp).

                      giuliomoro thanks for the explanation! I started using teensy to send gyro data from pwm out to analog in of bela. But I'll try your implementation, at least I would get rid of an extra board. thanks for great support!