Great, thanks. I'll give it a look.
Bela displays using I2C pins?
- Edited
did anyone get this working?
I'm planning on giving this a go, via the python library... (then communicate with the audio process via osc)
the following seems a good guide for the BBB
https://learn.adafruit.com/ssd1306-oled-displays-with-raspberry-pi-and-beaglebone-black/overview
my questions is... is the bela (or audio cape) likely to 'get in the way', for either SPI or I2C, and which is the preferred approach?
I guess, looking at the above instructions the question is, are the following valid
for i2c
using /dev/i2c-1
(there is talk in the instruction of ensuring to device overlays are already using)
for spi
using /dev/spidev1.0
enabling via
optargs=capemgr.enable_partno=BB-SPIDEV0
thoughts?
if I can get it working, i'll report back with details
a couple of notes, for me as much as anything:
- the above python method, is built on Adafruit_BBIO, this is probably not going to be in xenomai dist, but it can be built from https://github.com/adafruit/adafruit-beaglebone-io-python
- someone appears to already have Adafruit_BBIO running, see https://forum.bela.io/d/273-reading-digital-pins-from-pd-in-python
Use /dev/i2c-1
, it is broken out on the 4-pin molex header on the Bela cape and it is unused by Bela.
Check here for those pins we are using: https://github.com/BelaPlatform/Bela/wiki/Pins-used-by-the-Bela-cape
- Edited
ok, so got errors whist using apt-get
E: Archives directory /var/cache/apt/archives/partial is missing. - Acquire (2: No such file or directory)
resolved by creating,
now having issues with the python image libraries.....
ive found these are supposed to be replaced by Pillow,
so trying to do
pip install Pillow
but this fails, due to headers for zlib not being available,
so trying to install zlib dev with
apt-get install zlib1g-dev
but thats not found... any ideas, how to install zlib dev?
EDIT:
ok, compiled and installed zlib from source (GitHub), now have the same issue with libjpeg8-dev
(unfortunately you cannot disable jpeg support in pillow in current release!)
ok, I'm confused... what is going on with the distribution sources for bela (0.2.0a)
I can see that an armhf packages is available on debian wheezy, and it appears this is in the source list
deb http://ftp.us.debian.org/debian/ wheezy main contrib non-free
but its just saying no candidate for things like libzlib1g-dev and libjpeg8-dev...
and ive done both apt-get update and upgrade
unfortunately i cannot find the source for libjpeg8 so i cant build it , like i did for zlib....
really frustrating, that i cant just pick up the sources, or the packages...
for me apt-get install
worked fine with zlib1g-dev
, while libjpeg8-dev
seems to have been replaced by libjpeg62-turbo-dev
, which installs just fine, at which point
pip install Pillow
works fine.
Check the following:
a) before any apt-get
operation, is the date on the board correct? (it should get it from the network, but just double check. Opening the IDE page in the browser after a reboot will set the current date (which will be reset at the next boot)
b) run apt-get update
before trying to apt-get install
c) I am using the image v0.2.0b, December 2016, I think you are not (as denoted by the missing /var/cache/apt/archives/partial
, see here). I think apt-get update
should fix your issue, otherwise try upgrading to this release: https://github.com/BelaPlatform/bela-image/releases/tag/v0.2.0b_stable
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
- Edited
You can download libjpeg62-turbo-dev
from here http://ftp.us.debian.org/debian/pool/main/libj/libjpeg-turbo/libjpeg62-turbo-dev_1.3.1-12_armhf.deb and install it with dpkg -i libjpeg62-turbo-dev_1.3.1-12_armhf.deb
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?
Try i2cdetect -y -r 1
- Edited
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.
- Edited
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
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.
giuliomoro Ok, I'm going to give that a shot - thanks Giulio!