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
).