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?

            Can you link to one of the Arduino ones you are looking into using?

            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.

            2 months later

            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.

                4 days later

                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.

                  2 months later

                  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.

                  3 months later

                  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

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