Is there a guide somewhere to hooking up I2c displays, or should I be able to use the existing (Adafruit etc) libraries with minimal effort?

We do not have such guide at the moment.

There are a few device-specific I2c classes, with a bare minimal I2c super class, have a look here
http://docs.bela.io/classI2c.html

but basically any library you may find around should probably just work. Make sure you run any I2C operations from a thread that is not the audio thread.

See the MPR121example project to see how to create a separate thread and read the sensor from within it: http://docs.bela.io/capacitive-touch_2render_8cpp-example.html

I have started work on a library for Bela based loosely around arduino's wire library that allows you to write to and request from an I2C device from the audio thread without mode switches. Unfortunately it's not quite finished and it still causes occasional mode switches due to memory allocations, but I'm hoping to make it available soon.

In the meantime as Giulio said the best approach is to use the Adafruit (or whatever) libraries from an auxiliary task.

    7 days later

    LiamDonovan I'd be happy to be a beta tester for that! I'd love to be able to use a modernish OLED display to have an interface for the Bela.

    Honestly, what I'd LOVE is to be able to output the scope and maybe some interface over the HDMI port, but I know that's not going to happen.

        To be honest, after spending last night trying to get the Beaglebone's wifi to work-it'd work, but then on reboot my wlan would get assigned to a random number or the USB wifi card would stop being seen, or 100x other issues I found dozens of conflicting guidelines on how to fix-combined with the lack of basic functioning libraries for things like MIDI or displays, the loss of my git files more than once, the lack of more Belas in the time promised, the ongoing issues, I'm pretty frustrated with the whole thing and I'm thinking of moving this project over to the Pi.

          ben_wizards sorry to hear about your troubles. The BeagleBone's WIFI connectivity has always been a bit flaky in my experience, but I have had it working reliably by following this guide on our wiki.

          We do have a working MIDI library though it is of course under development like all of Bela. Support for other things like displays is coming, but it's worth remembering that all the Bela devs have full time jobs doing other stuff at the moment, and we have to prioritise.

          The delays with getting more capes on sale have unfortunately been mostly out of our control, as we first needed to finalise a complicated license agreement with Queen Mary University, and then it has taken over a month to set up a bank account. The details literally just arrived this morning, and we are setting up our web shop as we speak. So they'll be ready very soon!

          If you have specific problems with anything we're always happy to help.

              ben_wizards I'll try and get the I2C library up in new branch at some point in the next day or so, though I don't have any I2C devices with me right now to test it with. If you would like to test it, that would be very helpful!

              Unfortunately HDMI is disabled on Bela because it uses the same pins as the audio codec, but the scope only works because the heavy lifting of powering the display is offloaded to the host computer, the BeagleBone would struggle to do that itself. What you can do is connect it via USB or Wifi to a tablet (just a cheap Android one works fine) and use its browser to render the scope.

                  ben_wizards I looked back to all your open issues and they all seem to have been resolved, let us know if there is anything else that requires our attention.

                    My issues are just mainly frustration with the Beaglebone not so much the Bela part, I think. I had deleted my (frustrated from trying to get wifi working for hours) comment earlier, but it seemed to not have been taken down.

                    I was using your guide, but even with a powered USB hub, the Wlan id kept changing on reboot. I've read that this is a common problem with BBBs. I only wanted to get it online because I wanted to try to install something from a repository. I should have been satisfied with a LAN connection, but I was being pigheaded about it.

                    Don't get me wrong, I like a lot of things about the Bela! I love the built in scope, the ease of use for testing out audio, the multiple ADCs. I'm not really a coder-I'm an EE, so I really like not having to do all of the legwork for the inputs and outputs-that's huge.

                    I know I'm an early adopter and that this isn't a full time project for anyone, but I had been hoping for something with better documentation in the examples, more bare bones examples, that sort of thing.

                    For example, the MIDI demo includes code for some pedal I'd never heard of, one that has nothing to do with the Bela that I could tell. The multiple oscillators demo has/had virtually no documentation and I just couldn't understand what I was supposed to do to use it. Minor complaints, but it contributes the the feel of "not quite right."

                    My biggest gripe has been the distortion on the output, but I've read that might be a problem fixable in later versions of the software, or did I get that wrong?

                    Guilomoro, The Git issue has been filed as a bug, from what I could tell. I have regular backups and I'm only working on one project right now, but I've been backing up the render.cpp every few hours and the .zip file every day or so. I lost 2 days of git history, so I'm not really too worried about that.

                    LiamDonovan , I'd be happy to test an i2c oled I just got in. It's an ssd1306, which supposedly works in the BBB, but I haven't been able to make it happen yet.

                    I'd be happy to donate one to you folks if you wanted to test it. They're only €10 or so.

                      was it the name of the interface changing at every reboot (like wlan0 changing to wlan1) or the IP address?
                      If it is the former, I don't know much about it, but having the same configuration in /etc/interfaces for both, should take care of that.
                      If it is the IP address, then it is up to your router to make sure it always assigns the same IP address to the board (or you can set the board to a fixed IP address, but this needs to be non-conflicting with the router).

                      The MIDI demo shows how to send out some control changes. They just happen to have the meaning of toggling a LED on that specific device, but there is no reason why you would need that device to run the example. You can use any device, but you'll need to send a different value in order to obtain some effect. Sure that may be confusing, so I'll replace it with a more common "note on/off".

                      The oscillator-bank example surely is missing documentation, though the inlined comments should be enough to get the grasp of it.

                      Not sure what is this output distortion you are referring to, maybe this thread ? Despite it is not clearly stated anywhere in our guidelines, I think it is reasonable to expect the user to provide detailed instructions to a minimal working example that can reproduce the issue, otherwise it may be very difficult (and time consuming) to help users. Also, it is not clear from that thread whether your issue was finally resolved or not.

                      The git issue has definitely been logged as such. The github tracker is the right place for posting issues (again, with a reasonably detailed set of instructions on how to reproduce them).
                      Feel free to create issues also for the lack of documentation above.

                      What sort of examples would you like to see? If you post them on the forum, then maybe the community can help with them, or we when we are done with fixing bugs.
                      I2C / serial are not really Bela-specific things, so did not put much effort into documenting them, as the internet is full of tutorials on how to get them running on a BeagleBone.

                        Ok so this is starting to be quite an interesting discussion because I find myself agreeing with @ben_wizards here. While I think the BeagleBone offers pretty amazing functionality I think it does it in a way that is much harder to use than e.g. an Arduino. Linux is pretty complicated and hard to understand unless you've spent a lot of time learning it.

                        This was basically the main motivation behind the IDE, to get as much of the confusing boilerplate out of the way and make things as straightforward as possible, without dumbing down the functionality. And I think we could go a lot further by developing our APIs and user interfaces for peripherals and abstracting away a lot of the obscure Linux and Xenomai complexities.

                        And I think we're going in the right direction but there's a lot of work to do first! And other commitments to fulfil in the meantime.

                        giuliomoro One boot-wlan8, reboot, wlan0, wlan1, so on.

                        To recreate the distortion-create any complex signal, even bandlimited, output that to a scope.
                        Hell, input a signal and loop it back to the output.

                        Look at the signal.

                        Massive over/undershooting.

                        It's written (with screenshots )in my post.

                        The comments for the oscillator bank were not enough, I didn't get it. Instead of a simple example, it's a complex thing with lots of moving parts and no clear comments as to what each part was doing or how use them.

                        You write "2C / serial are not really Bela-specific things, so did not put much effort into documenting them, as the internet is full of tutorials on how to get them running on a BeagleBone." but apparently to use standard beaglebone functions you have to use something called an auxilliary function and your example of how to use one of those isn't something simple, it's a whole program that does something complicated that HAPPENS to use an aux program.

                        One of many reasons things like the Pi and Arduino took off is because they provided a solid backbone of examples that people could build from instead of "see, there's this part here that you need, just reverse engineer what we did, despite minimal documentation and it'll be fine"

                        I'd love to see things like...Simple examples. Basic functions to create a toolkit.

                        The expectation that we should submit complaints to Github instead of here should be the default answer to any question, or you could recognize that people who buy a product want to ask questions in a forum dedicated to that product. I'd never used github before the Bela. I'm quite fond of it now, but it was 100% foreign to me the first time I used it. I imagine that lots of people, especially artists, who want to go past arduino and into some real power will have the same experiences as me.

                          Regarding the wifi dongle, it may be worth having a look at this file on your board
                          /etc/udev/rules.d/70-persistent-net.rules
                          feel free to paste its content in a new thread if you want to seek help with that, I'll be happy to have a look, though given my limited knowledge of the topic, maybe a Debian/Arm/BeagleBone forum would be more appropriate?

                          The example in 11-Extras/bucket-brigade-chorus is as simple as it gets for demonstrating AuxiliaryTasks : a loop runs in an Auxiliary Task to write to the I2C bus, while the audio code runs unaltered, though you are right it could use a better name and it deserves an entry in the wiki. Although I reckon the documentation on AuxiliaryTasks (available here or on your board) is probably enough.

                          The issue tracker we ultimately look at and where we fix issues is the one on github. Now if a problem comes up in the forum which reveals an issue with the core code or IDE or documentation, I usually add an issue to GitHub as well, but I may occasionally fail to do so (maybe because I do not think it deserves it). If we fail to add them there, then users should feel free to add them in (possibly after a discussion on the forum). Again, we have to prioritize resources, so not everything that is on it will be closed immediately, but if it is not there, it is unlikely that we will ever fix it.
                          Just a side note: despite the tracker shows 98 issues, most of those have been fixed in various dev branches and will shortly be merged into master. The issues that are ACTUALLY still open (if my filtering rules are right) are these 16

                          Another side note is: users are welcome to contribute with code examples and even wiki pages. Wiki pages are editable by anyone with a GitHub account.

                          I'd love to see things like...Simple examples. Basic functions to create a toolkit.

                          That sounds good, exactly what we want. A more detailed list would help us get a better idea of your expectations are (maybe good for a separate thread?).

                          11 days later

                          LiamDonovan Any update on the i2c liberry? I realized that the Adafruit one is written in Python and I'm not sure how to integrate that into the Bela environment at all.

                              I know there are ways of including python libraries in C/C++, but I'm not sure if it's doable in the Bela/BBB.

                              I saw this Library and it'd pretty much cover everything one would need for getting Bela going as a fully functional module.

                              @LiamDonovan Actually I am thinking that to write to the I2C device from a time-critical thread you may be able to simply the call to write() in I2c_Codec::writeRegister with rt_fprintf().

                              Alternatively, the proper "Xenomai" way of communicating between rt and non-rt threads is rt_pipe. You would then need a "consumer" non-rt thread which reads from the pipe and writes to the I2C pseudo-file . Xenomai pipes allow bi-directional communication so you could use the same thread to read from I2C and send back.

                              The catch in these cases is always that you have a finite amount of memory pre-allocated, but that would be the same catch for any other rt implementation. So it is important that the user a) does not write too much data at once (and if they do they should increase the buffer size beforehand) and, b) the user checks for the return value of writeRegister().

                              I used pipes in the latest Midi https://github.com/BelaPlatform/Bela/blob/dev-midi/core/Midi.cpp but only in one-direction.

                              thought rt_fprintfis probably less deterministic than using the queue (as the buffering is left to Xenomai), though it probably does not make a huge difference either way for most I2C applications.

                              ben_wizards I'll get on it once I figure out how rt_pipes work. At the moment it occasionally causes mode switches so it would probably not be very useful in its current state.

                                Ok I've got this working. You can get it by checking out the dev-i2c branch from the repo, then take a look at the 06-sensors/i2c_accelerometer example. A disclaimer: it is not yet well tested or documented.

                                The important thing is to use i2c.request and i2c.write to read and write from the audio thread (i.e in render). In setup or on an auxiliary task you should instead use i2c.requestNow and i2c.writeNow.

                                Suggestions / comments / testing are all welcome.

                                  LiamDonovan Great! I only have one problem-the I2C libraries for the common OLEDs are all either written for Arduinos or are written in Python. Any idea how I can get around that?