Can you link to one of the Arduino ones you are looking into using?
Bela displays using I2C pins?
- Edited
I'm using the adafruit library right now on an small Arduino project I'm doing for a client.
https://github.com/adafruit/Adafruit_SSD1306
It's very easy to use (with the Arduino) and the display is awesome-one or two of them would be PERFECT for a Bela based Eurorack module.
Has anyone else tried to get anything like this working on the Bela?
ben_wizards I did have a go at porting the arduino library to Bela but I ended up needing to include the entire arduino codebase within the project just to get it to compile, and it was getting very messy so I abandoned the attempt. When I have a little more time I plan to try again, this time using the datasheet for the SSD1306 and Bela's I2C API. It should just be a case of following the instructions on the data sheet, but the instructions for this particular module are infuriatingly complicated and obscure.
LiamDonovan Have you looked at Adafruit's BBB or Pi libraries for that and similar OLEDs?
ben_wizards the one I could find seems to be a python library, did you find any C++ library?
Going Python is a possible solution, but you would need some sort of inter-process communication (e.g.: sockets or pipes) to communicate between the Bela C++ program and the Python script.
If you do not need to upgrade the display TOO often (e.g.: less than 5 Hz, I would say) , then you could also consider spawning a python process from the C++ code with a command line parameter to set your visualization, e.g.:
system("python myscript clearDisplay")
, but this is very inefficient as it needs to reload python and import all the libraries for each new command.
Is there any update on this matter? I bought a display that uses the exact library as above, and am unable to figure out how to get it to work. It seems that it is much harder than I originally expected, especially since their website says "The libraries are written in C++ for Arduino but could easily be ported to any microcontroller by rewriting the low-level pin access functions."
This is the display I am using:
https://www.adafruit.com/product/2719
And the 2 required libraries to use it:
https://github.com/adafruit/Adafruit-GFX-Library
https://github.com/adafruit/Adafruit_SSD1306
Any help would be much appreciated.
I tried to comment out all the things that were needed in order for these libraries to compile. So now they compile but obviously do not work.
Anyhow looking at these two commits you will see what would need to be re-implemented (which I have not done and I do not plan to do in the near future):
https://github.com/giuliomoro/Adafruit-GFX-Library/commit/452dc305f3ded58da66fdd1033d338c6d6e185c1
https://github.com/giuliomoro/Adafruit_SSD1306/commit/fb63b38e06bed5af5b1f9195b70d4e29f9e07206
Before going down this rabbit hole, though, I would encourage you to double check if there are any port of the libraries for the BeagleBone. Both projects have several hundred forks, I would be surprised if nothing is there already.
Great, thanks. I'll give it a look.
- 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).