Using Bela's Serial library to pass data to and from a PC

Thanks for the response.
I set the line to be:
gSerial.setup ("/dev/ttyGS0", 115200);
I run the program on the board, then on the host PC I use $ echo "s" > /dev/ttyACM0 and get a response!

But getting a response to that echo would only last for several seconds (~ 5-15 secs). After this amount of time, the program is still running but responses are gone. I ran some tests and it seems like a matter of time rather than the amount of chars passed. It would not respond even to a single echo after I wait several seconds.
When I run the program with gSerial.setup ("/dev/pts/0", 57600); and give input from within a Bela via shell everything works perfectly.

1. What could explain this?

Also, I’m looking for a way to send data from Bela to be stored in a file on the PC. For example, I’d like to add a functionality where every time “snare” is received, a text file on the host PC is concatenated with Bela’s uptime, without damaging the Real time functionality of Bela.

I’ve looked at the read and write functions in ‘Serial.h’ and ‘Pipe.h’. As well documented, the read/write functions in the serial library are used to read/write bytes from/to the serial port. In ‘Pipe.h’ their functionality is to exchange data between a RT and a non-RT thread.

2. I might be super wrong here but I didn’t manage to find an initiative idea as to how the Serial library can be used to achieve this goal. What would be the best way?

Another thing I noticed is that in render's while(gPipe.readRt(c) > 0), the Pipe’s gPipe.readRt redirects eventually to:

ssize_t Pipe::_readRt(void* ptr, size_t size)
{
    return _readRtNonRt(ptr, size, true);
}

Where Pipe::_readRtNonRt is fully implemented. Hope I’m not mistaken.

3. It looks like a function that’s supposed to act in RT is immediately redirected to NonRT. Am I missing something here, and it doesn’t really affect any required functionality?

giuliomoro Does this mean that if you run echo "s" > /dev/ttyACM0 repeatedly on the host, at some point the you no longer get a "response"? What is a response here? To simplify things, if you print the received message from the Bela C++ program, does it keep printing when you perform the echo command on the host?

My idea of response there was the printing and the generation of snare/kick sound according to the input. For example with "s":

Here's c: sReceived: s

c>0 and c is: s

I guess that's equivalent to satisfying either one of the conditions:

if('k' == serialBuffer[n])
{
gPipe.writeNonRt('k');
gSerial.write("kick!\n\r");
} else if('s' == serialBuffer[n])
{
gPipe.writeNonRt('s');
gSerial.write("snare!\n\r");
}

in render.cpp. After several seconds, while repeatedly sending echos on the host, it will stop printing as well as making drum sounds.

giuliomoro Did you stop the systemctl serial-getty@ttyGS0 service as explained above?

I tried in both cases, disabled and not disabled, same outcome.
Removed /etc/systemd/system/getty.target.wants/serial-getty@ttyGS0.service.

giuliomoro No. _readRtNonRt()'s last argument tells it whether it's RT or non-RT. The two cases are handled in a single place to avoid duplicates

Sorry I totally missed that boolean.

giuliomoro So you have a host sending some data to the board over USB-serial and you want that whenever such data is received a file on the host is updated with the board's timestamp? Can you not log that on the board and copy it over once the program ends, or every so often?

Yes sir. I'm interested in passing info that should be recorded on the board. The idea is to have a connection between Bela and the PC for as much time as needed, that will preserve Bela's RT capabilities, where files on both platforms can be updated with varying information and saved multiple times. Such file modification is not periodic and should occur upon a decision made elsewhere, here for simplicity it's represented by sending "s" or "k" because you made it so comfortable. Modifying files should not meet RT constraints, but only should not interfere with Bela's RT jobs.

giuliomoro Also, if this is all going to be done over the Bela's USB connection, then why not use the ethernet functionality that it provides and do everything via network instead of UART?

No prevention from using ethernet, do you recommend using it instead? I went to USB arbitrarily when I saw gSerial.setup ("/dev/ttyUSB0", 19200); and I didn't know what would be the implications of trying to communicate with Bela over ethernet.

Can't thank you enough for your posts