Dear Bela team & Community,

I'm just curious if anyone has had any success connecting devices to the Bela using the built-in UARTs on the BeagleBoneBlack - and accessing them via SuperCollider?

I've got a little external sensor device with an Arduino (pro mini) at its core. I want to have this device send data to the Bela and intercept this data in sclang to trigger some synths. Normally SuperCollider has the SerialPort class to handle this kind of thing - but I've never used it on the Bela.

Right now I'm waiting for a 3.3V Arduino Pro Mini to arrive to begin testing (rather than try level-converting a 5V board) --- but it would be great to hear any success or failure stories from the community.

best wishes,

Jonathan

    a month later

    giuliomoro / jonathan have either of you ran this successfully? Till's post says it relies on a class extension CapSerial that he "will make available soon via the SuperCollider Quarks system" (in 2016), but nothing of that name exists as a Quark. Thanks for any info!

          a year later

          rytrose I got something working without CapSerial ~~~ will post my results soon!

              a year later

              jonathan Did you get something working? Do you have an example? Please share!

              Also to @giuliomoro, if the quarks are floating out there for CapSerial would be helpful.

                  spencer yes! I've successfully gotten serial data going into SuperCollider via the built-in UARTS. Although I have to say that reading serial data in and out in this way (using sclang's SerialPort class) is buggy and seems to be causing audio glitches at times. I'm not really sure why this is... maybe @giuliomoro has some hunches?

                  More recently I was able to develop an I2C UGen to support Trill sensors. This has been much less error-prone than doing serial communication via SC lang. My hunch is that for most cases this is the approach to take... (i.e. building a UGen that does the specific low-level sensor communication via serial or I2C and packages it up into a nice format on the server) .... and my hunch as to why is that everything on Bela is based on the audio thread having high priority, and so having a process that is not being supervised by the audio thread (sclang) launching low-level system calls causes issues..

                  Another possible approach, that I have not yet tried, is to have a stand-alone C++ program that handles serial communications and pipes it into sclang via OSC. This would provide at least a less arduous approach than writing low-level UGens..

                      jonathan Although I have to say that reading serial data in and out in this way (using sclang's SerialPort class) is buggy and seems to be causing audio glitches at times.

                      Anything you do on sclang shouldn't cause any audio glitches on the server. Is it possible that you may be sending large chunks of data to the server? I see how parsing a long message on the server could cause a glitch.

                          7 days later

                          jonathan That is very interesting to hear, do you plan to open the I2C UGen? Does it work bi-directional, so that we could control tiny displays from SC? I gather that having it inside scsynth as a UGen, not in sclang (like the serial stuff) is probably a bit awkward w.r.t. string processing for a display. For things like Trill, a UGen is certainly perfect.

                          Other that that, I have used the UART with the plain serial class in sclang without much problems, interfacing with an arduino keyboard/display combination. Looking at the code, I used /dev/ttyS4, but I probably had to enable it via a dtb overlay first.

                              giuliomoro I wouldn't say large chunks.. but there is a non-trivial number of OSC messages going between sclang and sc-server ...

                                jonathan I think for the screen you would ideally make a little C++ utility that connects to the screen and pipes OSC to sclang.. what do you think @giuliomoro ?

                                I think that would be the best. I have done something like that for Trill that can work as a general template see here

                                jonathan My trill ugens are public: here https://github.com/jreus/Trill_SC

                                You will need my Pull Request for it to work with the released Trill!

                                      11 days later

                                      Just following up now. This is helpful, thanks guys! I'll post some code examples that utilize either or both approaches later this week/early next. I2C might be outside our application space, but I'll talk to the UX/UI team.
                                      @giuliomoro @jonathan

                                      14 days later

                                      Hey all
                                      I've been making some progress building a stand-alone serial utility on the Bela that converts incoming serial data to OSC (see code here)

                                      I would like this little utility to run when the Bela boots up, and to have it quit when the halt switch on the Bela is triggered. Just curious... giuliomoro ...do you have any best practice way of accomplishing this?

                                        you'll need a systemd service.

                                        Create a file following this template in /lib/systemd/system/serialosc.service:

                                        [Unit]
Description=serialosc daemon
[Service]
Type=simple
ExecStart=/usr/local/bin/serialoscd
PIDFile=/var/run/serialoscd.pid
RemainAfterExit=no
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target

                                        then edit the ExecStart line to match your executable file path.

                                        Then execute
                                        - to start the service:

                                        systemctl start serialosc

                                        - to stop the service:

                                        systemctl stop serialosc

                                        - to look at the output:

                                        journalctl -fu serialosc

                                        - to enable it at startup

                                        systemctl enable serialosc

                                        - to disable it at startup

                                        systemctl disable serialosc

                                        Ultimately, I just realised that the serialosc daemon used for the monome may already do all you need ... see here

                                          2 months later

                                          jonathan

                                          We ended up using CAN bus to get thing working, with input messages to supercollider. When we get a chance, we'll share code and methods for folks to use.

                                              spencer ooh, super cool! I'm very curious to see this as well :-)