i2c multiplexer for oled's

vivian

giuliomoro quick question, im getting close to finishing this little project im working on and wanted to ask about the appropriate way to compile all the background scripts like the i2c encoders and i2c display...just all in one project?

giuliomoro

It's probably best to have each of them as a separate process running on the board. Basically, go through these instructions twice, once per each program: https://learn.bela.io/using-bela/bela-techniques/running-a-program-as-a-service

vivian

giuliomoro also slightly noob question but in the main cpp for the u82g how do i change 'parameters' from horizontal lines to vertical?

bela_robert

@vivian excited to see the end result!

vivian

bela_robert ive still some work with trills to do but its getting there!

giuliomoro

See the highlighted line and the following ones: https://github.com/giuliomoro/O2O/blob/main/main.cpp#L265
The "lines" are drawn with "drawBox". The parameter order seems to be:
(xstart, ystart, width, height). Fulll reference for that and the othwr u8g2 methods can be found here https://github.com/olikraus/u8g2/wiki/u8g2reference#drawbox

nickcamillo

@giuliomoro Is using osc to send messages to the screen for the purpose of making development easier or is there a specific functional / timing reason for setting up communications with oled displays this way? I only intend on sending updates to the screens from within my Bela.

giuliomoro

There could be several reasons, but this is mainly down to separation of concerns.. It is a different process that has nothing to do with the Bela process. The process can be started before or after the audio-processing process, according to your requirements. The process can even crash and your audio code will keep running. You don't have to modify your Bela project to support the display(s) at a low level, so for instance you can reuse the same code to drive the display while your program only implements the message sending at a higher level. So much so that - and this is the "killer app" - you can send OSC from any language, without using or knowing C++. So your program can be Supercollider, PureData or Csound and you only have to send out OSC (which is relatively straightforward in any of these).

However, if you have a C++ Bela project, you can reduce the communication overhead and communicate to the screen directly using the C++ API rather than using OSC.

nickcamillo

@giuliomoro I'm getting some errors in the 020 repo on build once #define I2C_MUX is uncommented:

Makefile:510: recipe for target '/root/Bela/projects/oled-displays-2/build/main.o' failed

In file TCA9548A.h: only virtual member functions can be marked 'override' column: 16, line: 15
use of undeclared identifier 'oldTarget' column: 2, line: 145

nickcamillo

@giuliomoro I got around these errors by commenting out both lines shrug

I'm trying to run the update script to pull in the u8g2 dependency in a different project but I keep getting the warning about usage that displays if no directory is supplied. Am I using it correctly?

from the bela console

in ~/Bela/projects/project-name

sh update.sh path/to/u8g2/on/local/machine

giuliomoro

nickcamillo got around these errors by commenting out both lines shrug

That's what I would have suggested too

nickcamillo warning about usage that displays if no directory is supplied.

That also displays if you supply an argument that is not a valid existing directory. Do you need a leading forward slash?

nickcamillo does a mcp23017 example still exist

https://github.com/giuliomoro/MCP23017/blob/bela/render.cpp

giuliomoro

you are specifically meant to run this project as a separate project from your Bela code. As this project contains a main function, it will never call Bela's setup, render, etc. If you want to use this code as part of a C++ project including audio processing code using the Bela API, then you should rename the main function to something else and call it from within your setup() function.

nickcamillo I got around these errors by commenting out both lines

that's now on the main branch with a few more edits.

nickcamillo I'm trying to run the update script to pull in the u8g2 dependency in a different project but I keep getting the warning about usage that displays if no directory is supplied. Am I using it correctly?

this needs to run so that the machine running update.sh can access the specified path. For instance, if you have /path/to/u8g2/on/local/machine on your local computer and run update.sh on the board, it won't work. I just updated to the latest u8g2 (1bd25a7e657e20ef0efdab1c9cb5ba4e0aeae75b) and updated the update script so that it should be mostly automated. This update and updated update can be found on the update branch.

nickcamillo

giuliomoro @vivian does a mcp23017 example still exist? I can't seem to get the basic LED example of the shift register in to work but i have a bunch of 23017's lying around

nickcamillo

@giuliomoro yes this was with a leading forward slash pointing to a directory on my local machine

nickcamillo

@giuliomoro I'd still like to figure this out for the future, for now I got around it by cloning the oled project and copying my existing render.cpp into it. Not ideal bc I've now got two separate git projects/repos but one step closer at least.

On a previous commit, I was able to get 5 multiplexed OLEDs to update from messages sent directly via C++. Today I've successfully got them running as a service and reacting to OSC messages via supercollider. That said, it seems like now my render.cpp file never makes it to setup(). I've got an rt_printf() there that never executes.

This is my current output when running the project:

There is a trill connected directly to i2c lines and then the 5 OLEDs connected via a multiplexer.

Build finished
Running project ...
opened i2c file 4
set i2c addr 3c
opened i2c file 5
set i2c addr 3c
opened i2c file 6
set i2c addr 3c
opened i2c file 7
set i2c addr 3c
opened i2c file 8
set i2c addr 3c

Any ideas? Nothing else has changed.

nickcamillo

@giuliomoro I'm using the oxo main.cpp file exactly at the moment with the exception of enabling multiplexing and configuring the 5 OLEDs in gDisplays. Is there anything else I was supposed to change in there that might be causing the rest of the startup to block?

nickcamillo

I've been re-reading the instructions, am I specifically supposed to run this OLED service as a separate project in bela? currently it's all in the same project with my render.cpp just as a different file called OLEDS.cpp

nickcamillo

giuliomoro thank you, before I try this I just want to clarify what you're saying.

If you want to use this code as part of a C++ project including audio processing code using the Bela API, then you should rename the main function to something else and call it from within your setup() function.

What you're suggesting here would mean that I'm no longer running a background service right? I think I need to run the OLEDs as a background service because I get dropped audio frames when I try to update the screens directly via the C++ api from within my render.cpp during audio playback.

you are specifically meant to run this project as a separate project from your Bela code. As this project contains a main function

Do you mean that this example project was meant to be run that way, or that implementing the background service works that way? Like I should build and run that separate project as a service and then switch back to my main project and run my normal project on the bela?

giuliomoro

You can build the O2O project as it ships from the Bela IDE and even run it from within it, but it won't process any audio. This is C++, so the program will start execution from the main() function. In most Bela project, there is no main() function, so the default one is used under the hood, which in turn calls setup(), render(), cleanup(). In this project, there is a main() function and so the default one won't be called and setup(), render() and cleanup() won't run.

If you want a single program to run both the OLED(and optionally OSC) stuff AND the audio, then you wouldn't run two different processes and you would simply set the one program to run on boot from the IDE. If you previously enabled running the program as a separate service, you should disable that.

nickcamillo I think I need to run the OLEDs as a background service because I get dropped audio frames when I try to update the screens directly via the C++ api from within my render.cpp during audio playback.

This is not because you are running them from within the same process, rather because you are doing something from the audio thread that takes too long and/or are running non real-time-safe code from within the audio thread. You should reduce computation in the audio thread and push any long or non real-time-safe computations to a different thread. If you were to share your code I could probably help with that.

nickcamillo

giuliomoro Thanks for the explanation. The code in question is very simple but I accidentally deleted it during this process. I'm trying to animate a playhead moving across a waveform on the OLED during playback. It worked great, just dropped frames. Every time readPointer % playheadInterval == 0 where playheadInterval = gNumberOfFrames / displayWidth i'm calling a drawWaveform function which first calls switchTarget to the correct display, clears the display's buffer and then draws a waveform and the playhead. Depending on the length of the file, this call happens more often than others but I optimized when it gets called so that it only happens once per pixel.

so basically something like this

...
void render(BelaContext * context, void * userData) {
  for (unsigned int n = 0; n < context -> audioFrames; ++n) {
  
    if (readPointer % playheadInterval == 0) {
      drawWaveform(playheadIndex);
    }
  }
}

Would love to see how to handle this in another thread, and if you know how to only update certain parts of an individual display using u8g2 I'd love to hear that too haha.

giuliomoro

hmmm what is drawWaveform()? If that is computing all the pixels of the screen, it could be already very time consuming, possibly enough to cause a dropout. If in addition to that it also calls sendBuffer() then it really shouldn't be called from there because that operation takes several milliseconds to complete. Keep in mind that the display has a limited refresh rate, this depends on how many pixels you redraw (normally all of them)* and the I2C speed (which should already be at the maximum). This means that you should only try to draw it every so often, e.g.: every 50 ms. This is best done from a separate thread, where you have something like:

void writeToScreen(void*)
{
    while(!Bela_stopRequested()){
        // set all the pixels
        // .... your code here ...
        // send the data via I2C to the display
        u8g2.sendBuffer(); // this will take time to complete, possibly several milliseconds
        // sleep a bit if needed to lower the frame rate:
        // the overall period of the loop will be primarily determined by this sleep + the time it takes to complete sendBuffer() above.
        usleep(10000);
    }
}

you'd start this thread from setup() with something like:

Bela_runAuxiliaryTask(writeToScreen);

now, the magic is all in ... your code here ... there you'll probably put something very similar to drawWaveform(playheadIndex). You need playheadIndex to be a global variable so that it can be written from the audio render() thread and read from the writeToScreen() thread. This way you don't even need the if(readPointer % playheadInterval == 0) logic in render().
You can remove the usleep() line if you want the highest refresh rate that the I2C bus will allow, but that may put a significant load on your CPU and may make the IDE unresponsive, but it should in no way cause audio dropouts. If the IDE becomes unresponsive, briefly press the button on the Bela cape to stop the execution of the Bela program and wait a few seconds for the IDE to come back to life.

nickcamillo and if you know how to only update certain parts of an individual display using u8g2 I'd love to hear that too haha.

not sure. In csrc/u8g2_buffer.c , u8g2_send_buffer(), which is called from U8G2::sendBuffer(), calls u8g2_send_tile_row() and ultimately u8x8_DrawTile(). This last one u8x8_DrawTile() is also available directly from U8G2::drawTile(uint8_t x, uint8_t y, uint8_t cnt, uint8_t *tile_ptr). Not sure about the semantics of the arguments, but you can try looking at the existing code. Note that some displays will need to call refreshDisplay() for any change applied with drawTile() to take place. A tile seems to be an 8x8 pixel square, according to grepping through the docs.

« Previous Page Next Page »